Android 9 リリースノート

このページでは、Android 9 リリースの主な機能の概要を説明し、追加情報へのリンクを掲載しています。これらの機能の概要は、このサイトにおける各機能のドキュメントの場所に従って整理されています。セクションの移動と名前の変更に関するガイドについては、サイトの更新（2018 年 8 月）をご覧ください。

ビルド

Generic System Image（GSI）

Generic System Image（GSI）は、Android デバイス用に構成が調整されたシステム イメージです。Generic System Image（GSI）ページでは、Android 9 搭載デバイス向けの GSI と Android 9 にアップグレードされるデバイス向けの GSI の相違点を説明しています。

アーキテクチャ

Hardware Abstraction Layer（HAL）

HIDL フレームワークの下位互換性

HIDL フレームワークの下位互換性の確認は、フレームワークの下位互換性を確認するための手法です。

動的に使用可能な HAL

動的に使用可能な HAL は、Android ハードウェアのサブシステムが使用されていない、または不要な場合の動的なシャットダウンをサポートします。

HIDL

HIDL MemoryBlock

HIDL MemoryBlock は、hidl_memory、HIDL @1.0::IAllocator、HIDL @1.0::IMapper に構築された抽象レイヤです。複数のメモリブロックが 1 つのメモリヒープを共有する HIDL サービス用に設計されています。

デバイスツリー オーバーレイ

圧縮オーバーレイ

Android 9 以降では、バージョン 1 のデバイスツリー テーブル ヘッダーを使用している場合に、Device Tree Blob Overlay（DTBO）イメージの圧縮オーバーレイをサポートします。

DTO の更新

Android 9 以降では、デバイスツリー オーバーレイ（DTO）で定義されたプロパティを変更する前に、統合されたデバイスツリー blob をブートローダーからカーネルに渡す必要があります。

DTBO イメージ ヘッダーのバージョニング

Android 9 以降では、DTBO イメージ ヘッダーにバージョン フィールドがあります。

DTBO の検証

Android 9 以降には DTBO パーティションが必要です。ノードを追加するまたは SoC の DT のプロパティを変更するには、ブートローダーで SoC の DT にデバイス固有の DT を動的にオーバーレイする必要があります。詳細については、コンパイルと検証をご覧ください。

カーネル コンプライアンス

Android 9 以降には、カーネル、インターフェース、DTBO の使用に影響する要件が含まれています。詳細については、次のページをご覧ください。

• 安定版カーネルのリリースと更新
• Android の一般的なカーネル
• モジュラー カーネルの要件
• インターフェースの要件
• デバイスツリー オーバーレイ

ベンダー NDK

設計変更

Android 9 以降における VNDK の設計の変更点については、次のページをご覧ください。

• Vendor Native Development Kit（VNDK）
• VNDK ビルドシステムのサポート
• VNDK 定義ツール
• ディレクトリ、ルール、sepolicy
• VNDK 拡張機能
• リンカー名前空間

ABI チェッカー

ABI の安定性ページでは、VNDK ライブラリに加えられた変更が ABI 準拠を維持することを保証する Application Binary Interface（ABI）チェッカーについて説明しています。

VNDK スナップショット

システム イメージとベンダー イメージが異なるバージョンの Android から作成された場合でも、システム イメージは VNDK スナップショットを使用することで正しい VNDK ライブラリをベンダー イメージに提供できます。

ベンダー インターフェース オブジェクト（VINTF オブジェクト）

ベンダー インターフェース オブジェクトのセクションの次のページでは、Android 9 以降の更新について説明しています。

• マニフェスト
• FCM ライフサイクル
• デバイス マニフェストの開発

HIDL のサポート終了に関するスケジュール

Android での HIDL HAL のサポート終了と削除について、次のページで説明します。

• FCM ライフサイクル
• デバイス マニフェストの開発

ブートローダー

product パーティション

Android 9 以降では、Android ビルドシステムを使用した /product パーティションの作成をサポートしています。これまで、Android 8.x では Android ビルドシステムで OEM 固有コンポーネント専用のスペースを作成することなく、システム オン チップ（SoC）固有のコンポーネントを /system パーティションから /vendor パーティションに強制的に分割していました。

正規のブート理由に関するコンプライアンス

