機能と API の概要

Android 14 では、デベロッパー向けに優れた機能と API が導入されています。ここでは、アプリの機能を確認し、関連する API の使用を開始する方法について説明します。

追加、変更、削除された API の詳細なリストについては、API 差分レポートをご覧ください。追加された API について詳しくは、Android API リファレンスをご覧ください。Android 14 については、API レベル 34 で追加された API をご覧ください。プラットフォームの変更がアプリに影響する領域については、Android 14 の動作変更（Android 14 をターゲットとするアプリの場合）およびすべてのアプリについてをご確認ください。

多言語対応

アプリ別の言語設定

Android 14 では、Android 13（API レベル 33）で導入されたアプリ別の言語機能が拡張され、以下の機能が追加されています。

  • アプリの localeConfig の自動生成: Android Studio Giraffe Canary 7 および AGP 8.1.0-alpha07 以降では、アプリで自動的にアプリ別の言語設定をサポートするよう設定できます。Android Gradle プラグインは、プロジェクト リソースに基づいて LocaleConfig ファイルを生成し、そのファイルへの参照を最終マニフェスト ファイルに追加します。そのため、手動でファイルを作成または更新する必要はありません。AGP は、アプリ モジュールの res フォルダ内のリソースとライブラリ モジュールの依存関係を使用して、LocaleConfig ファイルに含めるロケールを決定します。

  • アプリの localeConfig の動的アップデート: LocaleManager の setOverrideLocaleConfig() メソッドと getOverrideLocaleConfig() メソッドを使用して、デバイスのシステム設定にある、アプリでサポートされる言語のリストを動的にアップデートします。この柔軟性を利用して、サポートされる言語のリストを地域ごとにカスタマイズしたり、A/B テストを実施したりできます。また、アプリがローカライズのためにサーバー側の push を使用する場合は、更新されたロケールのリストを提供できます。

  • インプット メソッド エディタ（IME）によるアプリの言語の確認: IME は getApplicationLocales() メソッドを使用して現在のアプリの言語を確認し、IME 言語をその言語と一致させます。

Grammatical Inflection API

30 億人もの人々が、性別で文法が変わる言語を話します。こうした言語では、話す相手、または言及する人や物の性別に応じて、各文法範疇（名詞、動詞、形容詞、前置詞など）の語形が変化します。伝統的に、性別で文法が変わる多くの言語では、男性形をデフォルトまたは汎用の性別として使用しています。

女性を男性形で呼ぶなど、ユーザーに対して不適切な文法的性を使用すると、ユーザーのパフォーマンスと態度に悪影響を及ぼす可能性があります。一方、ユーザーの文法的性を適切に反映した言語を使用して UI を作成すると、ユーザー エンゲージメントが向上し、より自然でパーソナライズされたユーザー エクスペリエンスを提供できます。

Android 14 では、性別で文法が変わる言語に合わせてユーザー中心の UI を構築するため、アプリをリファクタリングせずに文法上の性別への対応を追加できる Grammatical Inflection API が導入されています。

地域の設定

地域の設定を使用すると、ユーザーは温度単位、週の最初の曜日、番号体系をカスタマイズできます。米国に住んでいる欧州のユーザーの場合、温度の単位は華氏ではなく摂氏で表示し、アプリで週の始まりを米国のデフォルトの日曜日ではなく月曜日に指定することを好む可能性があります。

Android の新しい設定メニューは見つけやすく、ユーザーはここでアプリのそうした設定を一元的に変更できます。これらの設定は、バックアップや復元を行った場合も保持されます。複数の API とインテント（getTemperatureUnit や getFirstDayOfWeek など）により、アプリにそうしたユーザー設定への読み取りアクセス権を付与することで、アプリでの情報の表示方法を調整できます。また、ACTION_LOCALE_CHANGED に BroadcastReceiver を登録して、地域の設定が変更されたときに言語 / 地域の構成の変更を処理することも可能です。

これらの設定を確認するには、設定アプリを開いて [システム] > [言語と入力] > [地域の設定] に移動します。

