プロダクト ニュース

Android 17 の最初のベータ版

所要時間: 7 分
Matthew McCullough
Android デベロッパー、プロダクト マネジメント担当バイス プレジデント

本日、Android 17 の最初のベータ版をリリースします。プライバシー、セキュリティ、パフォーマンスの向上を重視したプラットフォームの構築に向けた取り組みを継続しています。このビルドでは、より適応性の高い Android アプリの実現に向けた取り組みが継続され、カメラとメディア機能の大幅な強化、接続を最適化するための新しいツール、コンパニオン デバイスの拡張プロファイルが導入されています。また、今回のリリースでは、デベロッパー コミュニティに新しいリリースを提供する方法が、従来のデベロッパー プレビュー モデルから Android Canary プログラムへと根本的に変わったことも強調されています。

デベロッパー プレビューのその後

Android では、従来の「デベロッパー プレビュー」が継続的な Canary チャンネルに置き換えられました。この新しい「常時稼働」モデルには、主に 3 つのメリットがあります。

  • より迅速なアクセス: 機能と API は、四半期ごとのリリースを待つのではなく、内部テストに合格するとすぐに Canary に導入されます。
  • 安定性の向上: カナリア版での早期の「実戦テスト」により、新しい API と動作の変更が最終版に近い、より洗練されたベータ版が提供されます。
  • テストの簡素化: Canary は OTA アップデートをサポートしており(手動フラッシュは不要)、別のアップデート チャネルとして CI ワークフローとの統合が容易です。また、今後の潜在的な変更についていち早くフィードバックを提供できるため、

Android 17 のスケジュール

このベータ版から、3 月を目標とするプラットフォームの安定性のマイルストーンに迅速に移行する予定です。このマイルストーンでは、最終版の SDK/NDK API と、ほぼ最終版のアプリ向け動作が提供されます。最終リリースまでの数か月間、テストを完了できます。

timeline1.png

1 年間のリリース

Android 17 は、四半期ごとのリリースでアップデートが継続される予定です。第 2 四半期のリリースでは、アプリの動作を破壊する変更が予定されています。第 4 四半期には、追加の API と機能を備えたマイナー SDK リリースを予定しています。

timeline2.png

画面の向きとサイズ変更の制限

Android 17 ベータ版のリリースに伴い、アダプティブ ロードマップの次のフェーズに移行します。Android 17(API レベル 37)では、大画面デバイス(sw > 600 dp)の画面の向きとサイズ変更の制限に関するデベロッパーのオプトアウトが削除されます。

アプリが SDK 37 をターゲットとする場合、適応する準備ができている必要があります。ユーザーは、タブレットでのマルチタスク、デバイスの展開、デスクトップ ウィンドウ環境の使用など、あらゆる場所でアプリが動作することを期待しています。また、UI がスペースを埋め、デバイスの姿勢を尊重することを期待しています。

SDK 37 の主な変更点

Android 17 をターゲットとするアプリは、Android 16 で導入されたマニフェスト属性とランタイム API の段階的廃止との互換性を確保する必要があります。大画面(小さい方のサイズが 600 dp 以上)で実行する場合、次の属性と API は無視されます。

マニフェスト属性/API無視される値
screenOrientationportrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape
setRequestedOrientation()portrait、reversePortrait、sensorPortrait、userPortrait、landscape、reverseLandscape、sensorLandscape、userLandscape
resizeableActivityすべて
minAspectRatioすべて
maxAspectRatioすべて

除外とユーザー コントロール

これらの変更は大画面に固有のものであり、sw600dp より小さい画面(従来のスレート型フォーム ファクタのスマートフォンを含む)には適用されません。また、ゲームに分類されたアプリ(android:appCategory フラグに基づく)は、これらの制限の対象外です。

ユーザーが引き続き管理できることも重要です。システムのアスペクト比の設定で、アプリのデフォルトの動作を明示的に有効または無効にできます。

構成の変更に関する最新情報