正規のブート理由に関するページでは、Android 9 以降のブートローダーのブート理由の仕様に関する変更について説明します。

root としてのシステム

Android 9 以降を搭載したすべてのデバイスでは system-as-root を使用する必要があり、これによって ramdisk.img が system.img に統合され（別名 no-ramdisk）、その後 rootfs としてマウントされます。

ブートイメージ ヘッダーのバージョニング

Android 9 以降では、ブートイメージのヘッダーにヘッダー バージョンを示すフィールドが含まれています。 ブートローダーは、このバージョン フィールドを確認し、それに応じてヘッダーを解析する必要があります。

リカバリ時の DTBO

非 A/B デバイスでのリカバリ イメージと DTBO パーティションの不一致による OTA エラーを回避するには、リカバリ イメージに DTBO イメージからの情報が含まれている必要があります。

ディスプレイ

ディスプレイ カットアウト

ディスプレイ カットアウトにより、アプリのデベロッパーはデバイスの前面に重要なセンサーのスペースを確保しながら、臨場感あふれるエッジ ツー エッジのエクスペリエンスを作成できます。

画面の回転の提案

画面の回転動作の更新によって、Android 9 以降では、デバイスの位置が変更されても画面の向きを横向きまたは縦向きに固定する、ユーザー向けの制御をサポートしています。

同期アプリの切り替え

同期されたアプリの切り替えにより、新しいアプリの切り替えアニメーションが可能になります。

テキストの分類（旧 Textclassifier）

Android 9 以降には、テキスト分類サービスが含まれています。これは、テキスト分類を実装するための推奨方法で、デフォルトのサービス実装です。

広色域

Android 9 以降では、次のような広色域に対応しています。

• ハイ ダイナミック レンジ（HDR）
• BT2020 の色域でコンテンツを処理（ただし、エンドターゲットのデータスペースは対象外）

広色域を使用するには、デバイスのフル ディスプレイ スタック（画面、ハードウェア コンポーザー、GPU など）が広色域またはバッファ形式に対応している必要があります。ハードウェアでサポートされていても、デバイスでの広色域コンテンツのサポートは必須ではありません。ただし、ハードウェアを最大限に活用するには、広色域を有効にする必要があります。一貫性のない視覚効果を避けるため、実行時に広色域をオフにしないでください。

互換性

Android 互換性定義ドキュメント

Android 9 互換性定義ドキュメント（CDD）は以前のバージョンから更新を続けており、新機能の情報やリリース済み機能の要件に関する変更が含まれています。

設定

優れたアプリ ウィジェット

Android アプリ ウィジェットのフレームワークでは、特にウィジェットを削除または手動で追加するユーザー操作の視認性が向上しています。Launcher3 ではこの機能がデフォルトで搭載されています。

メーカーのランチャー アプリ（デバイスとともに出荷される）が Launcher3 をベースとしていない場合は、この機能をサポートするようアプリを更新する必要があります。OEM は、デフォルトのランチャーで新しい widgetFeatures フィールドをサポートする必要があります。

この機能は、ランチャーで意図したとおり実装された場合にのみエンド ツー エンドで機能する点に留意してください。AOSP にはサンプル実装が含まれています。提供されているサンプルコードについては、AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca をご覧ください。

パッケージ インストーラに対するデバイスの状態変更に関する通知

ロケールや表示密度などのプロパティが変更されるたびに、INSTALL_PACKAGES 権限を持つアプリに対して、保護されたシステム ブロードキャストを送信できます。レシーバーはマニフェストに登録でき、ブロードキャストを受信するためにプロセスが開始されます。これは、前述の変更を受けてパッケージ インストーラがアプリの追加コンポーネントをインストールしようとする場合には便利ですが、このブロードキャストをトリガーするような設定変更はまれであることから、これは一般的ではありません。

デバイスの状態変更に関する通知のソースコードは、platform/frameworks/base の次の場所にあります。

• api/system-current.txt
• core/java/android/content/Intent.java
• core/res/AndroidManifest.xml
• services/core/java/com/android/server/am/ActivityManagerService.java

情報アーキテクチャ

設定アプリの情報アーキテクチャの変更により、機能が増えるとともに実装が容易になりました。

テスト

Atest

