機能と 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 和 intent（例如 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 でサポートしています。

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

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

ヘルスコネクト

Health Connect 是用户健康与健身数据的设备端仓库。借助该功能，用户可以在一个位置控制要与这些应用共享哪些数据，并在自己喜爱的应用之间共享数据。

在搭载 Android 14 之前的 Android 版本的设备上，Health Connect 可作为应用从 Google Play 商店下载。从 Android 14 开始，Health Connect 将成为 Android 平台的一部分，并通过 Google Play 系统更新接收更新，而无需单独下载。这样一来，Health Connect 就可以频繁更新，您的应用可以依赖于搭载 Android 14 或更高版本的设备上提供的 Health Connect。用户可以通过设备的“设置”访问 Health Connect，隐私控制功能集成到系统设置中。

用户无需在搭载 Android 14 或更高版本的设备上单独下载应用，即可开始使用 Health Connect。
用户可以通过系统设置控制哪些应用可以访问其健康与健身数据。

Health Connect 在 Android 14 中包含多项新功能，例如锻炼路线，可让用户分享可在地图上直观呈现的锻炼路线。路线定义为在一定时间范围内保存的位置列表，您的应用可以将路线插入锻炼时段，将它们关联起来。为确保用户能够完全控制此类敏感数据，用户必须允许与其他应用共享单个路线。

如需了解详情，请参阅 Health Connect 文档以及有关 Android Health 中的新功能的博文。

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 では、大画面デバイスの新しい設定メニューを使用して、アプリごとのオーバーライドを適用できるようになりました。

アプリの画面共有

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

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

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

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

12 月の機能ドロップが適用された Google Pixel 8 Pro デバイスでは、Google Tensor で実行されるオンデバイスの大規模言語モデル（LLM）を活用した、Gboard の品質の高いスマート リプライをデベロッパーが試すことができます。

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

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

次に、対応するアプリで会話を開くと、受信したメッセージに応じて 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 颜色混合。Uniform 可以传递到片段着色器和顶点着色器，以提高灵活性。

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

Android の Canvas API を使った描画をサポートする HardwareBuffer へのハードウェア アクセラレーション（Android 14） HardwareBufferRenderer が導入されました。この API は、低レイテンシの描画のために SurfaceControl を介してシステム コンポーザとの通信が必要なユースケースに特に便利です。