機能と 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 亿人在使用区分性别的语言，此类语言的语法类别（例如名词、动词、形容词和介词）会根据您交谈所涉及的人或物的性别而变化。传统上，许多区分性别的语言使用阳性语法性别作为默认或通用性别。

以错误的语法性别来称呼用户，例如以阳性语法性别来称呼女性，可能会对她们的表现和态度产生负面影响。相比之下，界面语言如果能正确反映用户的语法性别，就可以提高用户互动度，并提供更个性化、更自然的用户体验。

为帮助您针对区分性别的语言构建以用户为中心的界面，Android 14 引入了 Grammatical Inflection API，让您无需重构应用便能添加对语法性别的支持。

地域の設定

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

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

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

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

ユーザー補助

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

Android 14 以降では、フォント スケーリングが 200% までサポートされます。これにより、ユーザーは追加のユーザー補助オプションを利用できます。

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

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

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

スケーラブル ピクセル（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 単位を使用する

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

カメラとメディア

画像のウルトラ HDR

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

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

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

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

Android 14 では、カメラ拡張機能がアップグレードされ、改善されています。これにより、アプリはより長い処理時間を処理できるため、サポートされているデバイスで暗い場所での撮影などのコンピューティング負荷の高いアルゴリズムを使用して画像を改善できます。これらの機能により、カメラの拡張機能を使用する際のユーザー エクスペリエンスがさらに堅牢になります。主な改善点は次のとおりです。

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

  • 拡張機能固有のメタデータ（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 でログインなど）といった複数のログイン方法を単一の API でサポートしています。

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

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

ヘルスコネクト

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

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

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

ヘルスコネクトには、Android 14 の新機能がいくつか含まれています。たとえば、エクササイズ ルートを使用すると、ユーザーはワークアウトのルートを共有し、地図上に可視化できます。ルートは、一定の期間内に保存された位置情報のリストとして定義されます。アプリは、エクササイズ セッションにルートを挿入して、それらを関連付けることができます。ユーザーがこの機密データを完全に管理できるようにするには、ユーザーが個々のルートを他のアプリと共有することを許可する必要があります。

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

OpenJDK 17 の更新

Android 14 将继续更新 Android 的核心库，以与最新 OpenJDK LTS 版本中的功能保持一致，包括适合应用和平台开发者的库更新和 Java 17 语言支持。

其中包含以下功能和改进：

  • 将大约 300 个 java.base 类更新为支持 Java 17。
  • 文本块 - 为 Java 编程语言引入了多行字符串字面量。
  • instanceof 模式匹配：可让对象在 instanceof 中被视为具有特定类型，而无需任何额外的变量。
  • 密封类：允许您限制哪些类和接口可以扩展或实现它们。

得益于 Google Play 系统更新 (Project Mainline)，6 亿多台设备能够接收包含这些更改的最新 Android 运行时 (ART) 更新。我们致力于为应用提供更加一致、安全的跨设备环境，并为用户提供独立于平台版本的新功能。

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，用户可以在大屏设备上通过新的设置菜单应用按应用替换项。

アプリの画面共有

借助应用界面共享功能，用户可以在录制屏幕内容时共享应用窗口，而不是整个设备屏幕。

在应用屏幕共享模式下，状态栏、导航栏、通知和其他系统界面元素会从共享显示屏中排除。系统只会分享所选应用的内容。

应用屏幕共享功能可让用户运行多个应用，但将内容共享限制为单个应用，从而提高工作效率并保护隐私。

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

在搭载 12 月功能分块的 Pixel 8 Pro 设备上，开发者可以在 Gboard 中试用质量更高的智能回复，这些回复由在 Google Tensor 上运行的设备端大语言模型 (LLM) 提供支持。

此功能目前仅在 WhatsApp、Line 和 KakaoTalk 中以美式英语的形式提供给用户进行小范围测试。此功能需要使用 Pixel 8 Pro 设备，并将 Gboard 用作键盘。

如需试用此功能，请先依次前往设置 > 开发者选项 > AiCore 设置 > 启用 Aicore 持久性，启用该功能。

接下来，在受支持的应用中打开对话，即可在 Gboard 的建议栏中看到依托 LLM 的智能回复，以便回复收到的消息。

Gboard 利用设备端 LLM 提供更高质量的智能回复。

グラフィック

パスのクエリと補間に対応

Android の Path API は、ベクター グラフィックを作成およびレンダリングするための強力で柔軟なメカニズムです。パスのストロークや塗りつぶし、線分、二次曲線、三次曲線からのパスの作成、ブール演算による複雑な図形の取得、これらすべてを同時に実行することもできます。1 つの制限は、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 の中間（0 .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 を介してシステム コンポーザとの通信が必要なユースケースに特に便利です。