Atest コマンドライン ツールを使用すると、Android のテストをローカルで作成、インストール、実行できます。Trade Federation テストハーネスのコマンドライン オプションを知らなくてもテストの再実行を大幅に高速化できます。

互換性テストスイート

CTS のダウンロード

Android 9 向けの互換性テストスイート（CTS）パッケージは、CTS ダウンロードから入手できます。格納されているテストのソースコードは、オープンソース ツリーの android-cts-9.0_r1 タグによって同期できます。

CTS のオプション

Android 9 では、CTS v2 に次のコマンドと引数が追加されています。

• run retry は、以前のセッションで失敗または実行されなかったすべてのテストを再試行します。
• ‘--shard-count は、複数のデバイスで同時に実行するために、CTS の実行を一定数の独立したチャンク数に分割します。

さらに、ドキュメント化されていなかったコマンド --retry-type が同じ CTS v2 コンソール コマンド リファレンスに追加されました。

セキュア エレメント（SE）サービス

セキュア エレメント サービスでは、SE HAL 実装がデバイスにあるかどうか、ある場合はその数を特定することによって、GlobalPlatform 対応のセキュア エレメントをチェックします。API とその裏にあるセキュア エレメントの実装をテストする際は、これに基づいて行います。

Sensor Fusion Box

Sensor Fusion Box は、Camera Image Test Suite（Camera ITS）のセンサー フュージョン テストやマルチカメラ同期テストで使用され、Android スマートフォンのカメラや各種センサーのタイムスタンプ精度を測定する一貫したテスト環境を実現します。詳細については、次のページをご覧ください。

• Sensor Fusion Box クイック スタートガイドでは、センサー フュージョン テストと Sensor Fusion Box を初めて設定する際の手順を説明します。
• Sensor Fusion Box の詳細では、Sensor Fusion Box を組み立てる際の手順を説明します。

広視野角 ITS-in-a-box

広視野角 ITS-in-a-box は、カメラ ITS で広視野角（WFoV）カメラと標準視野角（RFoV）カメラの両方のシステムをテストするように設計された自動システムです。

ベンダー テストスイート

ホスト コントローラのアーキテクチャ

ベンダー テストスイート（VTS）ホスト コントローラのアーキテクチャは、クラウドベースのテスト処理サービスと統合された VTS テスト フレームワークのアーキテクチャです。

サービス名認識型 HAL テスト

VTS サービス名認識型 HAL テストは、VTS テストが実行されているデバイスに基づいて、特定の HAL インスタンスのサービス名の取得をサポートします。

HAL テスト可否チェック

VTS HAL テスト可否チェックには、デバイス構成を使用して、そのデバイスのターゲットでスキップすべき VTS テストを実行時に特定する手段が含まれています。

自動テスト インフラストラクチャ

自動テスト インフラストラクチャは、AOSP 汎用システム イメージ（GSI）を実行するパートナー デバイスで VTS、CTS、その他のテストに対する自動テストを行う VTS インフラストラクチャです。

デバッグ

高度なテレメトリー

Android では、テレメトリーとは、デバイス、Android システム、アプリに関する使用と診断の情報を自動的に収集するプロセスです。Android の以前のバージョンでは、テレメトリー スタックが制限されていたため、システムの信頼性やデバイスまたはアプリの問題を特定し解決するために必要な情報が取得されませんでした。この結果、問題の根本原因を特定することが困難または不可能なものになっていました。

Android 9 には statsd テレメトリー機能が搭載されており、これによりデータの迅速な収集を可能にすることで前述の問題を解決しています。statsd は、アプリの使用状況、電池とプロセスの統計情報、クラッシュ状況を収集します。データは分析され、製品、ハードウェア、サービスの改善に活用されます。

詳しくは、frameworks/base/cmds/statsd/ をご覧ください。

セキュリティ機能

アプリの署名

v3 APK 署名スキームは、APK 鍵のローテーションをサポートしています。

生体認証サポート

Android 9 にはパブリック クラス BiometricPrompt が含まれており、アプリはこのクラスをデバイスやモダリティに依存しない形での生体認証サポートの統合に使用できます。BiometricPrompt を使用して生体認証スタックを統合する手順について詳しくは、生体認証をご覧ください。

