Создание универсальных пакетов OEM для Windows

Статья
10/04/2017

Стандарт упаковки windows Universal OEM поддерживается в Windows IoT Базовая версии 1709.

Эта новая схема упаковки будет совместима с другими типами устройств в будущем. Если вы создали пакеты для устройств IoT Core с использованием устаревшего стандарта упаковки (pkg.xml) и хотите использовать их на устройствах Интернета вещей, их можно преобразовать в новый стандарт упаковки.

Пакеты

Пакеты — это логические стандартные блоки, используемые для создания образов IoT Core.

Все, что вы добавляете, упаковается. Каждый драйвер, библиотека, параметр реестра, системный файл и настройки, добавляемые на устройство, включаются в пакет. Содержимое и расположение каждого элемента перечислены в файле определения пакета (*.wm.xml).
Пакеты могут обновляться доверенными партнерами. Каждый пакет на вашем устройстве подписывается вами или доверенным партнером. Это позволяет изготовителям оборудования, ODM, разработчикам и корпорации Майкрософт работать вместе, чтобы обеспечить безопасность и обновления компонентов на ваши устройства, не пытаясь работать друг с другом.
Пакеты имеют версию. Это упрощает обновление и повышает надежность восстановления системы.

Пример файла пакета (sample_pkg.cab) включает файл определения пакета, содержимое пакета, такие как приложения, драйверы и файлы, а также файл сигнатуры и номер версии.

Пакеты делятся на три main категории:

Пакеты комплекта ОС содержат базовую операционную систему Windows
Предварительно созданные пакеты поставщиков SoC содержат драйверы и встроенное ПО, поддерживающие набор микросхем.
Пакеты OEM содержат драйверы и настройки для конкретного устройства

Узнайте, как объединить эти пакеты в образы для устройств.

Начните с создания нового пустого пакета

Установите Windows ADK для Windows 10 версии 1709, а также другие средства и тестовые сертификаты, описанные в разделе Получение средств, необходимых для настройки Windows IoT Core и Лаборатории 1a: создание базового образа.
Используйте текстовый редактор для создания нового файла определения пакета (также называемого файлом манифеста Windows) на основе следующего шаблона. Сохраните файл с помощью расширения 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>
```

Создайте пустой файл пакета (*.cab). Созданное имя файла основано на владельце, пространстве имен и имени из файла.

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

Добавление содержимого в пакет

Содержимое пакета упорядочено в виде списка XML-элементов в файле определения пакета.

В следующем примере показано, как добавить некоторые файлы и параметры реестра в пакет. В этом примере определяется переменная (_RELEASEDIR), которую можно обновлять при каждом создании пакета.

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

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"

Пример

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

Добавление компонента драйвера

В файле определения пакета используйте элемент driver для внедрения драйверов. Рекомендуется использовать относительные пути, так как это, как правило, самый простой способ описания пути к источнику INF.

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

Если путь импорта файла по умолчанию не равен пути к источнику INF, можно использовать атрибут defaultImportPath. В следующем примере INF находится в текущем каталоге, но импортируемые файлы относятся к $(_RELEASEDIR).

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

Если импортируемые файлы не относятся к тому, как они определены в INF, можно применить переопределения файлов. Это не рекомендуется, но доступно для особых случаев.

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

Добавление компонента службы

В файле определения пакета используйте элемент service (и его дочерние элементы и атрибуты), чтобы определить и упаковать системную службу.

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

Сборка и фильтрация пакетов WOW

Чтобы создать гостевые пакеты или пакеты WOW (32-разрядные пакеты для запуска на 64-разрядных устройствах), добавьте атрибут 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"
    >

При выполнении PkgGen.exe с теперь создайте по одному пакету WOW для каждого пакета узла.

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

Как правило, 64-разрядное устройство получает 64-разрядный пакет узла и 32-разрядный пакет гостя или пакет WOW, созданные из myPackage.wm.xml. Чтобы избежать конфликтов ресурсов между двумя пакетами, используйте фильтры сборки:

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

В этом случае разделы реестра являются эксклюзивными для 32-разрядного пакета Arm узла. Коммутатор ЦП используется для задания build.arch, а параметр build.isWow задает значение false при сборке 32-разрядного пакета узла, а значение true — при сборке 32-разрядного гостевого пакета или пакета WOW.

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

Преобразование универсальных пакетов OEM для Windows

Если вы создали пакеты с помощью модели упаковки pkg.xml и хотите использовать их в Windows IoT Базовая версии 1709, необходимо либо повторно создать пакеты, либо преобразовать их с помощью средства pkggen.exe.

После преобразования пакетов может потребоваться изменить файл wm.xml, чтобы убедиться, что он соответствует схеме.

Надстройки IoT Core версии 4.x поддерживают новый стандарт универсальных пакетов OEM Windows (wm.xml). Эта новая схема упаковки будет совместима с другими типами устройств в будущем.

Преобразование файлов пакета

Чтобы преобразовать существующие пакеты, созданные в устаревшем формате упаковки телефона (pkg.xml), в новый формат wm.xml:

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

Или в командной строке IoTCoreShell выполните преобразование с помощью convertpkg или buildpkg. Выходные wm.xml файлы сохраняются в той же папке.

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

Просмотрите и протестируйте пакеты wm.xml с помощью buildpkg.

buildpkg.cmd MyPackage.wm.xml

После преобразования файлов в формат wm.xml можно безопасно удалить файлы pkg.xml.

Повторное создание пакетов приложений

Используйте newAppxPkg с тем же именем компонента. При этом повторно создается файл customizations.xml. Номер версии appx сохраняется в качестве номера версии для ppkg.

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

Дополнительные сведения см. в разделе Добавление приложений.

Добавление файлов: watch для файлов нулевого размера, относительные пути

Файлы нулевого размера не поддерживаются в wm.xml. Чтобы обойти эту проблему, добавьте пустое место в файл, что делает его файлом ненулевых размеров.

Пути. При добавлении файлов, которые находятся в текущем каталоге, необходимо явно добавить префикс .\ к имени файла.

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

Дополнительные сведения: Добавление файлов

Обновление файла customization.xml пакета подготовки

В ADK версии 1709 необходимо обновить файл customizations.xml:

В папке product\prov вручную переместите Common/ApplicationManagement в раздел Common/Policies/ApplicationManagement.

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

Пакеты подготовки (PPKG) теперь поддерживают управление версиями из четырех частей, аналогичное управлением версиями пакетов. Таким образом, с этим изменением, версия 1.19 > 1.2. В предыдущих версиях использовалась сортировка на основе символов, поэтому версия 1.19 считалась более ранней, чем 1.2.

Дополнительные сведения: Добавление файлов подготовки

Поделиться через