Créer des schémas de packages OEM universels Windows

Article
10/04/2017

La norme d’empaquetage OEM universel Windows est prise en charge sur Windows IoT Core, version 1709.

Ce nouveau schéma d’empaquetage est conçu pour être compatible avec d’autres types d’appareils à l’avenir. Si vous avez créé des packages pour des appareils IoT Core à l’aide de la norme d’empaquetage héritée (pkg.xml) et que vous souhaitez les utiliser sur des appareils IoT, vous pouvez les convertir en nouvelle norme d’empaquetage.

Paquets

Les packages sont les blocs de construction logiques utilisés pour créer des images IoT Core.

Tout ce que vous ajoutez est empaqueté. Chaque pilote, bibliothèque, paramètre de Registre, fichier système et personnalisation que vous ajoutez à l’appareil est inclus dans un package. Le contenu et l’emplacement de chaque élément sont répertoriés dans un fichier de définition de package (*.wm.xml).
Les packages peuvent être mis à jour par des partenaires approuvés. Chaque package sur votre appareil est signé par vous-même ou un partenaire de confiance. Cela permet aux oem, aux ODM, aux développeurs et à Microsoft de travailler ensemble pour fournir des mises à jour de sécurité et de fonctionnalités à vos appareils sans s’arrêter sur le travail des uns et des autres.
Les packages sont versionnés. Cela facilite les mises à jour et rend les restaurations système plus fiables.

Un exemple de fichier de package (sample_pkg.cab) inclut un fichier de définition de package, le contenu du package comme les applications, les pilotes et les fichiers, ainsi qu’un fichier de signature et un numéro de version

Les packages se répartissent en trois catégories main :

Les packages du kit de système d’exploitation contiennent le système d’exploitation Windows principal
Les packages prédéfinis du fournisseur de SoC contiennent des pilotes et des microprogrammes qui prennent en charge le chipset
Les packages OEM contiennent des pilotes et des personnalisations spécifiques aux appareils

Découvrez comment combiner ces packages en images pour les appareils.

Commencez par créer un package vide

Installez Windows ADK pour Windows 10, version 1709, ainsi que les autres outils et certificats de test décrits dans Obtenir les outils nécessaires pour personnaliser Windows IoT Core et Lab 1a : Créer une image de base.

Utilisez un éditeur de texte pour créer un fichier de définition de package (également appelé fichier manifeste Windows) basé sur le modèle suivant. Enregistrez le fichier à l’aide de l’extension 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>

Créez le fichier de package vide (*.cab). Le nom de fichier créé est basé sur le propriétaire, l’espace de noms et le nom du fichier.

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

Ajouter du contenu à un package

Le contenu d’un package est organisé sous la forme d’une liste d’éléments XML dans le fichier de définition de package.

L’exemple suivant montre comment ajouter certains fichiers et paramètres de Registre à un package. Cet exemple définit une variable (_RELEASEDIR) qui peut être mise à jour chaque fois que vous générez le package.

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

Exécuter l’outil pkggen.exe

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"

Exemple :

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

Ajouter un composant de pilote

Dans le fichier de définition de package, utilisez l’élément pilote pour injecter des pilotes. Nous vous recommandons d’utiliser des chemins relatifs, car il s’agit généralement du moyen le plus simple de décrire le chemin de la source INF.

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

Si le chemin d’importation de fichier par défaut n’est pas égal au chemin de la source INF, vous pouvez utiliser l’attribut defaultImportPath. Dans l’exemple suivant, le fichier INF se trouve dans le répertoire actif, mais les fichiers à importer sont relatifs à $(_RELEASEDIR).

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

Si les fichiers à importer ne sont pas relatifs à la façon dont ils sont définis dans l’INF, des remplacements de fichiers peuvent être appliqués. Cette option n’est pas recommandée, mais elle est disponible pour les cas spéciaux.

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

Ajouter un composant de service

Dans le fichier de définition de package, utilisez l’élément de service (ainsi que ses éléments et attributs enfants) pour définir et empaqueter un service système.

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

Générer et filtrer des packages WOW

Pour générer des packages Guest ou WOW (packages 32 bits à exécuter sur des appareils 64 bits), ajoutez l’attribut buildWow="true » à 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"
    >

L’exécution de PkgGen.exe avec génère désormais un package WOW pour chaque package hôte.

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

En règle générale, l’appareil 64 bits obtient son package Host 64 bits et son package Invité 32 bits ou WOW, tous deux générés à partir de myPackage.wm.xml. Pour éviter les conflits de ressources entre les deux packages, utilisez des filtres de génération :

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

Dans ce cas, les clés de Registre sont exclusives au package Arm 32 bits hôte. Le commutateur d’UC est utilisé pour définir build.arch, et build.isWow est défini par PkgGen sur false lors de la génération du package hôte 32 bits, puis sur true lors de la génération du package Invité ou WOW 32 bits.

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

Conversion des packages OEM universels Windows

Si vous avez créé des packages à l’aide du modèle d’empaquetage pkg.xml et que vous souhaitez les utiliser sur Windows IoT Core, version 1709, vous devez recréer vos packages ou les convertir à l’aide de l’outil pkggen.exe.

Après avoir converti les packages, vous devrez peut-être modifier le fichier wm.xml pour vous assurer qu’il suit le schéma.

Les modules complémentaires IoT Core v4.x prennent en charge les nouveaux packages OEM windows universels standard (wm.xml). Ce nouveau schéma d’empaquetage est conçu pour être compatible avec d’autres types d’appareils à l’avenir.

Convertir vos fichiers de package

Pour convertir vos packages existants créés au format d’empaquetage de téléphone hérité (pkg.xml) au nouveau format wm.xml :

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

Ou, à partir de l’invite IoTCoreShell, convertissez à l’aide de convertpkg ou buildpkg. La sortie wm.xml fichiers sont enregistrés dans le même dossier.

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

Passez en revue et testez les packages wm.xml avec buildpkg.

buildpkg.cmd MyPackage.wm.xml

Une fois que vous avez converti les fichiers au format wm.xml, vous pouvez supprimer les fichiers pkg.xml en toute sécurité.

Régénérer vos packages d’application

Utilisez newAppxPkg avec le même nom de composant. Cela régénère le fichier customizations.xml. Le numéro de version de l’appx est conservé comme numéro de version pour ppkg.

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

En savoir plus : Ajouter des applications.

Ajout de fichiers : watch pour les fichiers de taille zéro, les chemins relatifs

Les fichiers de taille zéro ne sont pas pris en charge dans wm.xml. Pour contourner ce problème, ajoutez un espace vide dans le fichier, ce qui en fait un fichier de taille différente de zéro.

Chemins d’accès : lorsque vous ajoutez des fichiers qui se trouvent dans le répertoire actif, vous devez ajouter explicitement le préfixe .\ au nom du fichier.

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

En savoir plus : Ajouter des fichiers

Mettre à jour votre fichier de customization.xml package d’approvisionnement

Dans ADK version 1709, vous devez mettre à jour le fichier customizations.xml :

Dans votre dossier product\prov, déplacez manuellement Common/ApplicationManagement vers Common/Policies/ApplicationManagement

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

Les packages d’approvisionnement (PPKG) prennent désormais en charge le contrôle de version en quatre parties, comme le contrôle de version des packages. Donc, avec cette modification, version 1.19 > 1.2. Les versions précédentes utilisaient le tri basé sur les caractères. La version 1.19 a donc été considérée comme antérieure à la version 1.2.

En savoir plus : Ajouter des fichiers d’approvisionnement

Partager via