動的分析

Android 9 は、その他の攻撃緩和と分析ツールをサポートしています。

制御フローの整合性（CFI）

制御フローの整合性（CFI）は、コンパイルされたバイナリの元のコントロール フローグラフへの変更を禁止するセキュリティ メカニズムであり、そうした攻撃の実行を著しく困難にします。

カーネル CFI

デフォルトで有効になっているシステム CFI に加え、Android 9 以降ではカーネル制御フローの整合性（CFI）がサポートされています。

暗号化

ファイルベースの暗号化

ファイルベースの暗号化（FBE）は、Adoptable Storage で動作するように更新されています。新しいデバイスでは、フルディスク暗号化の代わりにファイルベースの暗号化を使用する必要があります。

メタデータの暗号化

Android 9 以降では、ハードウェアのサポートがあるメタデータの暗号化がサポートされています。メタデータの暗号化では、起動時に存在する単一の鍵がファイルベースの暗号化を使用して、暗号化されていないコンテンツを暗号化します。

キーストア

Android 9 以降には、次の機能を持つ Keymaster 4 が搭載されています。

StrongBox

Android 9 以降では、埋め込みセキュア エレメント（SE）などの高セキュリティ用途向けの物理的に独立した CPU に格納して使用する Android Keystore の鍵をサポートしています。 StrongBox Keymaster は、Keymaster HAL をディスクリート セキュア ハードウェアに実装したものです。StrongBox の機能は次のとおりです。

• 独立した CPU
• 完全なセキュア ストレージ
• 高品質な真性乱数ジェネレータ
• 耐タンパー性を備えたパッケージ
• サイドチャネル耐性

鍵の安全なインポート

鍵を Keymaster 4 に安全にインポートするには、オフデバイスで作成した鍵を、キーの使用方法を定義する認証の仕様で暗号化します。

3DES サポート

Keymaster 4 には、3DES を使用するレガシー システムとの互換性のため 3DES が含まれています。

バージョン バインディング

Treble のモジュラー構造をサポートし、boot.img に対する system.img のバインディングを解除するため、Keymaster 4 では鍵のバージョン バインディング モデルを変更して、パーティションごとに個別のパッチレベルを設定するようになりました。これにより、ロールバック保護を維持したまま、各パーティションを独立してアップデートできます。

Android Protected の確認 API

Android 9 がインストールされたサポート対象デバイスでは、デベロッパーは Android Protected の確認 API を使用できます。 この API では、アプリは ConfirmationPrompt のインスタンスを使用して、ユーザーによる承認を求める短いメッセージを表示できます。このメッセージによって、支払いなどの機密性の高い取引を完了する際に、ユーザーの意思をアプリで再確認できます。

SELinux

アプリ別の SELinux サンドボックス

アプリケーション サンドボックスには、Android 9 以降を対象とするすべての非特権アプリが個別の SELinux サンドボックスを確実に実行するための新しい保護とテストケースがあります。

Treble SELinux の変更

Android 9 以降の Treble SELinux の更新については、SELinux セクションのいくつかのページに記載されています。

ベンダー init

ベンダー init は、ベンダー固有の権限により /vendor コマンドを実行する独立した SELinux ドメインを使用して、Treble のシステム/ベンダー分割で生じた穴をふさぎます。

システム プロパティ

Android 9 では、システム プロパティが system および vendor パーティション間で不必要に共有されることを制限し、共有されたシステム プロパティ間の一貫性を保証する手段を提供します。

SELinux 属性テスト

Android 9 には、特定の場所のすべてのファイルが適切な属性を持つことを確認する、新しいビルドタイム テストが用意されています。 たとえば、sysfs にあるすべてのファイルは必要とされる sysfs_type 属性を持ちます。

音声

高音質のオーディオ エフェクト

高音質オーディオ エフェクトの更新には、エフェクト処理の int16 形式から float 形式への変換が含まれるほか、クライアントの同時出力トラック数、クライアント / サーバーの最大メモリ、混合トラック総数も増加しています。

カメラ

外付け USB カメラ

Android 9 以降では、標準の Android Camera2 API とカメラの HIDL インターフェースにより、プラグアンドプレイ USB カメラ（ウェブカメラ）の使用がサポートされます。