Android システム設定の地域の設定画面
Android システム設定の地域の設定に関する温度オプション。

ユーザー補助

非線形フォント スケーリングを 200% にする

Android 14 以降では、フォント スケーリングが 200% までサポートされます。これにより、ロービジョンのユーザーは、Web Content Accessibility Guidelines（WCAG）に準拠した追加のユーザー補助オプションを利用できます。

画面上の大きなテキスト要素が拡大しすぎないように、システムでは非線形のスケーリング曲線が適用されます。このスケーリング戦略では、大きいテキストが小さいテキストとは異なる率でスケーリングされます。非線形フォント スケーリングでは、異なるサイズの要素間の比例階層を維持したまま、線形テキスト スケーリングの高度な問題（テキストが途切れる、表示サイズが極端に大きいためにテキストが読みづらくなるなど）を軽減できます。

非線形フォント スケーリングでアプリをテストする

デバイスのユーザー補助設定で最大フォントサイズを有効にして、アプリをテストします。

すでにスケーリング ピクセル（sp）単位を使用してテキストのサイズを定義している場合は、これらの追加オプションとスケーリングの改善がアプリのテキストに自動的に適用されます。ただし、アプリがフォントサイズを正しく適用し、ユーザビリティに影響を与えずにより大きなフォントサイズに対応できることを確認するには、最大フォントサイズ（200%）を有効にして UI テストを行う必要があります。

200% のフォントサイズを有効にする手順は次のとおりです。

  1. 設定アプリを開き、[ユーザー補助] > [表示サイズとテキスト] に移動します。
  2. [フォントサイズ] オプションでは、最大フォントサイズの設定が有効になるまで、プラス（+）アイコンをタップします（このセクションに表示される画像で確認できます）。

テキストサイズにはスケール非依存ピクセル（sp）単位を使用する

テキストサイズは常に sp 単位で指定してください。アプリで sp 単位を使用している場合、Android はユーザーが希望するテキストサイズを適用して適切にスケーリングできます。

パディングに sp 単位を使用したり、暗黙的なパディングを前提としてビューの高さを定義したりしないでください。非線形フォント スケーリングでは sp 寸法が比例しない可能性があるため、4 sp + 20 sp が 24 sp と等しくない場合があります。

スケール非依存ピクセル（sp）単位を変換する

sp 単位からピクセルに変換するには TypedValue.applyDimension() を使用し、ピクセルを sp に変換するには TypedValue.deriveDimension() を使用します。これらのメソッドでは、適切な非線形スケーリング曲線が自動的に適用されます。

Configuration.fontScale または DisplayMetrics.scaledDensity を使用して方程式をハードコードしないでください。フォント スケーリングは非線形であるため、scaledDensity フィールドは正確でなくなります。fontScale フィールドは、フォントが単一のスカラー値でスケーリングされなくなったため、情報提供のみを目的として使用する必要があります。

lineHeight に sp 単位を使用する

必ず dp ではなく sp 単位を使用して android:lineHeight を定義すると、行の高さがテキストに合わせてスケーリングされます。そうしないと、テキストが sp であるのに lineHeight が dp または px の場合、拡大縮小が行われず、画面が窮屈に見えます。TextView は、textSize と lineHeight の両方が sp 単位で定義されている場合にのみ、目的の比率が維持されるように lineHeight を自動的に修正します。

カメラとメディア

画像のウルトラ HDR

標準ダイナミック レンジ（SDR）とハイ ダイナミック レンジ（HDR）の画質を示すイラスト。

Android 14 では、写真の撮影時にセンサーからのより多くの情報を保持するハイ ダイナミック レンジ（HDR）画像のサポートが追加され、色鮮やかでコントラストの高い写真を撮影できるようになりました。Android は、JPEG 画像との完全な下位互換性があるウルトラ HDR 形式を使用します。そのため、アプリは HDR 画像をシームレスに相互運用し、必要に応じて標準ダイナミック レンジ（SDR）で表示します。

