Android 9 の機能と API

Android 9（API レベル 28）では、ユーザーやデベロッパー向けの優れた新機能が導入されています。 このドキュメントでは、デベロッパー向けの新しい機能を紹介します。

新しい API の詳細については、API 比較レポートまたは Android API リファレンスをご覧ください。 あわせて Android 9 の動作変更点で、プラットフォームの変更がアプリにどのような影響を与えるのかをご確認ください。

Wi-Fi RTT による屋内位置測定

Android 9 では、IEEE 802.11mc WiFi プロトコルがプラットフォームでサポートされています。これは、Wi-Fi Round-Trip-Time（RTT）とも呼ばれ、アプリから屋内位置測定を使えるようにするものです。

RTT に対応したハードウェアを搭載する Android 9 端末では、アプリは新しい RTT API を使用して、近くにある RTT 対応の Wi-Fi アクセスポイント（AP）との距離を測定できます。 この際、端末のロケーション サービスと Wi-Fiスキャン（[Settings] > [Location] で設定）が有効になっており、アプリに ACCESS_FINE_LOCATION パーミッションが付与されていることが条件となります。 RTT は、端末がアクセス ポイントに接続していなくても利用できます。 ただし、プライバシー保護のため、アクセス ポイントまでの距離の測定はスマートフォン側からだけ行うことができます。アクセス ポイント側から距離を測定することはできません。

端末で 3 つ以上のアクセス ポイントまでの距離がわかれば、マルチラテレーション アルゴリズムを使用して、その測定結果から最適な端末の位置を推定できます。 基本的には、1～2 メートルの精度で端末の位置を特定できます。

この精度で位置が測定できると、屋内ナビゲーション、明確な音声制御（「このライトを付けてください」）などの高精度ロケーションベース サービス、ロケーションベースの情報（「この製品はスペシャル オファーが利用できますか？」）といった新しい体験を構築できます。

ディスプレイの切り欠きのサポート

エミュレータを用いたディスプレイ切り欠きのテスト

Android 9 では、カメラとスピーカー用のディスプレイ切り欠きがある画面いっぱいに表示される最新のスクリーンをサポートしています。 DisplayCutout クラスを使用すると、コンテンツが表示されない非機能領域の位置と形状を確認できます。 このような切り欠き領域の存在と配置を特定するには getDisplayCutout() メソッドを使います。

layoutInDisplayCutoutMode という新しいウィンドウ レイアウト属性を使用すると、端末の切り欠き領域の周辺にアプリ コンテンツを配置できます。 この属性は次の値に指定することが可能です。

• LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT
• LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES
• LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER

以下の手順に従うと、Android 9 を実行する任意の端末またはエミュレータで、画面の切り欠きを再現できます。

1. 開発者向けオプションを有効にします。
2. [Developer options] 画面で、[Drawing] セクションまでスクロール ダウンし、[Simulate a display with a cutout] を選択します。
3. 切り欠きのサイズを選択します。

注: Android 9 を実行する端末またはエミュレータを使用して、切り欠き領域周辺のコンテンツ表示をテストすることをお勧めします。

通知

Android 9 では、通知機能のさまざまな点が改善されており、API レベル 28 以降をターゲットとするデベロッパーは、それらの機能をすべて利用できます。

写真が添付された MessagingStyle

返信や会話が表示された MessagingStyle

SMS 仕様の改善

Android 7.0（API レベル 24）以降では、通知から直接メッセージに返信する、または他のテキストメッセージを入力するためのアクションを追加できます。 Android 9 では、この機能が次のように改良されています。

• よりシンプルな会話参加者のサポート: Person クラスを使用すると、アバターや URI を含め、会話に参加している人々を特定できます。 addMessage() など、その他の多くの API は CharSequence の代わりに Person クラスを利用するようになりました。 また、Person クラスはビルダー デザイン パターンをサポートしています。

• イメージのサポート: Android 9 では、端末上の SMS 通知にイメージが表示されます。 メッセージにイメージを表示するには、setData() を使用します。 次のコード スニペットは、Person の作成方法とイメージを含むメッセージの作成方法を示しています。

// Create new Person.
val sender = Person()
        .setName(name)
        .setUri(uri)
        .setIcon(null)
        .build()
// Create image message.
val message = Message("Picture", time, sender)
        .setData("image/", imageUri)
