Erstellen von Windows Universal-OEM-Paketen

Artikel
10/04/2017

Der Standard für die Windows Universal OEM-Verpackung wird unter Windows IoT Core, Version 1709, unterstützt.

Dieses neue Verpackungsschema ist so aufgebaut, dass es künftig mit mehr Gerätetypen kompatibel sein wird. Wenn Sie Pakete für IoT Core-Geräte mit dem Legacy-Verpackungsstandard (pkg.xml) erstellt haben und sie auf IoT-Geräten verwenden möchten, können Sie sie in den neuen Verpackungsstandard konvertieren.

Pakete

Pakete sind die logischen Bausteine, die zum Erstellen von IoT Core-Bildern verwendet werden.

Alles, was Sie hinzufügen, wird verpackt. Jeder Treiber, Bibliothek, Registrierungseinstellung, Systemdatei und Anpassung, die Sie zum Gerät hinzufügen, ist in einem Paket enthalten. Der Inhalt und der Speicherort jedes Elements werden in einer Paketdefinitionsdatei (*.wm.xml) aufgeführt.
Pakete können von vertrauenswürdigen Partnern aktualisiert werden. Jedes Paket auf Ihrem Gerät wird von Ihnen oder einem vertrauenswürdigen Partner signiert. Dadurch können OEMs, ODMs, Entwickler und Microsoft zusammenarbeiten, um Sicherheits- und Featureupdates für Ihre Geräte bereitzustellen, ohne auf die Arbeit der anderen zu stompen.
Pakete werden versioniert. Dies hilft, Updates zu vereinfachen und Systemwiederherstellen zuverlässiger zu machen.

Eine Beispielpaketdatei (sample_pkg.cab) enthält eine Paketdefinitionsdatei, Paketinhalte wie Apps, Treiber und Dateien sowie eine Signaturdatei und eine Versionsnummer

Pakete fallen in drei Hauptkategorien:

OS-Kit-Pakete enthalten das zentrale Windows-Betriebssystem
SoC-Hersteller-Prebuilt-Pakete enthalten Treiber und Firmware, die den Chipsatz unterstützen
OEM-Pakete enthalten gerätespezifische Treiber und Anpassungen

Erfahren Sie, wie Sie diese Pakete in Bilder für Geräte kombinieren.

Beginnen Sie mit dem Erstellen eines neuen leeren Pakets

Installieren Sie Windows ADK für Windows 10, Version 1709 sowie die anderen Tools und Testzertifikate, die in "Abrufen der Tools" beschrieben sind, um Windows IoT Core und Lab 1a anzupassen: Erstellen eines grundlegenden Bilds.

Verwenden Sie einen Text-Editor, um eine neue Paketdefinitionsdatei (auch als Windows Manifest-Datei bezeichnet) basierend auf der folgenden Vorlage zu erstellen. Speichern Sie die Datei mit der Erweiterung wm.xml.

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<identity
  xmlns="urn:Microsoft.CompPlat/ManifestSchema.v1.00"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  name="MediaService"
  namespace="Media"
  owner="OEM"
  >
</identity>

Erstellen Sie die leere Paketdatei (*.cab). Der erstellte Dateiname basiert auf dem Besitzer, Namespace und Namen aus der Datei.

c:\oemsample>pkggen myPackage.wm.xml /universalbsp

Directory of c:\oemsample

04/03/2017  05:56 PM    <DIR>          .
04/03/2017  05:56 PM    <DIR>          ..
04/03/2017  05:43 PM               333 myPackage.wm.xml
04/03/2017  05:56 PM             8,239 OEM-Media-MediaService.cab

Hinzufügen von Inhalten zu einem Paket

Der Inhalt eines Pakets wird als Liste der XML-Elemente in der Paketdefinitionsdatei organisiert.

Im folgenden Beispiel wird veranschaulicht, wie Sie einige Dateien und Registrierungseinstellungen zu einem Paket hinzufügen. In diesem Beispiel wird eine Variable (_RELEASEDIR) definiert, die jedes Mal aktualisiert werden kann, wenn Sie das Paket generieren.

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<identity
    xmlns="urn:Microsoft.CompPlat/ManifestSchema.v1.00"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    name="MediaService"
    namespace="Media"
    owner="OEM"    
    >
  <files>
    <file source="$(_RELEASEDIR)\MediaService.dll"/>
  </files>
  <regKeys>
    <regKey keyName="$(hklm.software)\OEMName\MediaService">
      <regValue
          name="StringValue"
          type="REG_SZ"
          value="MediaService"
          />
      <regValue
          name="DWordValue"
          type="REG_DWORD"
          value="0x00000020"
          />
    </regKey>
  </regKeys>
