Criar pacotes universais do OEM no Windows

Artigo
10/04/2017

O padrão de empacotamento OEM Universal do Windows tem suporte no Windows IoT Core, versão 1709.

Esse novo esquema de empacotamento é criado para ser compatível com mais tipos de dispositivos no futuro. Se você tiver criado pacotes para dispositivos IoT Core usando o padrão de empacotamento herdado (pkg.xml) e quiser usá-los em dispositivos IoT, poderá convertê-los no novo padrão de empacotamento.

Pacotes

Os pacotes são os blocos de construção lógicos usados para criar imagens do IoT Core.

Tudo o que você adiciona é empacotado. Cada driver, biblioteca, configuração do Registro, arquivo do sistema e personalização que você adiciona ao dispositivo são incluídos em um pacote. O conteúdo e o local de cada item são listados em um arquivo de definição de pacote (*.wm.xml).
Os pacotes podem ser atualizados por parceiros confiáveis. Cada pacote em seu dispositivo é assinado por você ou por um parceiro confiável. Isso permite que OEMs, ODMs, desenvolvedores e Microsoft trabalhem juntos para ajudar a fornecer atualizações de segurança e recursos para seus dispositivos sem pisar no trabalho uns dos outros.
Os pacotes são versões. Isso ajuda a facilitar as atualizações e torna as restaurações do sistema mais confiáveis.

Um arquivo de pacote de exemplo (sample_pkg.cab) inclui um arquivo de definição de pacote, conteúdo do pacote, como aplicativos, drivers e arquivos, além de um arquivo de assinatura e um número de versão

Os pacotes se enquadram em três categorias de main:

Os pacotes do kit do sistema operacional contêm o sistema operacional Windows principal
Os pacotes predefinidos do fornecedor soC contêm drivers e firmware que dão suporte ao chipset
Os pacotes OEM contêm drivers e personalizações específicos do dispositivo

Saiba mais sobre como combinar esses pacotes em imagens para dispositivos.

Comece criando um novo pacote vazio

Instale o Windows ADK para Windows 10, versão 1709, bem como as outras ferramentas e certificados de teste descritos em Obter as ferramentas necessárias para personalizar o Windows IoT Core e o Lab 1a: Criar uma imagem básica.

Use um editor de texto para criar um novo arquivo de definição de pacote (também chamado de arquivo de manifesto do Windows) com base no modelo a seguir. Salve o arquivo usando a extensão 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>

Crie o arquivo de pacote vazio (*.cab). O nome do arquivo criado é baseado no proprietário, no namespace e no nome do arquivo.

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

Adicionar conteúdo a um pacote

O conteúdo de um pacote é organizado como uma lista de elementos XML no arquivo de definição de pacote.

O exemplo a seguir demonstra como adicionar alguns arquivos e configurações do Registro a um pacote. Este exemplo define uma variável (_RELEASEDIR) que pode ser atualizada sempre que você gera o pacote.

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

Executar a ferramenta pkggen.exe

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

Exemplo:

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

Adicionar um componente de driver

No arquivo de definição de pacote, use o elemento driver para injetar drivers. É recomendável usar caminhos relativos, pois normalmente é a maneira mais simples de descrever o caminho de origem inf.

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

Se o caminho de importação de arquivo padrão não for igual ao caminho de origem INF, você poderá usar o atributo defaultImportPath. No exemplo a seguir, o INF está no diretório atual, mas os arquivos a serem importados são relativos a $(_RELEASEDIR).

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

Se os arquivos a serem importados não forem relativos à forma como são definidos no INF, as substituições de arquivo poderão ser aplicadas. Isso não é recomendado, mas está disponível para casos especiais.

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

Adicionar um componente de serviço

No arquivo de definição de pacote, use o elemento de serviço (e seus elementos e atributos filho) para definir e empacotar um serviço do 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"
      >

Criar e filtrar pacotes WOW

Para criar pacotes Convidado ou WOW (pacotes de 32 bits a serem executados em dispositivos de 64 bits) adicione o atributo buildWow="true" ao 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"
    >

A execução PkgGen.exe com agora gera um pacote WOW para cada pacote de 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, o dispositivo de 64 bits receberá seu pacote host de 64 bits e seu pacote Convidado de 32 bits ou WOW, ambos gerados de myPackage.wm.xml. Para evitar conflitos de recursos entre os dois pacotes, use filtros de build:

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

Nesse caso, as chaves do Registro são exclusivas do pacote Arm de 32 bits do Host. O comutador de CPU é usado para definir build.arch e build.isWow é definido por PkgGen como false ao compilar o Pacote de Host de 32 bits e, em seguida, true ao compilar o pacote Convidado ou WOW de 32 bits.

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

Convertendo pacotes OEM universais do Windows

Se você criou pacotes usando o modelo de empacotamento pkg.xml e deseja usá-los no Windows IoT Core, versão 1709, precisará recriar seus pacotes ou convertê-los usando a ferramenta pkggen.exe.

Depois de converter os pacotes, talvez seja necessário modificar o arquivo wm.xml para garantir que ele siga o esquema.

Os complementos do IoT Core v4.x dão suporte ao novo padrão de Pacotes OEM Universais do Windows (wm.xml). Esse novo esquema de empacotamento é criado para ser compatível com mais tipos de dispositivos no futuro.

Converter seus arquivos de pacote

Para converter seus pacotes existentes criados no formato de empacotamento de telefone herdado (pkg.xml) no novo formato de wm.xml:

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

Ou, no prompt do IoTCoreShell, converta usando convertpkg ou buildpkg. Os arquivos de wm.xml de saída são salvos na mesma pasta.

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

Examine e teste os pacotes de wm.xml com buildpkg.

buildpkg.cmd MyPackage.wm.xml

Depois de converter os arquivos em formato wm.xml, é seguro excluir os arquivos pkg.xml.

Regenerar seus pacotes de aplicativos

Use o newAppxPkg com o mesmo nome de componente. Isso regenera o arquivo customizations.xml. O número de versão do appx é mantido como o número de versão para ppkg.

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

Saiba mais: Adicionar aplicativos.

Adicionando arquivos: watch para arquivos de tamanho zero, caminhos relativos

Não há suporte para arquivos de tamanho zero em wm.xml. Para contornar isso, adicione um espaço vazio no arquivo, tornando-o um arquivo de tamanho diferente de zero.

Caminhos: ao adicionar arquivos que estão no diretório atual, você precisará adicionar explicitamente o prefixo .\ ao nome do arquivo.

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

Saiba mais: Adicionar arquivos

Atualizar seu pacote de provisionamento customization.xml arquivo

No ADK versão 1709, você precisará atualizar o arquivo customizations.xml:

Na pasta product\prov, mova manualmente Common/ApplicationManagement para Common/Policies/ApplicationManagement

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

Os PPKG (pacotes de provisionamento) agora dão suporte ao controle de versão de quatro partes semelhante ao controle de versão do pacote. Portanto, com essa alteração, versão 1.19 > 1.2. As versões anteriores usavam classificação baseada em caracteres, portanto, a versão 1.19 era considerada anterior à 1.2.

Saiba mais: Adicionar arquivos de provisionamento

Compartilhar via