val style = Notification.MessagingStyle(getUser())
        .addMessage("Check this out!", 0, sender)
        .addMessage(message)

// Create new Person.
Person sender = new Person()
        .setName(name)
        .setUri(uri)
        .setIcon(null)
        .build();
// Create image message.
Message message = new Message("Picture", time, sender)
        .setData("image/", imageUri);
Notification.MessagingStyle style = new Notification.MessagingStyle(getUser())
        .addMessage("Check this out!", 0, sender)
        .addMessage(message);

• 返信の下書き保存: ユーザーが意図せずメッセージ通知を閉じてしまった場合に、システムから送信される EXTRA_REMOTE_INPUT_DRAFT をアプリで取得できます。 この追加機能を利用すると、アプリのテキスト フィールドを事前に埋めて、ユーザーが返信を完了できるようにすることができます。

• グループ会話の判別: setGroupConversation() を使用すると、グループでの会話とそれ以外の会話を明示的に区別できます。

• インテントのためのセマンティックなアクションの設定: setSemanticAction() メソッドを使用すると、既読の印をつける、削除する、返信するなど、アクションの意味づけができます。

• SmartReply: Android 9 では、メッセージ アプリと同じ返信候補をサポートします。 RemoteInput.setChoices() を使用すると、一連の標準的な返信をユーザーに提示できます。

チャンネル設定、ブロードキャスト、マナーモード

Android 8.0 では通知チャンネルが導入され、表示する通知の種類ごとに、ユーザーがカスタマイズ可能なチャンネルを作成できるようになりました。 Android 9 では、この通知チャンネル設定をさらにシンプルにするため、次の変更を加えています。

• チャンネル グループのブロック: ユーザーは、アプリの通知設定内のすべてのチャンネル グループをブロックできます。 isBlocked() メソッドを使用すると、いつグループがブロックされたかを特定できるため、結果として、そのグループに含まれるチャンネルの通知を送信しないようにすることができます。

  アプリで現在のチャンネル グループ設定をクエリするには、新しい getNotificationChannelGroup() メソッドを使用します。

• 新しいブロードキャスト インテント タイプ: 通知チャンネルのブロック状態やチャンネル グループが変化した際に、Android システムによってブロードキャスト インテントが送信されるようになりました。 ブロックされたチャンネルまたはグループを含むアプリは、そのインテントをリッスンして適切なアクションをとることができます。 これらのインテント アクションや追加機能の詳細については、NotificationManager リファレンスに含まれる最新の定数リストをご覧ください。 ブロードキャスト インテントの処理方法については、ブロードキャストをご確認ください。

• NotificationManager.Policy には、3 つの新しい Do-Not-Disturb 優先カテゴリがあります。

  • PRIORITY_CATEGORY_ALARMS は、アラームを優先します。
  • PRIORITY_CATEGORY_MEDIA は、メディアや音声ナビゲーションなど、メディアソースからの音声を優先します。
  • PRIORITY_CATEGORY_SYSTEM は、システム通知音を優先します。

• NotificationManager.Policy には、視覚的な割り込みを抑制するために使用できる、7 つの新しい Do-Not-Disturb 定数が含まれています。

  • SUPPRESSED_EFFECT_FULL_SCREEN_INTENT は、通知がフルスクリーン アクティビティを起動することを防止します。
  • SUPPRESSED_EFFECT_LIGHTS は、通知ランプをブロックします。
  • SUPPRESSED_EFFECT_PEEK は、通知が一時的にビューにスライド（「ピーク」）することを防止します。
  • SUPPRESSED_EFFECT_STATUS_BAR は、ステータスバーをサポートする端末上で通知がステータスバーに表示されることを防止します。
  • SUPPRESSED_EFFECT_BADGE は、バッジをサポートする端末上でバッジをブロックします。 詳細は、通知バッジの変更をご覧ください。
  • SUPPRESSED_EFFECT_AMBIENT は、常に画面表示モードをサポートする端末上で通知をブロックします。
  • SUPPRESSED_EFFECT_NOTIFICATION_LIST は、通知シェードやロック画面など、リストビューをサポートする端末上で通知がリストビューに表示されることを防止します。

マルチカメラのサポートとカメラ機能のアップデート