</identity>

Ausführen des pkggen.exe-Tools

PkgGen.exe [Project] /universalbsp ...

  [project]··········· Full path to input file : .wm.xml, .pkg.xml, .man
                       Values:<Free Text> Default=NULL

  [universalbsp]······ Convert wm.xml BSP package to cab
                       Values:<true | false> Default=False

  [variables]········· Additional variables used in the project file,syntax:<name>=<value>;<name>=<value>;....
                       Values:<Free Text> Default=NULL

  [cpu]··············· CPU type. Values: (x86|arm|arm64|amd64)
                       Values:<Free Text> Default="arm"

  [languages]········· Supported language identifier list, separated by ';'
                       Values:<Free Text> Default=NULL

  [version]··········· Version string in the form of <major>.<minor>.<qfe>.<build>
                       Values:<Free Text> Default="1.0.0.0"

  [output]············ Output directory for the CAB(s).
                       Values:<Free Text> Default="CurrentDir"

Beispiel:

c:\oemsample>pkggen myPackage.wm.xml /universalbsp /variables:"_RELEASEDIR=c:\release"

Hinzufügen einer Treiberkomponente

Verwenden Sie in der Paketdefinitionsdatei das Treiberelement , um Treiber einzugeben. Es wird empfohlen, relative Pfade zu verwenden, da es in der Regel die einfachste Möglichkeit ist, den INF-Quellpfad zu beschreiben.

  <drivers>
    <driver>
      <inf source="$(_RELEASEDIR)\Media.inf"/>
    </driver>
  </drivers>

Wenn der Standarddateiimportpfad nicht dem INF-Quellpfad entspricht, können Sie das DefaultImportPath-Attribut verwenden. Im folgenden Beispiel befindet sich die INF im aktuellen Verzeichnis, aber die zu importierenden Dateien sind relativ zu $(_RELEASEDIR).

  <drivers>
    <driver defaultImportPath="$(_RELEASEDIR)">
      <inf source="Media.inf"/>
    </driver>
  </drivers>

Wenn dateien, die importiert werden sollen, nicht relativ zur Definition in der INF sind, können Dateiüberschreibungen angewendet werden. Dies wird nicht empfohlen, ist aber für spezielle Fälle verfügbar.

  <drivers>
    <driver>
      <inf source="Media.inf"/>
      <files>
         <file name="mdr.sys" source="$(_RELEASEDIR)\path1\mdr.sys" />
         <file name="mdr.dll" source="$(_RELEASEDIR)\path2\mdr.dll" />
      </files>
    </driver>
  </drivers>

Hinzufügen einer Dienstkomponente

Verwenden Sie in der Paketdefinitionsdatei das Dienstelement (und seine untergeordneten Elemente und Attribute), um einen Systemdienst zu definieren und zu verpacken.

   <service
      dependOnService="AudioSrv;AccountProvSvc"
      description="@%SystemRoot%\system32\MediaService.dll,-201"
      displayName="@%SystemRoot%\system32\MediaService.dll,-200"
      errorControl="normal"
      imagePath="%SystemRoot%\system32\svchost.exe -k netsvcs"
      name="MediaService"
      objectName="LocalSystem"
      requiredPrivileges="SeChangeNotifyPrivilege,SeCreateGlobalPrivilege"
      sidType="unrestricted"
      start="delayedAuto"
      startAfterInstall="none"
      type="win32UserShareProcess"
      >

Erstellen und Filtern von WOW-Paketen

Fügen Sie zum Erstellen von Gast- oder WOW-Paketen (32-Bit-Pakete, die auf 64-Bit-Geräten ausgeführt werden sollen) das BuildWow="true" -Attribut zu myPackage.wml hinzu

<identity
    xmlns="urn:Microsoft.CompPlat/ManifestSchema.v1.00"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    name="MediaService"
    namespace="Media"
    owner="OEM"
    buildWow="true"
    >

Führen Sie PkgGen.exe mit jetzt einem WOW-Paket für jedes Hostpaket aus.

04/05/2017  07:59 AM            11,870 OEM-Media-MediaService.cab
04/05/2017  07:59 AM            10,021 OEM-Media-MediaService_Wow_arm64.arm.cab

In der Regel erhält das 64-Bit-Gerät sein Host 64-Bit-Paket und entweder sein Gast-32-Bit- oder WOW-Paket, das von myPackage.wm.xml generiert wird. Um Ressourcenkonflikte zwischen den beiden Paketen zu vermeiden, verwenden Sie Buildfilter:

  <regKeys buildFilter="not build.isWow and build.arch = arm" >
    <regKey keyName="$(hklm.software)\OEMName\MediaService">
      <regValue
          name="StringValue"
          type="REG_SZ"
          value="MediaService"
          />
    </regKey>