モーション トラッキング

カメラデバイスは、モーション トラッキング機能をアドバタイズできます。

マルチカメラ サポート

マルチカメラ サポートには、同じ方向を向いた複数の物理カメラデバイスから成る新しい論理カメラデバイスを介した、マルチカメラ デバイス向けの API サポートが含まれています。

セッション パラメータ

セッション パラメータの実装によって、カメラ クライアントが撮影セッションの初期化フェーズで高価なリクエスト パラメータの一部を事前に構成することが可能になり、遅延を短縮できます。

単一プロデューサ、複数コンシューマー バッファ

単一プロデューサ、複数コンシューマーのカメラバッファ トランスポートは、撮影セッションやカメラでのストリーミングの進行中に、カメラ クライアントが出力サーフェスを動的に追加または削除できるようにする一連の手段です。

接続

通話とメッセージ

データプランの実装

Android 9 以降では、SubscriptionPlan API を使用してデータプランを実装する携帯通信会社に対するサポートを改善しています。

サードパーティの通話アプリ

Android 9 以降には、サードパーティ（3P）製の通話アプリが同時に行われる携帯通信会社からの受信通話を処理し、通話をシステム通話ログに記録できる API が搭載されています。

携帯通信会社

携帯通信会社 ID

Android 9 では、AOSP は携帯通信会社の識別に役立つ携帯通信会社 ID データベースを追加します。データベースは、携帯通信会社を識別するための一般的な方法を提供することで、ロジックの重複やアプリの断片化を最小限に抑えます。

eSIM

埋め込み SIM（eSIM または eUICC）は、モバイル ユーザーが物理的な SIM カードを持たずに携帯通信会社のプロファイルをダウンロードして、携帯通信会社のサービスを有効にできるようにする最新の技術です。Android 9 以降では、Android フレームワークは eSIM にアクセスし、eSIM で登録プロファイルを管理するための標準 API を提供しています。 詳しくは以下をご覧ください。

• eSIM の実装
• モデムの要件
• eUICC API

IMS 設定のマルチ SIM サポート

Android 9 以降では、IP マルチメディア サブシステム（IMS）に関するユーザー設定を改善しています。すべてのサブスクリプションでこの設定を共有するのではなく、VoiceOver LTE（VoLTE）、ビデオ通話、Wi-Fi 通話をサブスクリプションごとに設定できます。

SIM 状態のブロードキャスト

Android 9 以降では、Intent.ACTION_SIM_STATE_CHANGED が非推奨になり、TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED と TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED という、カード状態およびカード適用状態に関する 2 つの個別のブロードキャストが追加されています。

これらの変更により、カードが存在するかどうかのみを知る必要があるレシーバーで適用状態の変更を待機したり、カードの適用状況のみを知る必要があるレシーバーでカード状態の変更を待機したりする必要がなくなりました。

2 つの新しいブロードキャストは @SystemApis であり、sticky ではありません。READ_PRIVILEGED_PHONE_STATE の権限を持つレシーバーのみが、ブロードキャストを受信できます。

デバイスのロックを解除したときに、インテントは再ブロードキャストされません。ロック解除前に送信されたブロードキャストに依存するレシーバーは、directBootAware を使用するか、ロック解除後に状態を照会する必要があります。この状態は、TelephonyManager の対応する API getSimCardState() と getSimApplicationState() を使用して照会できます。

Wi-Fi

キャリア Wi-Fi

キャリア Wi-Fi 機能によって、デバイスは携帯通信会社が実装する Wi-Fi ネットワークに自動的に接続できます。混雑している地域、またはスタジアムや地下鉄の駅などの電波が届きにくい場所では、キャリア Wi-Fi を使用することで接続性が向上し、トラフィックをオフロードできます。

MAC アドレスのランダム化

MAC のランダム化により、現在ネットワークに関連付けられていないデバイスが新しいネットワークを探索する際に、ランダムな MAC アドレスを使用するようになります。Android 9 以降では、Wi-Fi ネットワークへの接続時にデバイスがランダムな MAC アドレスを使用するようになるデベロッパー オプションを有効にできます。

Wi‑Fi を自動的にオンにする