アプリがアクティビティ ウィンドウに HDR UI の使用をオプトインすると、マニフェスト エントリを介して、または実行時に Window.setColorMode() を呼び出して、HDR で UI にこれらの画像をレンダリングします。サポートされているデバイスでは、圧縮されたウルトラ HDR 静止画像をキャプチャすることもできます。センサーから得られる色が増えると、投稿での編集がより柔軟になります。ウルトラ HDR 画像に関連付けられた Gainmap を使用すると、OpenGL または Vulkan で画像をレンダリングできます。

カメラ拡張機能のズーム、フォーカス、ポストビューなど

Android 14 では、カメラ拡張機能がアップグレードされて改善されています。これにより、アプリでの処理時間が長くなり、サポートされているデバイスでの低光量写真などのコンピューティング負荷の高いアルゴリズムを使用して画像を改善できます。これらの機能により、カメラ拡張機能を使用する際のユーザー エクスペリエンスがさらに向上します。たとえば、次のような点が改善されています。

  • 動的な静止画撮影処理のレイテンシ推定により、現在のシーンと環境の状態に基づいて静止画撮影レイテンシをより正確に推定できます。CameraExtensionSession.getRealtimeStillCaptureLatency() を呼び出して、2 つのレイテンシ推定メソッドを持つ StillCaptureLatency オブジェクトを取得します。getCaptureLatency() メソッドは、onCaptureStarted と onCaptureProcessStarted() の間の推定レイテンシを返します。getProcessingLatency() メソッドは、onCaptureProcessStarted() と、最終的に処理済みのフレームとの間の推定レイテンシを返します。
  • キャプチャ進行状況コールバックをサポートして、長時間実行されている静止画処理オペレーションの現在の進捗状況をアプリで表示できるようにします。この機能を使用できるかどうかは、CameraExtensionCharacteristics.isCaptureProcessProgressAvailable で確認できます。利用できる場合は、進行状況（0 ～ 100）がパラメータとして渡される onCaptureProcessProgressed() コールバックを実装します。

  • 拡張機能固有のメタデータ（EXTENSION_BOKEH による背景ぼかしの量など、拡張機能効果の量をダイヤルインするための CaptureRequest.EXTENSION_STRENGTH など）。

  • カメラ拡張機能の静止画撮影用のポストビュー機能。最終画像よりも処理量の低い画像を提供します。拡張機能の処理レイテンシが増加した場合は、UX を改善するためのプレースホルダとしてポストビュー画像を指定し、後で最終的な画像に切り替えることもできます。この機能が利用可能かどうかは、CameraExtensionCharacteristics.isPostviewAvailable で確認できます。その後、OutputConfiguration を ExtensionSessionConfiguration.setPostviewOutputConfiguration に渡すことができます。

  • SurfaceView のサポート。プレビューのレンダリング パスの最適化と電力効率の向上を実現できます。

  • 拡張機能の使用中に「タップしてフォーカス」と「ズーム」をサポート。

センサー内ズーム

CameraCharacteristics の REQUEST_AVAILABLE_CAPABILITIES_STREAM_USE_CASE に SCALER_AVAILABLE_STREAM_USE_CASES_CROPPED_RAW が含まれている場合、アプリは高度なセンサー機能を使用して、ストリームのユースケースが CameraMetadata.SCALER_AVAILABLE_STREAM_USE_CASES_CROPPED_RAW に設定された RAW ターゲットで CaptureRequest を使用することで、切り抜かれた RAW ストリームに全画角と同じピクセルを表示できます。リクエストのオーバーライド コントロールを実装することで、更新されたカメラでは、他のカメラ コントロールの準備が整う前でも、ユーザーはズーム コントロールを利用できるようになります。

ロスレス USB オーディオ

Android 14 では、USB 有線ヘッドセットでオーディオ マニアレベルの体験ができるロスレス オーディオ形式のサポートが追加されました。USB デバイスで優先されるミキサー属性のクエリ、優先されるミキサー属性の変更に対するリスナーの登録、AudioMixerAttributes クラスを使用したミキサー属性の設定を行うことができます。このクラスは、チャンネル マスク、サンプルレート、オーディオ ミキサーの動作などの形式を表します。このクラスを使用すると、ミキシング、音量調整、処理エフェクトなしに、音声を直接送信できます。

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