アプリの互換性を向上させ、動画再生の中断や入力のドロップなどの状態損失を最小限に抑えるため、Activity の再作成のデフォルトの動作を更新します。Android 17 以降では、CONFIG_KEYBOARDCONFIG_KEYBOARD_HIDDENCONFIG_NAVIGATIONCONFIG_UI_MODEUI_MODE_TYPE_DESK のみが変更された場合)、CONFIG_TOUCHSCREENCONFIG_COLOR_MODE など、通常は UI の再作成を必要としない特定の構成変更について、システムはデフォルトでアクティビティを再起動しなくなります。代わりに、実行中のアクティビティは onConfigurationChanged を介してこれらの更新を単純に受け取ります。アプリがこれらの変更の際のリソースの再読み込みに完全な再起動を必要とする場合、新しい android:recreateOnConfigChanges マニフェスト属性を使用して明示的にオプトインする必要があります。この属性を使用すると、関連する定数 mccmnc、新しい定数 keyboardkeyboardHiddennavigationtouchscreencolorMode とともに、アクティビティの完全なライフサイクル(停止、破棄、再作成)をトリガーする構成の変更を指定できます。

アプリを準備する

Google では、この変更への対応を簡単に行えるように、ツールとドキュメントをリリースしました。こちらのブログ投稿では、一般的な問題に対処するための戦略など、より詳しいガイダンスをご紹介しています。向きやアスペクト比を制限することはできなくなるため、アプリは、アスペクト比の全範囲にわたるウィンドウ サイズの横向きと縦向きのレイアウトをサポートする必要があります。Android 17 ベータ版 1 を使用して、Pixel Tablet または Google Pixel Fold エミュレータ(targetSdkPreview = "CinnamonBun" に構成)でアプリをテストするか、アプリ互換性フレームワークを使用して Android 16 デバイスで UNIVERSAL_RESIZABLE_BY_DEFAULT を有効にすることをおすすめします。

パフォーマンス

ロックフリーの MessageQueue

Android 17 では、SDK 37 以上をターゲットとするアプリは、ロックフリー実装の android.os.MessageQueue の新しい実装を受け取ります。新しい実装では、パフォーマンスが向上し、フレームの欠落が減少しますが、MessageQueue の非公開フィールドとメソッドを反映するクライアントが破損する可能性があります。

世代別ガベージ コレクション

Android 17 では、ART の同時マーク圧縮コレクタに世代別ガベージ コレクションが導入されています。この最適化では、完全ヒープ コレクションに加えて、リソース消費量の少ない若い世代のコレクションをより頻繁に導入し、ガベージ コレクションの CPU コストと所要時間を全体的に削減することを目指しています。ART の改善は、Google Play システム アップデートを通じて、Android 12(API レベル 31)以降を搭載した 10 億台を超えるデバイスでも利用できます。

static final フィールドが真に final に

Android 17 以降をターゲットとするアプリは、Android 17 以降では「static final」フィールドを変更できなくなるため、ランタイムでより積極的にパフォーマンスの最適化を適用できるようになります。リフレクション(およびディープ リフレクション)を介してこれを行おうとすると、常に IllegalAccessException がスローされます。JNI の SetStatic<Type>Field メソッド ファミリーを使用して変更すると、アプリケーションが直ちにクラッシュします。

カスタム通知ビューの制限

メモリ使用量を削減するため、カスタム通知ビューのサイズを制限しています。このアップデートでは、アプリが URI を使用して既存の上限を回避できる抜け穴が解消されます。この動作はターゲット SDK バージョンによって制御され、API 37 以上をターゲットとするアプリに影響します。

新しいパフォーマンス デバッグ ProfilingManager トリガー

ProfilingManager にいくつかの新しいシステム トリガーが導入され、パフォーマンスの問題をデバッグするための詳細なデータを収集できるようになりました。これらのトリガーは、TRIGGER_TYPE_COLD_START、 TRIGGER_TYPE_OOM、 TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE です。

新しいシステム トリガーの設定方法については、トリガーベースのプロファイリングプロファイリング データの取得と分析のドキュメントをご覧ください。

メディアとカメラ