Android 9 を実行している端末では、2 つ以上の物理カメラのストリームに同時アクセスできます。 デュアルフロントまたはデュアルバック カメラが搭載されている端末では、シームレスなズーム、ぼかし、立体視など、単一のカメラでは実現できない画期的な機能を実現できます。 API を使うと、論理カメラ ストリームや、2 つ以上のカメラを自動的に切り替える融合カメラ ストリームを呼び出すこともできます。

カメラに関するその他の改善点として、最初の撮影の際の遅延を短縮するために役立つ追加の Session パラメータや、カメラのストリーミングを停止して再開しなくてもカメラ クライアントがさまざまなユースケースを扱えるようにする Surface 共有などがあります。 また、ディスプレイを利用したフラッシュをサポートする API や、アプリレベルでのイメージの安定化や特殊効果に利用できる OIS タイムスタンプにアクセスする API が追加されています。

Android 9 では、マルチカメラ API により、FULL または LIMITED 機能を備えた端末でモノクロカメラがサポートされます。 モノクロ出力は、Y がグレースケール、U（Cb）が 128、V（Cr）が 128 の YUV_420_888 形式で出力されます。

さらに Android 9 では、サポート対象の端末で外部 USB や UVC カメラを利用できます。

ドローアブルとビットマップのための ImageDecoder

Android 9 で導入された ImageDecoder クラスを使用すると、最新の方法でイメージをデコードできます。 BitmapFactory および BitmapFactory.Options API の代わりにこのクラスを使用します。

ImageDecoder では、バイト バッファ、ファイル、URI から Drawable または Bitmap を作成できます。 イメージをデコードするには、まずエンコードされたイメージのソースを指定して createSource() を呼び出します。 次に decodeDrawable() または decodeBitmap() を呼び出して ImageDecoder.Source オブジェクトを渡し、Drawable または Bitmap を作成します。 デフォルト設定を変更するには、decodeDrawable() または decodeBitmap() に OnHeaderDecodedListener を渡します。 イメージのデフォルトの幅と高さが判明すると、ImageDecoder はその情報を指定して onHeaderDecoded() を呼び出します。 エンコードされたイメージがアニメーション化された GIF または WebP である場合、decodeDrawable() は Drawable を返します。これは、AnimatedImageDrawable クラスのインスタンスです。

イメージのプロパティは、複数の方法で設定できます。

• デコードしたイメージを厳密なサイズにスケール変更するには、ターゲットの寸法を setTargetSize() に渡します。 またはサンプルサイズを使用して、イメージのスケールを変更することもできます。 サンプルサイズを setTargetSampleSize() に直接渡します。
• スケール変更したイメージの範囲内でイメージを切り取るには、setCrop() を呼び出します。
• 可変ビットマップを作成するには、true を setMutableRequired() に渡します。

ImageDecoder を使用すると、角丸や円形マスクなど、カスタマイズした効果や複雑な効果をイメージに適用できます。 任意の描画コマンドを実行するには、PostProcessor クラスのインスタンスを指定して setPostProcessor() を呼び出します。

注: AnimatedImageDrawable の後処理を行うと、アニメーションのすべてのフレームに効果が適用されます。

アニメーション

Android 9 では、GIF および WebP のアニメーション イメージを描画し、表示するための AnimatedImageDrawable クラスが導入されています。 AnimatedImageDrawable の動作は AnimatedVectorDrawable と同様で、レンダリング スレッドが AnimatedImageDrawable のアニメーションをコントロールします。 また、レンダリング スレッドはワーカー スレッドを使用してデコードを行うため、デコード処理がレンダリング スレッドの他の操作に影響を及ぼすことはありません。 この実装により、アプリはイメージのアップデートを管理することなくアニメーション イメージを表示でき、アプリの UI スレッド上の他のイベントに影響が生じることもありません。

ImageDecoder のインスタンスを使用して、AnimatedImageDrawable をデコードすることができます。 以下のコード スニペットは、ImageDecoder を使用して AnimatedImageDrawable をデコードする方法を示しています。

@Throws(IOException::class)
private fun decodeImage() {
    val decodedAnimation = ImageDecoder.decodeDrawable(
        ImageDecoder.createSource(resources, R.drawable.my_drawable))

    // Prior to start(), the first frame is displayed.
    (decodedAnimation as? AnimatedImageDrawable)?.start()
}