認証情報マネージャー

Android 14 では、プラットフォーム API として認証情報マネージャーが追加されています。また、Google Play 開発者サービスを使用する Jetpack ライブラリを介して、Android 4.4（API レベル 19）デバイスに対するサポートが追加されています。認証情報マネージャーは、ユーザーが構成した認証情報プロバイダを使用して認証情報を取得、保存する API を使用して、ユーザーがログインしやすくすることを目的としています。認証情報マネージャーは、ユーザー名とパスワード、パスキー、フェデレーション ログイン ソリューション（Google でログインなど）など、複数のログイン方法を 1 つの API でサポートします。

パスキーには多くの利点があります。たとえば、パスキーは業界標準に基づいて構築されており、さまざまなオペレーティング システムやブラウザのエコシステムで機能し、ウェブサイトとアプリの両方で使用できます。

詳細については、認証情報マネージャーとパスキーのドキュメントと認証情報マネージャーとパスキーに関するブログ投稿をご覧ください。

ヘルスコネクト

ヘルスコネクトは、ユーザーの健康とフィットネスに関するデータ用のオンデバイス リポジトリです。ユーザーはお気に入りのアプリ間でデータを共有でき、それらのアプリと共有するデータを 1 か所で管理できます。

Android 14 より前のバージョンの Android デバイスでは、ヘルスコネクトを Google Play ストアからアプリとしてダウンロードできます。Android 14 以降では、ヘルスコネクトはプラットフォームの一部であり、Google Play システム アップデートを通じてアップデートを受信します。別途ダウンロードする必要はありません。これにより、ヘルスコネクトは頻繁に更新され、アプリは Android 14 以降を搭載したデバイスでヘルスコネクトを利用できます。ユーザーはデバイスの設定からヘルスコネクトにアクセスし、プライバシー管理がシステム設定に統合されています。

Android 14 以降を搭載したデバイスでは、ユーザーは別途アプリをダウンロードすることなく、ヘルスコネクトの使用を開始することができます。
ユーザーは、健康とフィットネスに関するデータにアクセスできるアプリをシステム設定から管理できます。

ヘルスコネクトには、Android 14 の新機能（エクササイズのルートなど）がいくつか含まれており、ユーザーはワークアウトのルートを共有して、マップに表示できます。ルートは、一定の時間枠内に保存される場所のリストとして定義されます。アプリはエクササイズ セッションにルートを挿入し、関連付けることができます。ユーザーがこの機密データを完全に制御できるように、ユーザーは個々のルートを他のアプリと共有できるようにする必要があります。

詳しくは、ヘルスコネクトのドキュメントと Android Health の新機能に関するブログ投稿をご覧ください。

OpenJDK 17 の更新

Android 14 では、最新の OpenJDK LTS リリースの機能に合わせて Android のコアライブラリを更新する取り組みが引き続き行われています。これには、アプリ デベロッパーとプラットフォーム デベロッパー向けのライブラリの更新と Java 17 言語のサポートが含まれます。

主な機能と改善点は次のとおりです。

  • 約 300 の java.base クラスを、Java 17 をサポートするように更新しました。
  • テキスト ブロック: Java プログラミング言語で複数行の文字列リテラルを記述できます。
  • instanceof: パターン マッチング: 追加の変数なしで、オブジェクトを instanceof 内で特定の型を持つものとして扱うことができます。
  • シールクラス: 拡張または実装できるクラスとインターフェースを制限できます。

Google Play システム アップデート（プロジェクト Mainline）により、6 億台を超えるデバイスが、こうした変更を含む最新の Android ランタイム（ART）アップデートを受け取ることができます。これは、さまざまなデバイスでアプリにとって一貫した安全性の高い環境を実現し、プラットフォーム リリースに依存することなく新機能をユーザーに提供するための Google の取り組みの一環です。

Java および OpenJDK は、Oracle およびその関連会社の商標または登録商標です。

アプリストアの改善

