ラボ 1g: 製品イメージのビルド

[アーティクル]
10/15/2018

ここでは、Windows IoT Core の製品イメージを作成し、特定のハードウェアデバイスにフラッシュするために必要な手順について詳しく説明します。

前提条件または要件

基本イメージの作成に関するページとこれまでに完了したすべてのラボに従って基本イメージを作成したことを確認してください。

このセクションを完了するには、次のツールがインストールされている必要があります。

リテールコードサイニング証明書
クロスサイニング証明書
Visual Studio
Windows アセスメント & デプロイメントキット (Windows ADK)
IoT Core PowerShell 環境
メモ帳や VS Code などのテキストエディター

プロジェクト構成ファイルを変更する

次の手順に従って、製品イメージに追加するカスタムアプリケーションまたはプロビジョニングパッケージを追加します。

カスタムアプリケーションを追加するには、イメージへのアプリの追加に関するページに示されている手順に従う必要があります。ただし、ここで示すように、Add-IoTProductFeature コマンドを実行する場合は、Test の代わりに Retail を指定します。

Add-IoTProductFeature ProductX Retail APPX_HELLOWORLDAPP -OEM
or addfid ProductX Retail APPX_HELLOWORLDAPP -OEM

これにより、APPX_HELLOWORLDAPP という FeatureID が指定した製品の Retail OEMInput XML ファイルに追加されます。

組み込まれる Windows IoT Core 機能は最小限にします。 Windows IoT Core のテストイメージと共に (既定で) 含まれているすべてのテストアプリケーションも削除します。これには、IoT Core の既定のアプリケーションに加えて、他の開発者ツールやテスト機能も含まれます。これは、Remove-IoTProductFeature を使用して行うことができます。

Remove-IoTProductFeature ProductX Test IOT_BERTHA
or removefid ProductX Test IOT_BERTHA

アプリケーションに適切に署名して組み込む

Wiindows IoT Core の製品イメージに組み込む 1 つ以上のカスタムアプリケーションがある場合は、製品イメージに組み込むときにこれらのアプリケーションが適切に署名されていることを確認する必要があります。イメージに組み込むアプリケーションごとに、次の手順を実行します。組み込むアプリケーションが 1 つしかない場合は、手順 8. と 9. を省略できることにご注意ください。

テクニシャン PC にリテールコード署名証明書をインストールします。
Visual Studio でカスタムアプリケーションを開き、Package.appxmanifest ファイルを開きます。
[Packaging](パッケージ) タブをクリックし、[証明書の選択...] ボタンをクリックします。

パッケージマニフェスト画面

表示されるダイアログには、コード署名にどの証明書が使用されているかが表示されます。 [証明書の構成...] ドロップダウンをクリックし、[Pick from certificate store...](証明書ストアから選択...) を選びます。

証明書の選択画面

プロンプトが表示されたらリテールコード署名証明書を選び、[OK] をクリックします。
Visual Studio でプロジェクトを保存し、Appx パッケージをビルドします。このパッケージをビルドするときに、リテールコード署名証明書のパスワードの入力を求められることにご注意ください。
Appx ファイルがビルドされたら、IoT Core Powershell 環境で次のコマンドを実行します。

Add-IoTAppxPackage "C:\Dev\OpenSource\ContosoApp\ContosoApp\AppPackages\ContosoApp_1.0.0.0_ARM_Debug_Test\ContosoApp_1.0.0.0_ARM_Debug.appx" fga Appx.ContosoApp
 (or) newAppxPkg "C:\Dev\OpenSource\ContosoApp\ContosoApp\AppPackages\ContosoApp_1.0.0.0_ARM_Debug_Test\ContosoApp_1.0.0.0_ARM_Debug.appx" fga Appx.ContosoApp

製品イメージファイルをビルドする

すべてのカスタムアプリケーションパッケージが正常に署名されたら、Windows IoT Core 製品イメージをビルドできるようになります。次の手順を実行する前に、お使いの PC にリテールコード署名証明書がインストールされていることを確認してください。

お使いの証明書とクロス証明書の詳細が含まれるように、IoT 署名を設定します。これは、ワークスペース (例: C:\MyWorkspace) にある IoTWorkspace.xml ファイルを変更することで行います。

<!--Specify the retail signing certificate details, Format given below -->
<RetailSignToolParam>/s my /sha1 "thumbprint" /fd SHA256 /ac "c:\DownloadedCrossCert.crt"</RetailSignToolParam>

管理者として、IoT Core PowerShell 環境を実行します。
リテール署名用の環境を設定します。これは Set-IoTRetailSign を使用して行います。

Set-IoTRetailSign On
(or) retailsign on

パッケージをビルドします。

New-IoTCabPackage All
(or) buildpkg all

すべてのパッケージ .CAB ファイルがビルドされたら、これらの各ファイルがリテール証明書を使用して適切に署名されていることを確認する必要があります。一部がまだテスト証明書を使用して署名されている場合は (これは通常、テクニシャン PC をテストと製品の両方のイメージのビルドに使用している場合に発生します)、Redo-IoTCabSignature を使用してこれらのファイルに再署名できます。