private void decodeImage() throws IOException {
    Drawable decodedAnimation = ImageDecoder.decodeDrawable(
        ImageDecoder.createSource(getResources(), R.drawable.my_drawable));

    if (decodedAnimation instanceof AnimatedImageDrawable) {
        // Prior to start(), the first frame is displayed.
        ((AnimatedImageDrawable) decodedAnimation).start();
    }
}

ImageDecoder には、さらにイメージを修正するためのメソッドがいくつか含まれています。 たとえば setPostProcessor() メソッドを使用すると、円形マスクや角丸を適用して、イメージの見た目を修正することができます。

HDR VP9 動画、HEIF イメージ圧縮、メディア API

Android 9 では、組み込みでハイダイナミックレンジ（HDR）VP9 Profile 2 がサポートされており、YouTube や Play Movies などのソースから HDR 対応端末に HDR ムービーを提供できます。

Android 9 のプラットフォームは、新たに HEIF（heic）イメージ エンコーディングをサポートしています。 HEIF の静止イメージ サンプルは、MediaMuxer および MediaExtractor クラスでサポートされており、ストレージおよびネットワーク データを節約するために HEIF の圧縮率が改善されています。 Android 9 端末では、この HEIF がプラットフォームでサポートされるため、バックエンド サーバーから簡単に HEIF イメージを送って活用できるようになります。 アプリがこのデータ フォーマットによる共有や表示に対応していることを確認できたら、アプリにイメージを保存する際のフォーマットとして HEIF を使用してみてください。 ImageDecoder や BitmapFactory を使うと、jpeg-to-heic 変換を行って jpeg からビットマップを取得することができます。また、HeifWriter を使うと、YUV バイト バッファ、Surface、Bitmap のいずれかから HEIF の静止イメージを書き込むことができます。

メディア メトリクスは AudioTrack、AudioRecord、および MediaDrm クラスからも利用できるようになりました。

Android 9 で MediaDRM クラスに追加されたメソッドを使うと、メトリクス、HDCP レベル、セキュリティ レベル、セッション数の取得や、セキュリティ レベルとセキュア ストップのより詳細な管理が可能になります。 詳細については、API 比較レポートをご覧ください。

Android 9 では、AAudio API に、使用量、コンテンツ タイプ、入力プリセット用の AAudioStream 属性が含まれています。 これらの属性を使用して、VoIP アプリやカムコーダー アプリ向けに調整されたストリームを作成することができます。 また、AAudio ストリームとサブミックス（効果を含めることができる）が関連付けられるように SessionID を設定することもできます。 効果を制御するには、AudioEffect API を使用します。

Android 9 は、DynamicsProcessing 用の AudioEffect API を備えています。 このクラスを使用して、イコライゼーション、マルチバンド圧縮、リミッターなど、さまざまなタイプの複数のステージで構成されるチャンネルベースのオーディオ エフェクトを作成することができます。 帯域やアクティブなステージの数を自由に設定できるほか、ほとんどのパラメータをリアルタイムで制御できます。

JobScheduler でのデータコスト感度

Android 9 以降では、JobScheduler で、携帯通信会社から提供されるネットワークのステータス シグナルを使用して、ネットワーク関連ジョブの処理を改善することができます。

ジョブでは、予想データサイズの宣言、プリフェッチの合図、詳細ネットワーク要件の指定などができるようになっています。 JobScheduler は、そのネットワークのステータスに基づいて作業を管理します。 たとえば、ネットワークの混雑が合図されると、JobScheduler は大きなネットワーク リクエストの実行を先送りする場合があります。 定額制のネットワークの場合、JobScheduler は、あらかじめ見出しの一覧を取得しておくなど、プリフェッチ ジョブを実行してユーザー エクスペリエンスを改善することができます。

ジョブを追加する場合は、JobScheduler が作業を適切に処理できるよう、必要に応じて setEstimatedNetworkBytes()、setPrefetch()、setRequiredNetwork() を使うようにします。 ジョブを実行するときには、JobParameters.getNetwork() から返された Network オブジェクトを使うようにします。 そうでないと、暗黙的に端末のデフォルト ネットワークを使うことになります。その場合、要件を満たさず、意図しないデータ使用量になる可能性があります。

Neural Networks API 1.1