Wi-Fi を自動的にオンにする機能が有効な場合、デバイスが相対受信電波強度インジケーター（RSSI）の数値が十分に高い保存済みの Wi-Fi ネットワークに近づくと Wi-Fi が自動的に再度有効になります。

Wi-Fi ラウンドトリップ時間

Wi-Fi ラウンドトリップ時間（RTT）により、アクセス ポイント（AP）でも Wi-Fi Aware ピアでも（Wi-Fi Aware がデバイスでサポートされている場合）、デバイスで他の対応デバイスとの距離を測定できます。この機能は IEEE 802.11mc プロトコルをベースとしており、アプリが使用する位置情報の精度と認知度を向上させます。

Wi-Fi スコアリングの改善

Wi-Fi スコアリング モデルの改善により、接続済みの Wi-Fi ネットワークを解除したり新しい Wi-Fi ネットワークに接続したりするタイミングを迅速かつ正確に判断します。これらのモデルは接続が途切れることのない、信頼できるシームレスな環境をユーザーに提供します。

特に次の項目について、config.xml リソースの RSSI 値を確認、調整します。

• config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
• config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
• config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
• config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

Wi-Fi STA / AP の同時実行

Wi-Fi STA / AP の同時実行は、デバイスがステーション（STA）モードとアクセス ポイント（AP）モードで同時に動作する機能です。デュアルバンド同時接続（DBS）Wi-Fi をサポートするデバイスでは、ユーザーがアクセス ポイント（SoftAP）を有効にする場合に STA Wi-Fi の接続を維持するなどの接続方法が可能になります。

WiFiStateMachine の改善

WifiStateMachine は、Wi-Fi アクティビティの制御、ユーザー入力の調整（動作モード: アクセス ポイント、スキャン、接続、オフ）、Wi-Fi ネットワーク操作（スキャンや接続など）の制御に使用されるメインクラスです。

Android 9 以降では、Wi-Fi フレームワークのコードと WifiStateMachine の実装の再設計により、コードサイズの縮小、Wi-Fi 制御ロジックの追従性の向上、制御精度の向上、ユニットテストのカバレージと品質の向上を実現しました。

概略としては、WifiStateMachine では、Wi-Fi が次の 4 つの状態のいずれかになります。

• クライアント モード（接続とスキャンが可能）
• スキャン専用モード
• SoftAP モード（Wi-Fi アクセス ポイント）
• 無効（Wi-Fi が完全にオフ）

各 Wi-Fi モードでは、実行するサービスの要件が異なり、動作に関連するイベントのみを処理するように一貫性のある方法で設定する必要があります。新しい実装では、コードがそのモードに関連するイベントに制限され、デバッグ時間と複雑さを原因とする新しいバグが発生するリスクが軽減されます。モードの機能に対する明示的な処理に加えて、スレッド管理は一貫した方法で処理され、同期のためのメカニズムとして非同期チャネルの使用は排除されます。

Wi-Fi 権限の更新

Android 9 以降では、CHANGE_WIFI_STATE アプリ権限はデフォルトで有効になっています。[設定] > [アプリと通知] > [特別なアプリアクセス] > [Wi-Fi の管理] の設定ページでアプリの権限を無効にできます。

アプリは、CHANGE_WIFI_STATE 権限が付与されていないケースに対応できる必要があります。

この動作を検証するには、roboelectric と手動テストを実行します。

手動テストの場合:

1. [設定] > [アプリと通知] > [特別なアプリアクセス] > [Wi-Fi の管理]に移動します。
2. アプリの権限を選択して無効にします。
3. アプリが CHANGE_WIFI_STATE 権限を付与されていないシナリオを処理できることを確認します。

WPS のサポート終了

セキュリティの問題により、WiFiManager の Wi-Fi Protected Setup（WPS）は Android 9 以降でサポートを終了し、無効になりました。ただし、WiFiDirect は引き続き WPA サプリカントで WPS を使用します。

グラフィック

実装

Vulkan 1.1 API

Android 9 以降では、Vulkan 1.1 グラフィック API の実装をサポートしています。

ウィンドウ遷移トレース用の WinScope ツール