In diesem Fall sind die Registrierungsschlüssel exklusiv für das Host 32-Bit-Arm-Paket. Der CPU-Switch wird verwendet, um build.arch festzulegen und build.isWow wird von PkgGen auf "false" festgelegt, wenn das 32-Bit-Hostpaket erstellt wird, und dann true beim Erstellen des 32-Bit-Gast- oder WOW-Pakets.

[cpu]··············· CPU type. Values: (x86|arm|arm64|amd64)
                     Values:<Free Text> Default="arm"

Konvertieren von universellen Windows-OEM-Paketen

Wenn Sie Pakete mithilfe des pkg.xml Paketmodells erstellt haben und sie unter Windows IoT Core, Version 1709, verwenden möchten, müssen Sie ihre Pakete entweder neu erstellen oder mithilfe des pkggen.exe-Tools konvertieren.

Nachdem Sie die Pakete konvertiert haben, müssen Sie möglicherweise die wm.xml Datei ändern, um sicherzustellen, dass es dem Schema folgt.

IoT Core-Add-Ons v4.x unterstützen den neuen Standard für universelle OEM-Pakete (wm.xml). Dieses neue Verpackungsschema ist so aufgebaut, dass es künftig mit mehr Gerätetypen kompatibel sein wird.

Konvertieren ihrer Paketdateien

So konvertieren Sie Ihre vorhandenen Pakete, die im älteren Telefonpaketformat (pkg.xml) erstellt wurden, in das neue wm.xml-Format:

pkggen.exe "filename.pkg.xml" /convert:pkg2wm

Oder konvertieren Sie aus der IoTCoreShell-Eingabeaufforderung entweder convertpkg oder buildpkg. Die Ausgabe wm.xml Dateien werden in demselben Ordner gespeichert.

convertpkg.cmd MyPackage.pkg.xml
buildpkg.cmd MyPackage.pkg.xml

Überprüfen und testen Sie die wm.xml Pakete mit Buildpkg.

buildpkg.cmd MyPackage.wm.xml

Nachdem Sie die Dateien in wm.xml Format konvertiert haben, können die pkg.xml-Dateien sicher gelöscht werden.

Generieren Ihrer App-Pakete

Verwenden Sie das newAppxPkg mit demselben Komponentennamen. Dadurch wird die customizations.xml Datei neu generiert. Die Versionsnummer der Appx wird als Versionsnummer für ppkg beibehalten.

newAppxPkg "C:\DefaultApp\IoTCoreDefaultApp_1.2.0.0_ARM_Debug_Test\IoTCoreDefaultApp_1.2.0.0_ARM_Debug_Test.appx" fga Appx.MyUWPApp

Weitere Informationen: Apps hinzufügen.

Hinzufügen von Dateien: Achten Sie auf null große Dateien, relative Pfade

Nullformatige Dateien werden in wm.xml nicht unterstützt. Um dies zu umgehen, fügen Sie ein leeres Leerzeichen in der Datei hinzu, wodurch die Datei nicht null groß ist.

Pfade: Wenn Sie Dateien hinzufügen, die sich im aktuellen Verzeichnis befinden, müssen Sie das Präfix .\ explizit dem Dateinamen hinzufügen.

<BinaryPartition ImageSource=".\uefi.mbn" />

Weitere Informationen: Dateien hinzufügen

Aktualisieren des Bereitstellungspakets customization.xml Datei

In ADK Version 1709 müssen Sie die Datei customizations.xml aktualisieren:

Verschieben Sie im Ordner „Produkt\prov“ „Common/ApplicationManagement“ manuell auf Common/Policies/ApplicationManagement

    <Customizations>
      <Common>
        <Policies>
          <ApplicationManagement>
            <AllowAppStoreAutoUpdate>Allowed</AllowAppStoreAutoUpdate>
            <AllowAllTrustedApps>Yes</AllowAllTrustedApps>
          </ApplicationManagement>

Bereitstellungspakete (PPKG) unterstützen jetzt die vierteilige Versionierung ähnlich wie die Paketversionierung. Mit dieser Änderung, Version 1.19 > 1.2. Frühere Versionen verwendet zeichenbasierte Sortierung, sodass Version 1.19 früher als 1.2 betrachtet wurde.

Weitere Informationen: Hinzufügen von Bereitstellungsdateien

Freigeben über