Redo-IoTCabSignature  C:\BSP.IN C:\BSP.OUT
(or) re-sign.cmd C:\BSP.IN C:\BSP.OUT

これにより、.CAB ファイルを c:\BSP.IN から取得し、リテール証明書を使用して再署名して c:\BSP.OUT ディレクトリにコピーします。

ステップ 5. の .CAB ファイルに再署名した場合は、再署名した .CAB ファイルを C:\IoT\Workspaces\ContosoWS\Build\<arch>\pkgs にコピーして既存のファイルを上書きします。この例では、これらのファイルが C:\IoT\Workspaces\ContosoWS\Build\arm\pkgs にコピーされます。
以下のコマンドを実行して、製品イメージをビルドします。

New-IoTFFUImage ProductX Retail
(or)buildimage ProductX Retail

その後、イメージのフラッシュに関するページの説明に従って製品イメージをフラッシュできます。

使用されるコマンド

IoT Core の製品イメージを作成するためのコマンドを次に (順序どおりに) 示します。最初にリテールコード署名証明書をインストールする必要があることと、.CAB ファイルに再署名するときに証明書のパスワードの入力を求められる場合があることにご注意ください。

Set-IoTRetailSign On
New-IoTCabPackage All
Redo-IoTCabSignature  C:\BSP.IN C:\BSP.OUT
xcopy C:\BSP.OUT\*.cab C:\IoT\Workspaces\ContosoWS\Build\arm\pkgs\*.cab
New-IoTFFUImage ProductX Retail

リテール構成に機能を追加する

Add-IoTProductFeature を使用して、製品のリテール構成ファイルを更新します

# Add application features
Add-IoTProductFeature ProductA Test APPX_MYUWPAPP -OEM
Remove-IoTProductFeature ProductA Test IOT_BERTHA
# Add registry and file features
Add-IoTProductFeature ProductA Retail FILES_CONFIGS -OEM
Add-IoTProductFeature ProductA Retail REGISTRY_SETTINGS -OEM
# Add provisioning feature
Add-IoTProductFeature ProductA Retail PROV_WIFISETTINGS -OEM
# Add driver
Add-IoTProductFeature ProductA Retail DRIVERS_HELLOBLINKY -OEM

製品イメージを確認する

ユーザーは、デバイス上でイメージをフラッシュしてデバイスの電源をオンにするだけで、Windows IoT Core のカスタムテストイメージを簡単に確認できます。デバイスが実行されたら、さまざまなチェックを実行して、デバイスが本当に機能していることを確認できます。これらのテストの容易さは、イメージに組み込まれているセキュリティ要素のレベルによって決まります。テストイメージにはセキュリティプロトコルが組み込まれていないため、使用可能なすべての開発ツールを使用して IoT デバイスをテストできます。

デバイスにインストールされているイメージの一部としてセキュリティプロトコルを含めることができるため、Windows IoT Core のカスタム製品イメージではテストのタスクが難しくなります。これらのセキュリティプロトコルの性質により、使用可能なテストツールを使用してデバイスを確認できないことがあるため、IoT デバイスで実行できるテストアプリケーションの作成が必要になる場合があります。このアプリケーションでは、IoT デバイスのさまざまな領域と機能の検証テストを実行します。

Windows IoT Core のカスタム製品イメージのテストは、次のいずれかの方法で行うことができます。

クリーンな製品イメージ

クリーンな製品イメージが必要な場合は、デバイス用に 2 つの製品イメージを作成する必要があります。この 2 つのイメージは同じものですが、一方のイメージにはテストアプリケーション (フォアグラウンドアプリケーションとして構成されている) が含まれ、もう一方の "クリーン" イメージには含まれません。 (テストアプリケーションを含む) 最初のイメージをフラッシュし、IoT デバイス上でテスト検証を実行します。検証が完了したら、2 番目の "クリーンな" 製品イメージを使用して IoT デバイスを配布用に再フラッシュできます。

長所: 最終的な製品イメージは完全にクリーンになり、必要と思われる項目のみがイメージに含まれます。

短所: テストアプリケーションを製品イメージに含めると、プロビジョニングパッケージに潜在的な問題が導入される可能性や、テストアプリケーション内で潜在的なユーザーエラーが発生する可能性があります。これにより、この製品イメージが最終的な製品イメージと異なるものになります。

1 回限りのパススルーテスト

最終的な製品イメージは 1 つだけ作成され、テストアプリケーションも含まれます。このイメージは、out-of-box-experience (OOBE) アプリケーションが起動されるとテストアプリケーションが (フォアグラウンドアプリケーションとして) 起動されるように構成します。テストアプリケーションが前に 1 回実行されたことを認識するようにアプリケーション内の条件付きステートメントがトリガーされます (これにより、デバイスの初回電源オンより後に実行されることを防ぎます)。