Android 14 では、アプリストアでのユーザー エクスペリエンスを改善するための PackageInstaller API がいくつか導入されています。

ダウンロードする前にインストールの承認をリクエストする

アプリをインストールまたは更新する際に、ユーザーの承認が必要になる場合があります。たとえば、REQUEST_INSTALL_PACKAGES 権限を使用するインストーラが新しいアプリをインストールしようとした場合などです。それより前のバージョンの Android では、APK がインストール セッションに書き込まれてセッションがcommit された後にのみ、アプリストアでユーザーの承認をリクエストできます。

Android 14 以降では、requestUserPreapproval() メソッドを使用して、インストール セッションを commit する前にユーザーの承認をリクエストできます。この改善により、ユーザーがインストールを承認するまで、アプリストアで APK のダウンロードが延期されます。さらに、ユーザーがインストールを承認すると、アプリストアはユーザーの作業を妨げることなく、バックグラウンドでアプリをダウンロードしてインストールできます。

今後の更新に責任を持つことを示す

setRequestUpdateOwnership() メソッドを使用すると、インストーラは、インストール中のアプリの今後のアップデートに責任を持つことをシステムに示すことができます。この機能により、更新の所有権の適用が可能になります。つまり、更新の所有者のみがアプリに自動更新をインストールできます。更新の所有権の適用により、ユーザーは想定されるアプリストアからのみ更新を受け取るようになります。

その他のインストーラ（INSTALL_PACKAGES 権限を利用するものを含む）がアップデートをインストールするには、ユーザーの明示的な承認を得る必要があります。ユーザーが別のソースから更新を進めることにした場合、更新の所有権は失われます。

影響が少ないタイミングでアプリを更新する

アプリストアは通常、アクティブに使用されているアプリを更新することはありません。これは、アプリの実行中のプロセスが強制終了され、ユーザーの操作が中断される可能性があるためです。

Android 14 以降では、InstallConstraints API を使用することで、インストーラはアプリのアップデートを適切なタイミングで実施できます。たとえば、アプリストアで commitSessionAfterInstallConstraintsAreMet() メソッドを呼び出して、ユーザーが対象のアプリを操作しなくなった場合にのみ更新が commit されるようにできます。

オプションの分割をシームレスにインストールする

分割 APK を使用すると、アプリの機能をモノリシック APK としてではなく、別々の APK ファイルで配信できます。これにより、アプリストアでさまざまなアプリ コンポーネントの配信を最適化できます。たとえば、アプリストアは、ターゲット デバイスのプロパティに基づいて最適化できます。PackageInstaller API は、API レベル 22 で導入されて以来、分割をサポートしています。

Android 14 では、setDontKillApp() メソッドにより、新しい分割がインストールされたときに、アプリの実行中のプロセスを強制終了すべきでないことを示すことができます。アプリストアでは、この機能を使用して、ユーザーがアプリを使用している間、アプリの新しい機能をシームレスにインストールできます。

アプリのメタデータ バンドル

Android 14 以降では、Android パッケージ インストーラを使用して、データ セーフティ方針などのアプリのメタデータを指定して、Google Play などのアプリストア ページに追加できます。

ユーザーがデバイスのスクリーンショットを撮影したときに検出する

Android 14 では、スクリーンショットの検出の標準化されたエクスペリエンスを実現するため、プライバシーを保護するスクリーンショット検出 API が導入されました。この API を使用すると、アプリはアクティビティごとにコールバックを登録できます。アクティビティが表示されている間にユーザーがスクリーンショットを撮ると、これらのコールバックが呼び出され、ユーザーに通知されます。

ユーザー エクスペリエンス

共有シートのカスタム アクションとランキングの改善

Android 14 では、システム共有シートが更新され、カスタムのアプリ アクションと有益なプレビュー結果をユーザーに提供できるようになりました。

カスタム アクションを追加する

Android 14 では、アプリで呼び出すシステム共有シートにカスタム アクションを追加できます。

共有シートのカスタム アクションのスクリーンショット。

直接共有ターゲットのランキングを改善する

