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 を登録して、地域の設定が変更されたときに言語 / 地域の構成の変更を処理することも可能です。
これらの設定を確認するには、設定アプリを開いて [システム] > [言語と入力] > [地域の設定] に移動します。
ユーザー補助
非線形フォント スケーリングを 200% にする
Android 14 以降では、フォント スケーリングが 200% までサポートされます。これにより、ロービジョンのユーザーは、Web Content Accessibility Guidelines（WCAG）に準拠した追加のユーザー補助オプションを利用できます。
画面上の大きなテキスト要素が拡大しすぎないように、システムでは非線形のスケーリング曲線が適用されます。このスケーリング戦略では、大きいテキストが小さいテキストとは異なる率でスケーリングされます。非線形フォント スケーリングでは、異なるサイズの要素間の比例階層を維持したまま、線形テキスト スケーリングの高度な問題（テキストが途切れる、表示サイズが極端に大きいためにテキストが読みづらくなるなど）を軽減できます。
非線形フォント スケーリングでアプリをテストする
すでにスケーリング ピクセル（sp）単位を使用してテキストのサイズを定義している場合は、これらの追加オプションとスケーリングの改善がアプリのテキストに自動的に適用されます。ただし、アプリがフォントサイズを正しく適用し、ユーザビリティに影響を与えずにより大きなフォントサイズに対応できることを確認するには、最大フォントサイズ（200%）を有効にして UI テストを行う必要があります。
200% のフォントサイズを有効にする手順は次のとおりです。
- 設定���プリを開き、[ユーザー補助] > [表示サイズとテキスト] に移動します。
- [フォントサイズ] オプションでは、最大フォントサイズの設定が有効になるまで、プラス（+）アイコンをタップします（この���クションに表示される画像で確認できます）。
テキストサイズにはスケール非依存ピクセル（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
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()コールバックを実装します。 拡張機能固有のメタデータ（拡張機能の効果の量を調整する
CaptureRequest.EXTENSION_STRENGTH（EXTENSION_BOKEHでの背景のぼかし量など））。カメラ拡張機能の静止画撮影用のポストビュー機能。最終画像よりも処理の少ない画像をすばやく表示できます。拡張機能の処理レイテンシが増加した場合は、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 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 では、より有用な結果をユーザーに提供するため、アプリからのより多くのシグナルを使用し��ダイレクト シェア ターゲットのランキングが決定されます。ランキングのための最も有用なシグナルを提供するには、ダイレクト シェア ターゲットのランキングの改善のガイダンスに従ってください。通信アプリでは、送受信メッセージのショートカットの使用状況を報告することもできます。
予測型「戻る」の組み込みアニメーションとカスタム アニメーションのサポート
Android 13 では、開発者向けオプションの背後に予測型のホームに戻るアニメーションが導入されました。開発者向けオプションを有効にした対応アプリで、右にスワイプすると、「戻る」ジェスチャーによってアプリが終了してホーム画面に戻ることを示すアニメーションが表示されます。
Android 14 では、予測型「戻る」に関するさまざまな改善と新しいガイダンスが追加されています。
android:enableOnBackInvokedCallback=trueを設定すると、アプリ全体ではなく、アクティビティごとに予測型「戻る」システム アニメーションを有効にできます。- Android 13 から、ホームに戻るアニメーションに付随する新しいシステム アニメーションが追加されました。新しいシステム アニメーションは、アクティビティ間およびタスク間であり、予測型「戻る」に移行すると自動的に取得されます。
- ボトムシート、サイドシート、検索に、新しいマテリアル コンポーネント アニメーションを追加しました。
- カスタムのアプリ内アニメーションと遷移を作成するための設計ガイダンスを作成しました。
- カスタムのアプリ内遷移アニメーションをサポートする新しい API を追加しました。
handleOnBackStarted、handleOnBackProgressed、handleOnBackCancelledinOnBackPressedCallbackonBackStarted、onBackProgressed、onBackCancelledinOnBackAnimationCallback- ユーザーが後方にスワイプしたときに応答する遷移には、
overridePendingTransitionではなくoverrideActivityTransitionを使用します。
この 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 永続性を有効にする] でこの機能を有効にします。
次に、サポートされているアプリで会話を開くと、着信メッセージに応じて LLM を活用したスマート リプライが Gboard の候補領域に表示されます。
グラフィック
パスのクエリと補間が可能
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 を介したシステム コンポジタとの通信が含まれる場合に、低レイテンシの描画に特に役立ちます。