Android 9 以降には、ウィンドウ遷移をトレースする WinScope ツールが搭載されています。 WinScope は、移行中と移行後にウィンドウ マネージャの状態を記録し、分析するためのインフラストラクチャとツールを提供します。関連するウィンドウ マネージャの状態をすべてトレース ファイルに記録しながら、ウィンドウ遷移を記録してステップ実行できます。このデータを使用して、移行のリプレイとステップスルーを行うことができます。

WinScope ツールのソースコードは platform/development/tools/winscope にあります。

操作

自動車用オーディオ

自動車用オーディオでは、自動車に関連した Android の実装のオーディオ アーキテクチャについて説明します。

ニューラル ネットワーク（NN）HAL は、さまざまなアクセラレータの抽象化を定義します。これらのアクセラレータのドライバは、この HAL に準拠している必要があります。

車両 HAL

車両のプロパティでは、車両の HAL インターフェースに対する変更を説明しています。

GNSS 衛星の選択

新しいグローバル ナビゲーション衛星システム（GNSS）HAL（v1.1 以降）を使用する場合、Android フレームワークは Android の設定を監視します。パートナーは、Google Play サービスやその他のシステム アップデートから設定を変更できます。これらの設定は、GNSS HAL に、特定の GNSS 衛星を使用しないかどうかを指示します。これは、GNSS 衛星またはコンステレーション エラーが永続的に発生する場合や、うるう秒、曜日、週番号の繰り越しなど、異なる時刻システムや外部イベントを使用してコンステレーションを混合する場合に発生する GNSS HAL 実装の問題により迅速に対応する必要がある場合に有用です。

GNSS ハードウェア モデル

Android 9 では、GNSS HAL バージョン 1.1 以降でハードウェア API に関する情報をプラットフォームに渡すことができます。プラットフォームは、IGnssCallback インターフェースを実装し、HAL にハンドルを渡す必要があります。GNSS HAL は、LocationManager#getGnssHardwareModelName() メソッドによりハードウェア モデルの情報を渡します。デバイス メーカーは GNSS HAL プロバイダと協力して、可能な限りこの情報を提供する必要があります。

権限

任意アクセス制御の構成の更新

任意アクセス制御（DAC）の構成には、ファイル システム機能を拡張するための Android ID（AID）メカニズムに対する変更が含まれています。

権限のあるアプリの権限のホワイトリスト

Android 9 以降では、権限を拒否する必要がある場合は、XML を編集して以前のリリースで使用されていた permission タグの代わりに deny-permission タグを使用するようにします。

データ

帯域幅推定の改善

Android 9 では、帯域幅推定のサポートが強化されています。Android アプリが利用可能なデータ帯域幅にアクセスできる場合は、ビデオ通話や動画ストリーミングの解像度をより適切に設定できます。

Android 6.0 以降を搭載するデバイスの場合、モバイル ネットワークの推定帯域幅を求める呼び出し元が ConnectivityManager.requestBandwidthUpdate() を呼び出し、フレームワークが推定ダウンリンク帯域幅を提供します。

一方、Android 9.0 以降を搭載するデバイスの場合、推定帯域幅が大きく変化すると onCapabilitiesChanged() コールバックが自動的に起動します。requestBandwidthUpdate() の呼び出しは何も行いませんが、関連する getLinkDownstreamBandwidthKbps() と getLinkUpstreamBandwidthKbps() では物理層から提供される更新情報が入力されます。

さらに、デバイスは ServiceState.getCellBandwidths() を介して LTE セルの帯域幅を確認できます。 これにより、アプリケーションは特定のセルで使用できる帯域幅（周波数）を特定できます。セルの帯域幅情報は、非表示のメニューから取得でき、フィールド テスターは最新の情報を確認できます。

eBPF トラフィック モニタリング

eBPF ネットワーク トラフィック ツールは、カーネルとユーザー空間の実装の組み合わせを使用して、前回のデバイスの起動以降のデバイスにおけるネットワーク使用を監視します。このツールは、デバイスの状態に応じて、ネットワーク アクセスからアプリケーションをブロックするために、ソケットのタグ付け、フォアグラウンドとバックグラウンドのトラフィック分離、UID 別ファイアウォールなどの追加機能を提供します。

より低い API に復元する

デバイスが、オペレーティング システムの将来のバージョンから復元できるようになりました。これは、ユーザーがスマートフォンをアップグレードした後に紛失または破損した場合に特に便利です。

