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용 Windows ADK 버전 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 [프로젝트] /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는 현재 디렉터리에 있지만 가져올 파일은 $(_RELEASEEDIR)에 상대적입니다.
<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비트 패키지)를 빌드하려면 myPackage.wm.wml에 buildWow="true" 특성을 추가합니다.
<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를 설정하는 데 사용되며 build.isWow는 32비트 호스트 패키지를 빌드할 때 PkgGen에 의해 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 유니버설 OEM 패키지 표준(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
buildpkg를 사용하여 wm.xml 패키지를 검토하고 테스트합니다.
buildpkg.cmd MyPackage.wm.xml
파일을 wm.xml 형식으로 변환한 후에는 package.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에서는 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보다 이전 버전으로 간주되었습니다.
자세히 알아보기: 프로비저닝 파일 추가