Creare pacchetti OEM universali di Windows

Articolo
10/04/2017

Lo standard di creazione di pacchetti OEM universali di Windows è supportato in Windows IoT Core versione 1709.

Questo nuovo schema di creazione pacchetti è compatibile con più tipi di dispositivi in futuro. Se sono stati creati pacchetti per i dispositivi IoT Core usando lo standard di creazione di pacchetti legacy (pkg.xml) e si vuole usarli nei dispositivi IoT, è possibile convertirli nel nuovo standard di creazione di pacchetti.

Pacchetti

I pacchetti sono i blocchi predefiniti logici usati per creare immagini IoT Core.

Tutto quello che si aggiunge è in pacchetto. Ogni driver, libreria, impostazione del Registro di sistema, file di sistema e personalizzazione aggiunti al dispositivo è incluso in un pacchetto. Il contenuto e il percorso di ogni elemento sono elencati in un file di definizione del pacchetto (*.wm.xml).
I pacchetti possono essere aggiornati dai partner attendibili. Ogni pacchetto nel dispositivo viene firmato dall'utente o da un partner attendibile. Ciò consente agli OEMs, agli sviluppatori, agli sviluppatori e a Microsoft di collaborare per offrire aggiornamenti della sicurezza e delle funzionalità ai dispositivi senza modificare il lavoro dell'altro.
I pacchetti vengono versioneti. Ciò consente di semplificare gli aggiornamenti e rendere più affidabili i ripristini di sistema.

Un file di pacchetto di esempio (sample_pkg.cab) include un file di definizione del pacchetto, il contenuto del pacchetto, ad esempio app, driver e file, oltre a un file di firma e un numero di versione

I pacchetti rientrano in tre categorie principali:

I pacchetti del kit del sistema operativo contengono il sistema operativo Windows principale
I pacchetti predefiniti del fornitore SoC contengono driver e firmware che supportano il chipset
I pacchetti OEM contengono driver e personalizzazioni specifici del dispositivo

Informazioni su come combinare questi pacchetti in immagini per i dispositivi.

Iniziare creando un nuovo pacchetto vuoto

Installare Windows ADK per Windows 10 versione 1709, nonché gli altri strumenti e i certificati di test descritti in Ottenere gli strumenti necessari per personalizzare Windows IoT Core e Lab 1a: Creare un'immagine di base.

Usare un editor di testo per creare un nuovo file di definizione del pacchetto (denominato anche file manifesto di Windows) in base al modello seguente. Salvare il file usando l'estensione 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>

Creare il file di pacchetto vuoto (*.cab). Il nome del file creato è basato sul proprietario, lo spazio dei nomi e il nome dal file.

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

Aggiungere contenuto a un pacchetto

Il contenuto di un pacchetto è organizzato come elenco di elementi XML nel file di definizione del pacchetto.

Nell'esempio seguente viene illustrato come aggiungere alcuni file e impostazioni del Registro di sistema a un pacchetto. In questo esempio viene definita una variabile (_RELEASEDIR) che può essere aggiornata ogni volta che si genera il pacchetto.

<?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>

Eseguire lo strumento di pkggen.exe

PkgGen.exe [progetto] /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"

Esempio:

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

Aggiungere un componente driver

Nel file di definizione del pacchetto usare l'elemento driver per inserire i driver. È consigliabile usare percorsi relativi, poiché in genere è il modo più semplice per descrivere il percorso di origine INF.

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

Se il percorso di importazione del file predefinito non è uguale al percorso di origine INF, è possibile usare l'attributo defaultImportPath. Nell'esempio seguente, INF si trova nella directory corrente, ma i file da importare sono relativi a $(_RELEASEDIR).

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

Se i file da importare non sono relativi alla modalità di definizione nel file INF, è possibile applicare gli overridi di file. Non è consigliabile, ma è disponibile per casi speciali.

  <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>

Aggiungere un componente del servizio

Nel file di definizione del pacchetto usare l'elemento del servizio (e i relativi elementi e attributi figlio) per definire e creare un pacchetto di un servizio di sistema.

   <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"
      >

Compilare e filtrare pacchetti WOW

Per creare pacchetti Guest o WOW (pacchetti a 32 bit da eseguire in dispositivi a 64 bit) aggiungere l'attributo buildWow="true" a myPackage.wm.wml

<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"
    >

Esecuzione di PkgGen.exe con ora generare un pacchetto WOW per ogni pacchetto host.

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 genere, il dispositivo a 64 bit otterrà il pacchetto Host a 64 bit e il pacchetto Guest a 32 bit o WOW, entrambi generati da myPackage.wm.xml. Per evitare conflitti di risorse tra i due pacchetti, usare filtri di compilazione:

  <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 questo caso, le chiavi del Registro di sistema sono esclusive per il pacchetto Arm host a 32 bit. L'opzione CPU viene usata per impostare build.arch e build.isWow è impostata da PkgGen su false durante la compilazione del pacchetto host a 32 bit, quindi true durante la compilazione del pacchetto Guest a 32 bit o WOW.

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

Conversione di pacchetti OEM universali di Windows

Se hai creato pacchetti usando il modello di creazione pacchetti pkg.xml e vuoi usarli in Windows IoT Core versione 1709, dovrai ricreare i pacchetti o convertirli usando lo strumento pkggen.exe.

Dopo aver convertito i pacchetti, potrebbe essere necessario modificare il file di wm.xml per assicurarsi che segue lo schema.

IoT Core Add-Ons v4.x supportano il nuovo standard di pacchetti OEM universali windows (wm.xml). Questo nuovo schema di creazione pacchetti è compatibile con più tipi di dispositivi in futuro.

Convertire i file del pacchetto

Per convertire i pacchetti esistenti creati nel formato di creazione di pacchetti telefonici legacy (pkg.xml) nel nuovo formato di wm.xml:

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

In alternativa, dal prompt di IoTCoreShell convertire usando convertpkg o buildpkg. L'output wm.xml file viene salvato nella stessa cartella.

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

Esaminare e testare i pacchetti wm.xml con buildpkg.

buildpkg.cmd MyPackage.wm.xml

Dopo aver convertito i file in formato wm.xml, è possibile eliminare i file pkg.xml.

Rigenerare i pacchetti dell'app

Usare il nuovoAppxPkg con lo stesso nome del componente. Questo rigenera il file di customizations.xml. Il numero di versione dell'appx viene mantenuto come numero di versione per ppkg.

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

Altre informazioni: Aggiungere app.

Aggiunta di file: watch out per file di dimensioni zero, percorsi relativi

I file di dimensioni zero non sono supportati in wm.xml. Per risolvere questo problema, aggiungere uno spazio vuoto nel file, rendendo il file di dimensioni non zero.

Percorsi: quando si aggiungono file nella directory corrente, è necessario aggiungere in modo esplicito il prefisso .\ al nome del file.

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

Altre informazioni: Aggiungere file

Aggiornare il pacchetto di provisioning customization.xml file

In ADK versione 1709 è necessario aggiornare il file di customizations.xml:

Nella cartella product\prov spostare manualmente Common/ApplicationManagement in Common/Policies/ApplicationManagement

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

I pacchetti di provisioning (PPKG) supportano ora il controllo delle versioni in quattro parti simile al controllo delle versioni del pacchetto. Quindi, con questa modifica, versione 1.19 > 1.2. Le versioni precedenti hanno usato l'ordinamento basato su caratteri, quindi la versione 1.19 è stata considerata precedente alla versione 1.2.

Altre informazioni: Aggiungere file di provisioning

Condividi tramite