Neural Networks API は、Android 端末上での機械学習を強化するために、Android 8.1（API レベル 27）で導入されました。 Android 9 では、この API が拡張および改良されており、次の 9 種類の新しい操作が追加されています。

• 要素ごとの算術演算
  • ANEURALNETWORKS_DIV
  • ANEURALNETWORKS_SUB
• 配列演算
  • ANEURALNETWORKS_BATCH_TO_SPACE_ND
  • ANEURALNETWORKS_SPACE_TO_BATCH_ND
  • ANEURALNETWORKS_SQUEEZE
  • ANEURALNETWORKS_STRIDED_SLICE
  • ANEURALNETWORKS_TRANSPOSE
  • ANEURALNETWORKS_PAD
  • ANEURALNETWORKS_MEAN

既知の問題点: ANEURALNETWORKS_TENSOR_QUANT8_ASYMM テンソルを ANEURALNETWORKS_PAD 演算（Android 9 以降で利用可能）に渡すときに、NNAPI からの出力が、TensorFlow Lite などの高レベルの機械学習フレームワークからの出力と一致しない場合があります。 問題が解決するまでは、その代わりに ANEURALNETWORKS_TENSOR_FLOAT32 のみを渡す必要があります。

また、この API は ANeuralNetworksModel_relaxComputationFloat32toFloat16() という新機能を備えており、IEEE 754 16 ビット浮動小数点形式と同程度の範囲と精度で ANEURALNETWORKS_TENSOR_FLOAT32 を計算するかどうを指定することができます。

自動入力フレームワーク

Android 9 では、この自動入力サービスに改良を加え、フォーム記入時のユーザー エクスペリエンスをさらに改善できるようにしています。 アプリで自動入力機能を使用する方法の詳細は、自動入力フレームワークのガイドをご覧ください。

セキュリティの機能強化

Android 9 には、以下のセクションで説明する多くのセキュリティ機能が追加されています。

Android Protected Confirmation

Android 9 以降を実行するサポート対象の端末では、Android Protected Confirmation を使用することができます。 このワークフローを使用すると、アプリでユーザーにプロンプトを表示し、短い文を承認するように求めることができます。 この文により、アプリでは、ユーザーが支払いの実行などの機密性の高いトランザクションを完了する意思があることを再確認できます。

ユーザーがこの文を承認すると、Android Keystore は、鍵付きハッシュのメッセージ認証コード（HMAC）で保護されている暗号化署名を受け取って保存します。 Android Keystore がメッセージの有効性を確認した後、アプリは、信頼できる実行環境（TEE）で trustedConfirmationRequired から生成された鍵を使用して、ユーザーが承認したメッセージに署名することができます。 署名により、ユーザーが確実に文を見て、文に同意したことが示されます。

警告: Android Protected Confirmation は、ユーザーに対して安全な情報チャンネルを提供しません。 アプリでは、Android プラットフォームが提供する機密保持の保証以外は保証されません。 特に、このワークフローを使用して、ユーザーの端末に通常は表示しない機密情報を表示しないようにしてください。

Android Protected Confirmation のサポートを追加する方法については、Android Protected Confirmation のガイドをご覧ください。

統合されたバイオメトリック認証ダイアログ

Android 9 では、アプリの代わりに、システムによってバイオメトリック認証ダイアログが提供されます。 この機能により、ダイアログの外観、操作性、配置が標準化され、ユーザーは、信頼できるバイオメトリック認証情報チェッカーに対して、安心して認証を行うことができます。

アプリが FingerprintManager を使用して指紋認証ダイアログをユーザーに表示している場合は、BiometricPrompt の使用に切り替えます。 BiometricPrompt はシステムに依存して認証ダイアログを表示します。 また、ユーザーが選択したバイオメトリック認証のタイプに対応するために、その動作を変更します。

注: アプリで BiometricPrompt を使用する前に、最初に hasSystemFeature() メソッドを使用して、端末で FEATURE_FINGERPRINT、FEATURE_IRIS、または FEATURE_FACE がサポートされるようにします。 端末でバイオメトリック認証がサポートされない場合は、createConfirmDeviceCredentialIntent() メソッドを使用して、ユーザーの PIN、パターン、またはパスワードの検証にフォールバックすることができます。

ハードウェアのセキュリティ モジュール