Android 14 では、より有用な結果をユーザーに提供するため、アプリからのより多くのシグナルを使用してダイレクト シェア ターゲットのランキングが決定されます。ランキングのための最も有用なシグナルを提供するには、ダイレクト シェア ターゲットのランキングの改善のガイダンスに従ってください。通信アプリでは、送受信メッセージのショートカットの使用状況を報告することもできます。

共有シートの [ダイレクト シェア] 行（1 を参照）

予測型「戻る」の組み込みアニメーションとカスタム アニメーションのサポート

動画: 予測型「戻る」アニメーション

Android 13 では、開発者向けオプションの背後に、予測型のホームに戻るアニメーションが導入されました。開発者向けオプションを有効にしたサポートされているアプリで使用した場合、下にスワイプすると、「戻る」ジェスチャーでアプリを終了してホーム画面に戻ることを示すアニメーションが表示されます。

Android 14 では、予測型戻る機能に関して複数の改善と新しいガイダンスが追加されています。

この Android 14 プレビュー リリースでは、予測型戻る機能のすべての機能が開発者向けオプションで提供されています。詳しくは、アプリを予測型「戻る」に移行するデベロッパー ガイドと、カスタムのアプリ内遷移を作成するためのデベロッパー ガイドをご覧ください。

大画面デバイス メーカーのアプリごとのオーバーライド

アプリごとのオーバーライドにより、デバイス メーカーは大画面デバイスでのアプリの動作を変更できます。たとえば、FORCE_RESIZE_APP オーバーライドは、アプリ マニフェストで resizeableActivity="false" が設定されている場合でも、ディスプレイの寸法に合わせてアプリのサイズを変更するようシステムに指示します（サイズ互換モードを回避します）。

オーバーライドは、大画面でのユーザー エクスペリエンスを改善することを目的としています。

新しいマニフェスト プロパティを使用すると、アプリに対して一部のデバイス メーカーのオーバーライドを無効にできます。

大画面のユーザーのアプリごとのオーバーライド

アプリごとのオーバーライドにより、大画面デバイスでのアプリの動作が変わります。たとえば、OVERRIDE_MIN_ASPECT_RATIO_LARGE デバイス メーカーのオーバーライドは、アプリの設定に関係なく、アプリのアスペクト比を 16:9 に設定します。

Android 14 QPR1 では、大画面デバイスで新しい設定メニューを使用して、アプリごとのオーバーライドを適用できます。

アプリの画面共有

アプリの画面共有を使用すると、ユーザーは画面コンテンツの録画中にデバイス画面全体ではなくアプリのウィンドウを共有できます。

アプリの画面共有では、ステータスバー、ナビゲーション バー、通知、その他のシステム UI 要素が共有ディスプレイから除外されます。選択したアプリのコンテンツのみが共有されます。

アプリの画面共有により、ユーザーは複数のアプリを実行できるが、コンテンツの共有は 1 つのアプリに限定されるため、生産性とプライバシーが向上します。

Google Pixel 8 Pro の Gboard での LLM を活用したスマート リプライ

12 月の Feature Drop が適用された Google Pixel 8 Pro デバイスでは、デベロッパーは、Google Tensor で動作するデバイス上の大規模言語モデル（LLM）を利用した Gboard で、より高品質のスマート リプライをお試しいただけます。

この機能は、英語（米国）向けの限定プレビュー版として WhatsApp、Line、KakaoTalk で利用できます。Google Pixel 8 Pro デバイスで Gboard をキーボードとして使用する必要があります。

試用するには、まず [設定] > [開発者向けオプション] > [AiCore 設定] > [Aicore Persistent を有効にする] でこの機能を有効にします。

次に、対応アプリで会話を開くと、着信メッセージに対する LLM を活用したスマート リプライが Gboard の候補ストリップに表示されます。

Gboard はオンデバイス LLM を利用して、より質の高いスマート リプライを提供します。

グラフィック

パスはクエリと補間が可能