OEM がシステム パッケージ（Android、システム、設定）のいずれかのバックアップ エージェントを修正した場合、それらのエージェントはクラッシュを伴わずに、少なくとも一部のデータを復元しながら、プラットフォームの上位バージョンに基づいて作成されたバックアップ セットを復元する必要があります。

core/java/android/provider/SettingsValidators.java にあるように、バリデータを使用して指定されたバックアップ データの無効な値をチェックし、有効なデータのみを復元することを検討します。

この機能はデフォルトでオンになっています。将来のバージョンからの復元に関する SettingsBackupAgent のサポートは、Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION からオフにできます。デバイス メーカーが ROM に含まれるバックアップ エージェントを拡張（または、カスタム エージェントを追加）しない限り、追加の実装は必要ありません。

この機能により、プラットフォームの将来のバージョンからのシステム復元が可能になります。ただし、復元されたデータが完全ではないことが予想されます。次のバックアップ エージェントに適用される手順は、以下のとおりです。

• PackageManagerBackupAgent は、フォーマット バージョニングを使用してバックアップ データの将来のバージョンをサポートします。こちらの拡張機能は現在の復元コードと互換性があるか、適切な定数のバンプを含むクラス内の指示に従うことが必要です。

• SystemBackupAgent は、Android 9 以降で restoreAnyVersion = false を指定します。API の上位バージョンからの復元はサポートされていません。

• SettingsBackupAgent は、Android 9 以降で restoreAnyVersion = true を指定します。部分的なサポートはバリデータを介して存在します。ターゲット OS にバリデータが存在する場合は、上位の API から設定を復元できます。設定を追加するには、バリデータを指定する必要があります。詳細については、クラスを確認してください。

• ROM に含まれるカスタム バックアップ エージェントは、バックアップ データ形式に互換性のない変更が加えられた場合にはバージョン コードを増やし、エージェントで将来のバージョンからバックアップ データを処理する準備ができていない場合は、必ず restoreAnyVersion = false（デフォルト）であることを確認する必要があります。

ビジネス

管理対象プロファイルの改善

管理対象プロファイルの UX の変更により、ユーザーが管理対象プロファイルを簡単に識別、アクセス、管理できるようになります。

OTA の一時停止

新しい @SystemApi を使用すると、デバイスの所有者はセキュリティ アップデートなどの OTA アップデートを無期限で一時停止できます。

パフォーマンス

Health 2.0

Android 9 以降には、health@1.0 HAL からのメジャー バージョンのアップグレードである android.hardware.health HAL 2.0 が含まれます。詳細については、次のページをご覧ください。

• パフォーマンスと健全性
• 健全性の実装
• health@1.0 のサポート終了

APK キャッシュ ソリューション

Android 9 以降には、A/B パーティションをサポートするデバイスにプリロードされたアプリを迅速にインストールするための、APK キャッシュ ソリューションが含まれています。OEM は、大部分が新しい A/B 分割デバイスの空の B パーティションに保存された APK キャッシュにプリロードと人気のあるアプリを配置できます。その際ユーザー向けのデータスペースに影響が生じることはありません。

プロファイルに基づく最適化

Android 9 以降では、ブループリントのビルドルールを持つネイティブ Android モジュールで Clang のプロファイルに基づく最適化（PGO）を使用できます。

write-ahead log 書き込み

互換性 write-ahead log 書き込み（WAL）という SQLiteDatabase の特殊なモードにより、データベースごとに最大 1 つの接続を維持しながら journal_mode=WAL を使用できるようになります。

起動時間

Android 9 は、起動時間の最適化の説明にあるとおり、起動時間の最適化が変更されます。

電源

バックグラウンド制限

Android 9 以降にはバックグラウンド制限が含まれており、電池を消耗させている可能性があるアプリをユーザーが制限できます。 また、デバイスの健全性に悪影響を与えているアプリの無効化を提案する機能もあります。

電池非搭載デバイス

Android 9 は、電池非搭載デバイスを以前のリリースよりも適切に処理します。Android 9 では、電池が存在し、100% 充電されていて、サーミスタの温度測定値が正常で良好な状態にあることをデフォルトで仮定する、電池非搭載デバイス向けのコードが削除されています。