Android 9 以降がインストールされたサポート対象の端末では、ハードウェアのセキュリティ モジュール内にある Keymaster HAL の実装である StrongBox Keymaster を使用できます。 このモジュールには次のものが含まれています。

• 独自の CPU。
• 安全なストレージ。
• 真性乱数ジェネレータ。
• パッケージの改ざんやアプリの不正なサイドローディングを防ぐ追加のメカニズム。

システムでは、StrongBox Keymaster に格納されている鍵をチェックするときに、信頼できる実行環境（TEE）で鍵の整合性を保証します。

Strongbox Keymaster を使用する方法の詳細は、ハードウェアのセキュリティ モジュールをご覧ください。

キーストアへの鍵の安全なインポート

Android 9 では、ASN.1 でエンコードされた鍵形式を使用して、暗号化された鍵をキーストアに安全にインポートする機能を追加することにより、鍵を復号化する際の追加セキュリティを提供しています。 次に、Keymaster によりキーストアで鍵が復号化されるため、端末のホストメモリに鍵のコンテンツがプレーン テキストで出現することはありません。

注: この機能は、Keymaster 4 以降が含まれている端末のみでサポートされます。

暗号化された鍵をより安全にインポートする方法の詳細をご覧ください。

鍵のローテーションを使った APK 署名スキーム

Android 9 では、APK 署名スキーム v3 のサポートが追加されています。このスキームには、各署名証明書の署名ブロックにローテーション証明記録を含めるためのオプションがあります。 この機能を使用すると、APK ファイルの過去の署名証明書を新しい署名証明書にリンクすることにより、新しい署名証明書でアプリに署名することができます。

注: Android 8.1（API レベル 27）以前を実行している端末は、署名証明書の変更をサポートしていません。 アプリの minSdkVersion が 27 以下である場合は、新しい署名に加えて、古い証明証明書を使用してアプリに署名します。

詳細は、apksigner を使用して鍵をローテーションする方法をご覧ください。

ロック解除された端末のみで鍵を復号化するオプション

Android 9 には、unlockedDeviceRequired フラグが導入されています。 このオプションにより、指定した鍵を使用して実行中のデータまたは保存されたデータの復号化を許可する前に、キーストアが画面のロック解除を要求するかどうかが指定されます。 これらのタイプの鍵は、健康データや企業データなどの機密データを暗号化してディスクに保存するときに適しています。 このフラグを使用すると、端末を紛失したり盗まれたりした場合でも、端末がロックされているとデータを復号化することはできないため、ユーザーには高い安心感がもたらされます。

注: unlockedDeviceRequired フラグを有効にすると、暗号化と署名検証が任意のタイミングで引き続き発生します。 このフラグは、端末がロック解除された際に、データの復号化のみを防止します。

端末がロック解除されたときに、鍵を復号化できないようにするには、true を setUnlockedDeviceRequired() メソッドに渡して、このフラグを有効にします。 このステップの完了後、ユーザーの画面がロックされると、この鍵を使用してデータを復号化したり、データに署名したりする試みはすべて失敗します。 ロックされた端末にアクセスするには、PIN、パスワード、指紋、またはその他の信頼できる要素が必要です。

以前の暗号化方法のサポート

Keymaster 4 が付属している Android 9 端末では、Triple Data Encryption Algorithm（Triple DES）がサポートされます。 Triple DES を必要とする以前のシステムとアプリを相互運用する必要がある場合、機密性の高い認証情報を暗号化するときにこのタイプの暗号を使用します。

アプリをさらに安全にする方法の詳細は、Android デベロッパー向けセキュリティをご覧ください。

• ユーザーが Android 9 以降を使用してバックアップを有効化している。
• ロック解除するために PIN、パターン、またはパスワードが必要な端末でユーザーが画面ロックを設定している。

このプライバシー方針が有効化されると、ユーザーの端末で作成されたバックアップからデータを復元する際に、端末の PIN、パターン、またはパスワードが必要になります。 この機能のベースとなるテクノロジーの詳細については、Google Cloud Key Vault Service に関するホワイトペーパーをご覧ください。

バックアップに必要な端末条件の定義

Android 9 では、アプリデータに機密情報やユーザー設定が含まれる場合、クライアント側の暗号化が有効にされたときやローカル端末間で転送が実行されたときなど、アプリのデータがユーザーのバックアップに格納される端末条件を定義することができます。