Android の Path API は、ベクター グラフィックの作成とレンダリングを行うための強力かつ柔軟なメカニズムです。パスのストロークや塗りつぶし、線分、2 次曲線、3 次曲線からのパスの作成、ブール演算による複雑なシェイプの取得、またはこれらすべてを同時に行うことが可能です。制限の一つは、Path オブジェクトに実際に何が含まれているかを確認する機能です。作成後は、オブジェクトの内部は呼び出し元には不透明です。

Path を作成するには、moveTo()、lineTo()、cubicTo() などのメソッドを呼び出して、パスセグメントを追加します。しかし、これまではパスのパスにセグメントの内容を確認する手段がなかったため、その情報は作成時に保持する必要があります。

Android 14 以降では、パスをクエリしてパスの内部を調べることができます。まず、Path.getPathIterator API を使用して PathIterator オブジェクトを取得する必要があります。

Kotlin

val path = Path().apply {
    moveTo(1.0f, 1.0f)
    lineTo(2.0f, 2.0f)
    close()
}
val pathIterator = path.pathIterator

Java

Path path = new Path();
path.moveTo(1.0F, 1.0F);
path.lineTo(2.0F, 2.0F);
path.close();
PathIterator pathIterator = path.getPathIterator();

次に、PathIterator を呼び出してセグメントを 1 つずつ反復し、各セグメントに必要なすべてのデータを取得できます。この例では、データをパッケージ化する PathIterator.Segment オブジェクトを使用します。

Kotlin

for (segment in pathIterator) {
    println("segment: ${segment.verb}, ${segment.points}")
}

Java

while (pathIterator.hasNext()) {
    PathIterator.Segment segment = pathIterator.next();
    Log.i(LOG_TAG, "segment: " + segment.getVerb() + ", " + segment.getPoints());
}

PathIterator には、next() の非割り当てバージョンもあり、バッファを渡してポイントデータを保持できます。

Path データのクエリを行う重要なユースケースの一つに、補間があります。たとえば、2 つの異なるパス間でアニメーション化（モーフィング）できます。このユースケースをさらに簡素化するために、Android 14 では Path に interpolate() メソッドも追加されています。2 つのパスの内部構造が同じ場合、interpolate() メソッドはその補間された結果を使用して新しい Path を作成します。この例では、形状が path と otherPath の中間（.5 の線形補間）のパスを返します。

Kotlin

val interpolatedResult = Path()
if (path.isInterpolatable(otherPath)) {
    path.interpolate(otherPath, .5f, interpolatedResult)
}

Java

Path interpolatedResult = new Path();
if (path.isInterpolatable(otherPath)) {
    path.interpolate(otherPath, 0.5F, interpolatedResult);
}

Jetpack の graphics-path ライブラリを使用すると、以前のバージョンの Android でも同様の API を使用できます。

頂点シェーダーとフラグメント シェーダーを使用したカスタム メッシュ

Android は以前から、カスタム シェーディングを使用した三角形メッシュの描画をサポートしていますが、入力メッシュ形式はいくつかの事前定義済み属性の組み合わせに限定されています。Android 14 では、カスタム メッシュのサポートが追加されています。カスタム メッシュは、三角形または三角形のストリップとして定義され、オプションでインデックスを付けることができます。これらのメッシュは、カスタム属性、頂点ストライド、可変、AGSL で記述された頂点シェーダーとフラグメント シェーダーで指定されます。

頂点シェーダーは、位置や色などの変化を定義します。フラグメント シェーダーは、頂点シェーダーによって作成された変化を使用して、必要に応じてピクセルの色を定義できます。フラグメント シェーダーによって色が提供された場合は、メッシュの描画時に選択したブレンドモードを使用して、現在の Paint の色とブレンドされます。柔軟性を高めるために、フラグメント シェーダーと頂点シェーダーにユニフォームを渡すことができます。

Canvas 用のハードウェア バッファ レンダラ

Android の Canvas API を使用してハードウェア アクセラレーションを HardwareBuffer に描画できるように、Android 14 では HardwareBufferRenderer が導入されました。この API は、ユースケースに SurfaceControl を介したシステム コンポジタとの通信が含まれ、低レイテンシの描画を行う場合に特に便利です。