Compartir a través de

Crear paquetes de OEM universales de Windows

  • Artículo

El estándar de empaquetado oem universal de Windows es compatible con Windows IoT Core, versión 1709.

Este nuevo esquema de empaquetado se ha creado para ser compatible con más tipos de dispositivos en el futuro. Si ha creado paquetes para dispositivos IoT Core mediante el estándar de empaquetado heredado (pkg.xml) y quiere usarlos en dispositivos IoT, puede convertirlos al nuevo estándar de empaquetado.

Paquetes

Los paquetes son los bloques de creación lógicos que se usan para crear imágenes de IoT Core.

  • Todo lo que agregue se empaqueta. Cada controlador, biblioteca, configuración del Registro, archivo del sistema y personalización que agregue al dispositivo se incluye en un paquete. El contenido y la ubicación de cada elemento se muestran en un archivo de definición de paquete (*.wm.xml).
  • Los partners de confianza pueden actualizar los paquetes. Cada paquete del dispositivo está firmado por usted o un asociado de confianza. Esto permite que los OEM, los OEM, los desarrolladores y Microsoft trabajen juntos para ayudar a ofrecer actualizaciones de seguridad y características a los dispositivos sin pisar el trabajo entre sí.
  • Los paquetes tienen versiones. Esto ayuda a facilitar las actualizaciones y hace que las restauraciones del sistema sean más confiables.

Un archivo de paquete de ejemplo (sample_pkg.cab) incluye un archivo de definición de paquete, contenido de paquete como aplicaciones, controladores y archivos, además de un archivo de firma y un número de versión.

Los paquetes se dividen en tres categorías principales:

  • Los paquetes del kit del sistema operativo contienen el sistema operativo Windows principal
  • Los paquetes creados previamente por el proveedor de SoC contienen controladores y firmware que admiten el conjunto de chips
  • Los paquetes OEM contienen controladores y personalizaciones específicos del dispositivo

Obtenga información sobre cómo combinar estos paquetes en imágenes para dispositivos.

Empiece por crear un nuevo paquete vacío

  1. Instale Windows ADK para Windows 10, versión 1709, así como las demás herramientas y certificados de prueba descritos en Obtención de las herramientas necesarias para personalizar Windows IoT Core y Lab 1a: Crear una imagen básica.

  2. Usa un editor de texto para crear un nuevo archivo de definición de paquete (también denominado archivo de manifiesto de Windows) basado en la siguiente plantilla. Guarde el archivo con la extensión 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>

  3. Cree el archivo de paquete vacío (*.cab). El nombre de archivo creado se basa en el propietario, el espacio de nombres y el nombre del archivo.

    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

Agregar contenido a un paquete

El contenido de un paquete se organiza como una lista de elementos XML en el archivo de definición de paquete.

En el ejemplo siguiente se muestra cómo agregar algunos archivos y la configuración del Registro a un paquete. En este ejemplo se define una variable (_RELEASEDIR) que se puede actualizar cada vez que se genera el paquete.

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

Ejecución de la herramienta de 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"

Ejemplo:

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

Adición de un componente de controlador

En el archivo de definición de paquete, use el elemento driver para insertar controladores. Se recomienda usar rutas de acceso relativas, ya que normalmente es la manera más sencilla de describir la ruta de acceso de origen inf.

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

Si la ruta de acceso de importación de archivos predeterminada no es igual a la ruta de acceso de origen INF, puede usar el atributo defaultImportPath. En el ejemplo siguiente, el INF está en el directorio actual, pero los archivos que se van a importar son relativos a $(_RELEASEDIR).

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

Si los archivos que se van a importar no son relativos a cómo se definen en INF, se pueden aplicar invalidaciones de archivo. Esto no se recomienda, pero está disponible para casos especiales.

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

Adición de un componente de servicio

En el archivo de definición de paquete, use el elemento de servicio (y sus elementos y atributos secundarios) para definir y empaquetar un servicio del 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"
      >

Compilar y filtrar paquetes WOW

Para compilar paquetes invitados o WOW (paquetes de 32 bits para ejecutarse en dispositivos de 64 bits) agregue el atributo 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"
    >

La ejecución de PkgGen.exe con ahora genera un paquete WOW para cada paquete 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

Normalmente, el dispositivo de 64 bits obtendrá su paquete host de 64 bits y su paquete invitado de 32 bits o WOW, ambos generados a partir de myPackage.wm.xml. Para evitar conflictos de recursos entre los dos paquetes, use filtros de compilación:

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

En este caso, las claves del Registro son exclusivas del paquete Arm host de 32 bits. El conmutador de CPU se usa para establecer build.arch y build.isWow lo establece PkgGen en false al compilar el paquete host de 32 bits y, a continuación, true al compilar el paquete invitado o WOW de 32 bits.

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

Conversión de paquetes oem universales de Windows

Si ha creado paquetes con el modelo de empaquetado de pkg.xml y quiere usarlos en Windows IoT Core, versión 1709, deberá volver a crear los paquetes o convertirlos mediante la herramienta pkggen.exe.

Después de convertir los paquetes, es posible que tenga que modificar el archivo wm.xml para asegurarse de que sigue el esquema.

Los complementos de IoT Core v4.x admiten el nuevo estándar de paquetes OEM universales de Windows (wm.xml). Este nuevo esquema de empaquetado se ha creado para ser compatible con más tipos de dispositivos en el futuro.

Convertir los archivos de paquete

Para convertir los paquetes existentes creados en el formato de empaquetado de teléfono heredado (pkg.xml) al nuevo formato de wm.xml:

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

O bien, desde el símbolo del sistema de IoTCoreShell, convierta mediante convertpkg o buildpkg. Los archivos wm.xml de salida se guardan en la misma carpeta.

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

Revise y pruebe los paquetes de wm.xml con buildpkg.

buildpkg.cmd MyPackage.wm.xml

Después de convertir los archivos en wm.xml formato, es seguro eliminar los archivos pkg.xml.

Regeneración de los paquetes de la aplicación

Use newAppxPkg con el mismo nombre de componente. Esto vuelve a generar el archivo customizations.xml. El número de versión de appx se conserva como el número de versión de ppkg.

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

Más información: Agregar aplicaciones.

Agregar archivos: watch para archivos de tamaño cero, rutas de acceso relativas

Los archivos de tamaño cero no se admiten en wm.xml. Para solucionarlo, agregue un espacio vacío en el archivo, lo que lo convierte en un archivo de tamaño distinto de cero.

Rutas de acceso: al agregar archivos que están en el directorio actual, deberá agregar explícitamente el prefijo .\ al nombre de archivo.

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

Más información: Agregar archivos

Actualización del archivo de customization.xml del paquete de aprovisionamiento

En ADK versión 1709, deberá actualizar el archivo customizations.xml:

En la carpeta product\prov, mueva manualmente Common/ApplicationManagement a Common/Policies/ApplicationManagement.

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

Los paquetes de aprovisionamiento (PPKG) ahora admiten el control de versiones de cuatro partes similar al control de versiones del paquete. Por lo tanto, con este cambio, versión 1.19 > 1.2. Las versiones anteriores usaban la ordenación basada en caracteres, por lo que la versión 1.19 se consideraba anterior a la 1.2.

Más información: Adición de archivos de aprovisionamiento