Android 端末上のデータのバックアップに関する詳細は、データ バックアップの概要をご確認ください。

ユーザー補助機能

Android 9 では、アプリのユーザーにさらに優れたエクスペリエンスを簡単に提供できるようにするユーザー補助機能フレームワークが強化されています。

ナビゲーション セマンティクス

Android 9 に追加された属性により、特にスクリーン リーダーなどのユーザー補助機能サービスが画面の一部から別の部分に移動する方法を簡単に定義できるようになりました。 これらの属性を使用すると、視覚障がいを持つユーザーがアプリの UI のテキストをすばやく読んで選択できるようになります。

ショッピング アプリを例にとると、スクリーン リーダーは、あるお買い得品カテゴリから別のカテゴリへとユーザーを直接移動させることができます。その際、別のカテゴリに移動する前に、そのカテゴリに含まれるすべてのアイテムを読み取る必要はありません。

ユーザー補助機能のペイン タイトル

Android 8.1（API レベル 27）以前のユーザー補助機能サービスでは、アクティビティが 1 つのフラグメントを別のフラグメントに置き換えるときなど、画面の特定のペインがアップデートされたタイミングを常に判別することは不可能でした。 ペインは、論理的にグループ化された視覚的に関連する UI 要素（通常、フラグメントを構成する）で構成されます。

Android 9 では、これらのペインに対して、ユーザー補助機能のペイン タイトルまたは個別に識別できるタイトルを指定することができます。 ペインにユーザー補助機能のペイン タイトルがある場合、ユーザー補助機能サービスは、ペインが変更されたときにより詳細な情報を受け取ります。 この機能を使用すると、サービスを通じて、UI の変更点に関するより詳しい情報をユーザーに提供することができます。

ペインのタイトルを指定するには、android:accessibilityPaneTitle 属性を使用します。 または、setAccessibilityPaneTitle() を使用して、実行時に置換される UI ペインのタイトルをアップデートすることも可能です。 たとえば、Fragment オブジェクトのコンテンツ領域にタイトルを指定することができます。

見出しベースのナビゲーション

アプリに論理的な見出しを含むテキスト コンテンツが表示されている場合、その見出しを表示している View のインスタンスに対して、android:accessibilityHeading 属性を true に設定します。 これらの見出しを追加すると、ユーザー補助機能サービスでユーザーを 1 つの見出しから次の見出しに直接移動させることができます。 すべてのユーザー補助機能サービスでこの機能を使用して、ユーザーの UI ナビゲーション エクスペリエンスを向上させることができます。

グループ ナビゲーションと出力

以前より、スクリーン リーダーでは、android:focusable 属性を使用して、View オブジェクトのコレクションである ViewGroup を 1 つのユニットとして読み上げるタイミングを判定してきました。 これにより、ユーザーは、ビューが相互に論理的に関連していることを理解できました。

Android 8.1 以前では、ViewGroup 内の各 View オブジェクトをフォーカス不可に、ViewGroup 自体をフォース可能に指定する必要がありました。 こうした処理により、一部の View インスタンスがフォーカス可能に指定されてしまい、キーボード操作が煩雑になっていました。

Android 9 以降では、View オブジェクトをフォーカス可能に指定することで好ましくない副作用が生じる場合は、android:focusable 属性の代わりに android:screenReaderFocusable 属性を使用できます。 スクリーン リーダーは、android:screenReaderFocusable または android:focusable を true に設定したすべての要素にフォーカスを当てます。

便利なアクション

Android 9 では、ユーザーの代わりに便利なアクションを実行するサポートが追加されています。

ツールチップの利用

ユーザー補助機能フレームワークの追加機能を使用すると、アプリの UI でツールチップを利用できます。 ツールチップのテキストを読み上げるには getTooltipText() を使用します。View インスタンスにツールチップを表示または非表示にするよう指定するには、ACTION_SHOW_TOOLTIP または ACTION_HIDE_TOOLTIP を使用します。

グローバル アクションの追加

Android 9 では、AccessibilityService クラスで 2 つの追加端末アクションがサポートされます。 ユーザーが端末をロックできるようにするには、サービスで GLOBAL_ACTION_LOCK_SCREEN アクションを使用し、スクリーンショットの撮影をサポートするには、GLOBAL_ACTION_TAKE_SCREENSHOT アクションを使用します。