// Declare variable
Windows.Storage.ApplicationDataContainer localSettings = 
    Windows.Storage.ApplicationData.Current.LocalSettings;
    
// Set variable as boolean, numbers, or string values as needed at approperiate location within the test app
localSettings.Values["appRanOnce"] = false;    

// Read variable and verify value to check and apply logic
Object value = localSettings.Values["appRanOnce"];

Note

最適な結果を得るために、設定値を格納する変数の格納には localSettings のみを使用します。 roamingSettings 機能を使用すると望ましくない結果が発生する可能性があります。 localSettings は、この書き込み時には、64k のデータしか保持できません。アプリケーション設定の詳細は、こちらを参照してください。

上記のコードブロックを使用して、テストアプリケーションの起動時にロジックを適用することで、次回以降の起動時にアプリケーションによって適切なアクションが実行されるようにすることができます。

実行できるアクションの種類

別の FGA アプリを起動する
レジストリを編集してブートシーケンスを変更する

テストアプリケーションからの別の FGA アプリケーションの起動

Microsoft ストアアプリを起動している場合は、次のコードスニペットを使用して、ストアを通じてインストールおよび更新されたアプリを起動できます。 URI スキーマの追加情報については、こちらを参照してください。

// Following will launch the Microsoft store app and navigate to the Games section
bool result = await Windows.System.Launcher.LaunchUriAsync(new Uri
    ("ms-windows-store://navigatetopage/?Id=Games"));

// Following will launch the One Note app using the package family name (PFN)
bool result = await Windows.System.Launcher.LaunchUriAsync(new Uri
    ("ms-windows-store://pdp/?PFN= Microsoft.Office.OneNote_8wekyb3d8bbwe"));

カスタム (Microsoft ストア以外) のアプリを起動する場合は、AppServiceConnection を使用し、パッケージファミリ名 (PFN) を使用してアプリを起動できます。

最初に、最終的なアプリ (com.concurrency.lwinsapp) をシステム内のアプリサービスに登録する必要があります。 Package.appxmanifest file を変更して、マニフェストの <Applications> セクションに次のコードブロックを含める必要があります。

<Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="AppServiceProvider.App">
      <Extensions>
        <uap:Extension Category="windows.appService" EntryPoint="MyAppService.AppLaunchService">
          <uap3:AppService Name="com.concurrency.lwinsapp" uap4:SupportsMultipleInstances="true" />
        </uap:Extension>
      </Extensions>
      ...
</Application>

次のコードセグメントでは、カスタムアプリケーションが起動されます。

private AppServiceConnection appLaunchService;
...
this.appLaunchService = new AppServiceConnection();
this.appLaunchService.AppServiceName = "com.concurrency.lwinsapp";
this.appLaunchService.PackageFamilyName = "f3a114f7-e099-4773-8c93-77abcba14f62_004hcn5rxyy0y";
var status = await this.appLaunchService.OpenAsync();

localSettings と AppServiceConnection の間でロジックを結合することで、デバイスの起動のたびにテストアプリケーションをバイパスできます。基本的に、テストアプリケーションは毎回起動時に実行されますが、起動時に最終的なアプリケーションに "パススルー" されます。必要に応じて、テストアプリケーションでテストが失敗した場合に、デバイスが最終的なアプリケーションに進まないようにロジックを設定できます。これは、毎回起動時にデバイスが完全にテストされ、機能していることを確認する必要がある場合に役立つ可能性があります。

長所: 毎回起動時にデバイスを自動的にテストして、特定の条件が正しく設定され、デバイスが完全にテストされている (そしてセキュリティで保護されている) ことを確認できます。

短所: テストアプリケーションが製品イメージに含まれます。アプリケーションにはセキュリティホールがある可能性があります。必要に応じてテストアプリがロックダウンされることを確認してください。テストアプリケーションの性質により、デバイスの機能を変更できる場合があります。

次のステップ

ラボ 2: 独自のボードサポートパッケージの作成

次の方法で共有

ラボ 1g: 製品イメージのビルド

前提条件または要件

プロジェクト構成ファイルを変更する

アプリケーションに適切に署名して組み込む

製品イメージファイルをビルドする

使用されるコマンド

リテール構成に機能を追加する

製品イメージを確認する

クリーンな製品イメージ

1 回限りのパススルーテスト

テストアプリケーションからの別の FGA アプリケーションの起動

次のステップ

その他のリソース

次の方法で共有

ラボ 1g: 製品イメージのビルド

前提条件または要件

プロジェクト構成ファイルを変更する

アプリケーションに適切に署名して組み込む

製品イメージ ファイルをビルドする

使用されるコマンド

リテール構成に機能を追加する

製品イメージを確認する

クリーンな製品イメージ

1 回限りのパススルー テスト

テスト アプリケーションからの別の FGA アプリケーションの起動

次のステップ

その他のリソース

製品イメージファイルをビルドする

1 回限りのパススルーテスト

テストアプリケーションからの別の FGA アプリケーションの起動