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

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

前提条件または要件

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

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

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

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

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

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

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

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

2. 組み込まれる 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. を省略できることにご注意ください。

1. テクニシャン PC にリテール コード署名証明書をインストールします。

2. Visual Studio でカスタム アプリケーションを開き、Package.appxmanifest ファイルを開きます。

3. [Packaging](パッケージ) タブをクリックし、[証明書の選択...] ボタンをクリックします。

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

5. プロンプトが表示されたらリテール コード署名証明書を選び、[OK] をクリックします。

6. Visual Studio でプロジェクトを保存し、Appx パッケージをビルドします。 このパッケージをビルドするときに、リテール コード署名証明書のパスワードの入力を求められることにご注意ください。

7. 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 にリテール コード署名証明書がインストールされていることを確認してください。

1. お使いの証明書とクロス証明書の詳細が含まれるように、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>

2. 管理者として、IoT Core PowerShell 環境を実行します。

3. リテール署名用の環境を設定します。 これは Set-IoTRetailSign を使用して行います。

Set-IoTRetailSign On
(or) retailsign on 

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

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 ディレクトリにコピーします。

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

7. 以下のコマンドを実行して、製品イメージをビルドします。

New-IoTFFUImage ProductX Retail
(or)buildimage ProductX Retail 

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

使用されるコマンド

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

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

1. 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"];

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

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

• 別の 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: 独自のボード サポート パッケージの作成