ウィンドウ変更の詳細

Android 9 では、アプリが複数のウィンドウを同時に再描画した際に、アプリ ウィンドウの更新内容を容易にトラックできます。 TYPE_WINDOWS_CHANGED イベントが発生したら、getWindowChanges() API を使用して、ウィンドウの変更内容を確認します。 マルチ ウィンドウの更新中は、各ウィンドウが独自のイベントセットを生成します。 getSource() メソッドは、各イベントに関連付けられたウィンドウのルートビューを返します。

アプリが View オブジェクトに対してユーザー補助機能のペイン タイトルを定義している場合は、サービスでアプリの UI が更新されたタイミングを検知することができます。 TYPE_WINDOW_STATE_CHANGED イベントが発生したら、getContentChangeTypes() から返されるタイプを使用して、ウィンドウの変更内容を特定します。 たとえばフレームワークでは、ペインに新しいタイトルが追加されたタイミングや、ペインが非表示になったタイミングを検知できます。

回転

画面が意図せず回転するのを避けるため、端末の位置が変化しても、現在の画面の向きを固定するモードが導入されました。 ユーザーは、システムバーにあるボタンをタップすることで、必要に応じて手動で画面を回転させることができます。

大半のケースにおいて、アプリの互換性への影響はごくわずかです。 ただし、アプリで回転動作をカスタマイズしていたり、特殊な画面の向きの設定を使用していたりする場合は、ユーザーの回転設定が常に縦向きに設定されていたときには気づかなかった問題が発生する可能性があります。 そのため、アプリに含まれるすべての主要な Activity について回転動作を確認し、画面の向きがどの設定になっていても最適なエクスペリエンスが実現されるようにしてください。

詳細については、関連する動作の変更点をご覧ください。

新しい回転モードでは、ユーザーが必要に応じてシステムバーのボタンから手動で画面の向きを変更可能

テキスト

Android 9 のプラットフォームは、次のテキスト関連の機能を備えています。

• 事前計算済みテキスト: PrecomputedText クラスにより、事前に必要な情報を計算およびキャッシュできるため、テキスト表示のパフォーマンスが向上します。 さらに、アプリがメインスレッド以外でテキスト レイアウトを実行できるようにします。

• 拡大鏡: Magnifier クラスは Magnifier API を提供するプラットフォーム ウィジェットであり、すべてのアプリで一貫した拡大鏡機能を使用できるようにします。

• Smart Linkify: Android 9 では、TextClassifier クラスが強化されており、機械学習を活用して、選択したテキストのいくつかのエンティティを特定したり、アクションを提案したりします。 たとえば、TextClassifier を使用すると、ユーザーが電話番号を選択したことをアプリで検出することができます。 その後、アプリは、ユーザーがその電話番号を使用して電話をかけることを示唆できます。 TextClassifier の機能は、Linkify クラスの機能に代わるものです。

• テキスト レイアウト: いくつかの便利なメソッドと属性により、UI デザインの実装が簡単になりました。 詳細は、TextView のリファレンス ドキュメントをご覧ください。

ART での DEX ファイルの Ahead-of-time 変換

Android 9 以降を実行する端末では、Android ランタイム（ART）の Ahead-Of-Time コンパイラでアプリ パッケージの DEX ファイルをよりコンパクトな表現に変換することにより、圧縮された Dalvik 実行形式（DEX）ファイルがさらに最適化されます。 この変更により、アプリの起動を高速化し、ディスク スペースと RAM の消費を抑えることができます。

この改善は、特にディスク I/O の速度が低いローエンド端末にメリットをもたらします。

オンデバイス システム トレース

Android 9 では、端末から System Trace を記録してから、これらの記録のレポートを開発チームと共有することができます。 このレポートは、HTML などの複数の形式をサポートしています。

これらのトレースを収集することにより、アプリのプロセスとスレッドに関連するタイミング データを取得したり、その他のタイプのグローバルに重要な端末状態を表示したりできます。

注: コードを計測してトレースを記録する必要はありませんが、この操作を行うと、スレッドのハングやぎこちない UI の原因になっているアプリのコード部分を確認することができます。

このツールの詳細は、オンデバイス システム トレースの実行をご覧ください。