Android 17 では、シームレスなトランジションや標準化されたラウドネスなどの機能を備えた、プロフェッショナル グレードのツールがメディアアプリとカメラアプリに導入されています。

動的カメラ セッションの更新

CameraCaptureSessionupdateOutputConfigurations() を導入しました。これにより、カメラ キャプチャ セッション全体を再構成することなく、出力サーフェスを動的にアタッチおよびデタッチできます。この変更により、アプリがカメラの起動時に必要とする可能性のあるすべてのカメラ出力サーフェスを構成して保持する際のメモリコストやコードの複雑さを伴うことなく、カメラのユースケースとモード(静止画の撮影と動画の撮影など)をシームレスに切り替えることができます。これにより、操作中にユーザーに表示されるグリッチやフリーズを解消できます。

  fun updateCameraSession(session: CameraCaptureSession, newOutputConfigs:  List<OutputConfiguration>)) {
    // Dynamically update the session without closing and reopening
    try {
        
        // Update the output configurations
        session.updateOutputConfigurations(newOutputConfigs)
    } catch (e: CameraAccessException) {
        // Handle error
    }
}

論理マルチカメラ デバイスのメタデータ

複数の物理カメラ センサーを組み合わせた論理カメラを使用する場合、キャプチャに関与するすべてのアクティブな物理カメラから追加のメタデータをリクエストできるようになりました。プライマリ カメラだけでなく、すべてのアクティブな物理カメラからリクエストできます。以前は、セカンダリ アクティブ カメラからメタデータを取得するために、回避策を実装する必要がありました(たとえば、ズーム用のレンズ切り替え時にフォロワー カメラがアクティブになっている場合など)。場合によっては、不要な物理ストリームを割り当てる必要がありました。この機能では、CaptureRequestCaptureResult に新しいキー LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS が導入されます。CaptureRequest でこのキーをオンに設定すると、TotalCaptureResult に、これらの追加のアクティブな物理カメラのメタデータが含まれます。この包括的なメタデータには、TotalCaptureResult.getPhysicalCameraTotalResults() を使用してアクセスできます。これにより、カメラ アプリケーションでのリソース使用量を最適化できる詳細情報を取得できます。

Versatile Video Coding(VVC)のサポート

Android 17 では、Versatile Video Coding(VVC)規格のサポートが追加されています。これには、MediaFormatvideo/vvc MIME タイプを定義すること、MediaCodecInfo で新しい VVC プロファイルを追加すること、MediaExtractor にサポートを統合することが含まれます。この機能は、ハードウェア デコードをサポートするデバイスと対応するドライバを備えたデバイスで利用できるようになります。

動画録画の一定品質

MediaRecordersetVideoEncodingQuality() を追加しました。これにより、動画エンコーダの一定画質(CQ)モードを構成し、単純なビットレート設定を超えて動画の画質を細かく制御できます。

バックグラウンド音声の強化

Android 17 以降では、オーディオ フレームワークは、オーディオ再生、音声フォーカス リクエスト、音量変更 API などのバックグラウンド オーディオ インタラクションに対する制限を適用し、これらの変更がユーザーによって意図的に開始されるようにします。

アプリが有効なライフサイクルにないときに音声 API を呼び出そうとすると、例外がスローされたり、エラー メッセージが提供されたりすることなく、音声再生 API と音量変更 API はサイレントに失敗します。音声フォーカス API は、結果コード AUDIOFOCUS_REQUEST_FAILED で失敗します。

プライバシーとセキュリティ

クリアテキスト トラフィック属性の非推奨化

android:usesCleartextTraffic 属性は非推奨になりました。アプリのターゲットが(Android 17)以降で、対応するネットワーク セキュリティ構成なしで usesCleartextTraffic="true" に依存している場合、デフォルトでクリアテキスト トラフィックは許可されません。きめ細かい制御を行うには、ネットワーク セキュリティ構成ファイルに移行することをおすすめします。

HPKE ハイブリッド暗号

HPKE ハイブリッド暗号化の実装用の公開 Service Provider Interface(SPI)を導入します。これにより、公開鍵と対称暗号化(AEAD)の組み合わせを使用して安全な通信が可能になります。

