Criar pacotes universais do OEM no Windows
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.
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.
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.
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
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>
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"
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>
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"
>
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"
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.
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.
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.
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
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