Windows 유니버설 OEM 패키지 만들기
Windows 유니버설 OEM 패키징 표준은 Windows IoT Core 버전 1709에서 지원됩니다.
이 새로운 패키징 스키마는 나중에 더 많은 유형의 디바이스와 호환될 수 있도록 빌드되었습니다. 레거시 패키징 표준(pkg.xml)을 사용하여 IoT Core 디바이스용 패키지를 빌드했으며 IoT 디바이스에서 사용하려는 경우 새 패키징 표준으로 변환할수 있습니다.
패키지
패키지는 IoT Core 이미지를 만드는 데 사용되는 논리적 구성 요소입니다.
- 추가하는 모든 것이 패키지됩니다. 디바이스에 추가하는 모든 드라이버, 라이브러리, 레지스트리 설정, 시스템 파일 및 사용자 지정은 패키지에 포함됩니다. 각 항목의 내용과 위치는 패키지 정의 파일(*.wm.xml)에 나열됩니다.
- 신뢰할 수 있는 파트너가 패키지를 업데이트할 수 있습니다. 디바이스의 모든 패키지는 사용자 또는 신뢰할 수 있는 파트너가 서명합니다. 이렇게 하면 OEM, ODM, 개발자 및 Microsoft가 함께 작동하여 서로의 작업을 방해하지 않고도 디바이스에 보안 및 기능 업데이트를 제공할 수 있습니다.
- 패키지의 버전은 입니다. 이렇게 하면 업데이트가 더 쉬워지고 시스템 복원의 안정성이 높아집니다.
패키지는 다음 세 가지 주요 범주로 나뉩니다.
- OS 키트 패키지에는 핵심 Windows 운영 체제가 포함되어 있습니다.
- SoC 공급업체 미리 구성된 패키지에는 칩셋을 지원하는 드라이버 및 펌웨어가 포함되어 있습니다.
- OEM 패키지에는 디바이스별 드라이버 및 사용자 지정이 포함되어 있습니다.
이러한 패키지를 디바이스용 이미지로 결합하는 방법에 대해 알아봅니다.
비어 있는 새 패키지를 만들어 시작합니다.
Windows 10, 버전 1709용 Windows ADK 및 IoT Core 및 랩 1a를사용자 Windows 지정하는 데 필요한 도구 얻기: 기본 이미지 만들기에 설명된 다른 도구 및 테스트 인증서를 설치합니다.
텍스트 편집기를 사용하여 다음 템플릿을 기반으로 새 패키지 정의 파일(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"
드라이버 구성 요소 추가
패키지 정의 파일에서 드라이버 요소를 사용하여 드라이버를 삽입합니다. 일반적으로 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
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 패키지(64비트 디바이스에서 실행할 32비트 패키지)를 빌드하려면 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 패키지에만 해당됩니다. CPU 스위치는 build.arch를 설정하는 데 사용되며, 32비트 호스트 패키지를 빌드할 때 pkgGen에서 build.isWow를 false로 설정한 다음, 32비트 게스트 또는 WOW 패키지를 빌드할 때 true로 설정됩니다.
[cpu]··············· CPU type. Values: (x86|arm|arm64|amd64)
Values:<Free Text> Default="arm"
Windows 유니버설 OEM 패키지 변환
pkg.xml 패키징 모델을 사용하여 패키지를 만들고 Windows IoT Core 버전 1709에서 사용하려는 경우 패키지를 다시 만들거나 pkggen.exe 도구를 사용하여 변환해야 합니다.
패키지를 변환한 후 wm.xml 파일을 수정하여 스키마를따르는지 확인해야 할 수 있습니다.
IoT Core 추가 기능 v4.x는 새로운 Windows wm.xml(유니버설 OEM 패키지 표준) 을 지원합니다. 이 새로운 패키징 스키마는 나중에 더 많은 유형의 디바이스와 호환될 수 있도록 빌드되었습니다.
패키지 파일 변환
레거시 휴대폰 패키징 형식(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
buildpkg를 wm.xml 패키지를 검토하고 테스트합니다.
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
자세한 정보: 앱 추가.
파일 추가: 크기가 0인 파일, 상대 경로에 주의
크기가 0인 파일은 wm.xml 지원되지 않습니다. 이 작업을 수행하려면 파일에 빈 공간을 추가하여 크기가 0이 아닌 파일로 만듭니다.
경로: 현재 디렉터리에 있는 파일을 추가할 때 파일 ’’ 이름에 .\ 접두사 를 명시적으로 추가해야 합니다.
<BinaryPartition ImageSource=".\uefi.mbn" />
자세한 정보: 파일 추가
프로비전 패키지 customization.xml 파일 업데이트
ADK 버전 1709에서는 ’’ 파일을 업데이트해야 합니다.
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 이전 버전으로 간주되었습니다.
자세한 정보: 프로비전 파일 추가