接続性と通信

拡張 VoIP 通話履歴

アプリの VoIP 通話履歴の統合に関するユーザー設定の管理を導入します。これには、システム ダイヤルでの発信者と参加者のアバター URI のサポートが含まれます。これにより、通話履歴のプライバシーをユーザーが細かく制御できるようになり、統合された VoIP 通話履歴の視覚的な表示が充実します。

Wi-Fi 測距と近接

Wi-Fi Ranging が、新しい近接検出機能で強化され、継続的な測距と安全なピアツーピア検出をサポートします。Wi-Fi Aware の測距のアップデートには、ピア ハンドルと 11az セキュア測距の PMKID キャッシュ保存のための新しい API が含まれます。

デベロッパーの生産性とツール

コンパニオン デバイスのアプリのアップデート

デバイスの区別と権限処理を改善するため、CompanionDeviceManager に 2 つの新しいプロファイルが導入されました。

  • 医療機器: このプロファイルを使用すると、医療機器のモバイル アプリケーションは 1 回のタップで必要なすべての権限をリクエストできるため、セットアップ プロセスが簡素化されます。
  • フィットネス トラッカー: DEVICE_PROFILE_FITNESS_TRACKER プロファイルを使用すると、コンパニオン アプリはフィットネス トラッカーを管理していることを明示的に示すことができます。これにより、既存のウォッチロール権限を再利用しながら、明確なアイコンで正確なユーザー エクスペリエンスを実現できます。

また、CompanionDeviceManager で、デバイスの関連付けと Nearby 権限のリクエストに関する統合ダイアログが提供されるようになりました。AssociationRequest.Builder の新しい setExtraPermissions メソッドを活用して、既存の関連付けフロー内で付近の権限プロンプトをバンドルし、ユーザーに表示されるダイアログの数を減らすことができます。

Android 17 を使ってみる

サポートされている Pixel デバイスを登録すると、このアップデートと今後の Android ベータ版のアップデートを無線(OTA)で入手できます。Google Pixel デバイスをお持ちでない場合は、Android Studio で Android Emulator で 64 ビット システム イメージを使用することができます。

現在 Android ベータ プログラムに参加している場合は、ベータ版 1 への無線(OTA)アップデートが提供されます。

Android 26Q1 ベータ版をお使いで、26Q1 の最終安定版に移行してベータ版を終了したい場合は、26Q2 ベータ版 1 への無線(OTA)アップデートを無視して、26Q1 のリリースをお待ちください。

皆様からのフィードバックをお待ちしております。フィードバック ページから、問題の報告や機能リクエストの送信を行ってください。早期にフィードバックをお送りいただくと、最終リリースにより多くのフィードバックを反映させることができます。

Android 17 で最適な開発エクスペリエンスを実現するには、Android Studio(Panda)の最新プレビュー版を使用することをおすすめします。セットアップが完了したら、次の手順を行います。

  • 新しい SDK でコンパイルし、CI 環境でテストし、フィードバック ページのトラッカーで問題を報告してください。
  • 現在のアプリの互換性をテストし、Android 17 の変更による影響を受けるかどうかを確認します。また、Android 17 を実行しているデバイスまたはエミュレータにアプリをインストールして、徹底的にテストします。

Android 17 のリリース サイクルを通して、プレビュー/ベータ版のシステム イメージと SDK は定期的に更新されます。ベータ版ビルドをインストールすると、それ以降のすべてのプレビュー版とベータ版のアップデートが無線(OTA)で自動的に提供されます。

詳しくは、Android 17 デベロッパー サイトをご覧ください。

会話に参加する

今年後半の Platform Stability と Android 17 の最終安定版のリリースに向けて、皆様からのフィードバックは引き続き Google の最も貴重な資産となります。Canary チャンネルのアーリー アダプターでも、Beta 1 でテストしているアプリ デベロッパーでも、コミュニティに参加してフィードバックを送信することを検討してください。ぜひお聞かせください。

作成者:

続きを読む