機能と 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 では、性別で文法が変わる言語に合わせてユーザー中心の UI を構築するため、アプリをリファクタリングせずに文法上の性別への対応を追加できる 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 升级并改进了相机扩展程序，让应用能够处理更长的处理时间，从而支持在受支持的设备上使用计算密集型算法（例如弱光摄影）来改善图片。这些功能可让用户在使用相机扩展功能时获得更出色的体验。这些改进的示例包括：

センサー内ズーム

当 CameraCharacteristics 中的 REQUEST_AVAILABLE_CAPABILITIES_STREAM_USE_CASE 包含 SCALER_AVAILABLE_STREAM_USE_CASES_CROPPED_RAW 时，您的应用可以使用高级传感器功能，将剪裁后的 RAW 数据流的像素与全视野范围相同，方法是将 CaptureRequest 与将数据流用例设置为 CameraMetadata.SCALER_AVAILABLE_STREAM_USE_CASES_CROPPED_RAW 的 RAW 目标搭配使用。通过实现请求替换控件，更新后的相机可让用户在其他相机控件准备就绪之前使用缩放控件。

ロスレス USB オーディオ

Android 14 支持无损音频格式，可通过 USB 有线耳机提供发烧友级体验。您可以查询 USB 设备的首选混音器属性，注册监听器以监听首选混音器属性的更改，以及使用 AudioMixerAttributes 类配置混音器属性。此类表示音频混音器的格式，例如声道掩码、采样率和行为。该类允许直接发送音频，而无需混音、调节音量或处理效果。

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

認証情報マネージャー

Android 14 将 Credential Manager 添加为平台 API，并通过使用 Google Play 服务的 Jetpack 库，向后额外支持 Android 4.4（API 级别 19）设备。Credential Manager 旨在通过 API 使用用户配置的凭据提供程序检索和存储凭据，让用户更轻松地登录。Credential Manager 在单个 API 中支持多种登录方法，包括用户名和密码、通行密钥和联合登录解决方案（如“使用 Google 账号登录”）。

通行密钥具有许多优势。例如，通行密钥是基于业界标准构建的，可在各种不同的操作系统和浏览器生态系统中使用，并且可用于网站和应用。

如需了解详情，请参阅 Credential Manager 和通行密钥文档以及介绍 Credential Manager 和通行密钥的博文。

ヘルスコネクト

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 では、最新の 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 写入安装会话并且提交会话后，应用商店才能请求用户批准。

从 Android 14 开始，requestUserPreapproval() 方法可让安装程序在提交安装会话之前请求用户批准。此项改进可让应用商店将任何 APK 的下载操作推迟到用户批准安装之后。此外，用户批准安装后，应用商店可以在后台下载并安装应用，而不会干扰用户。

承担未来更新的责任

借助 setRequestUpdateOwnership() 方法，安装程序可以向系统表明它打算负责将被安装的应用未来的更新。此 capability 可实现更新所有权强制执行，即仅允许更新所有者为应用安装自动更新。更新所有权强制执行有助于确保用户仅收到来自预期应用商店的更新。

任何其他安装程序（包括使用 INSTALL_PACKAGES 权限的安装程序）都必须获得用户的明确批准，才能安装更新。如果用户决定继续从其他来源安装更新，则会失去更新所有权。

在干扰较少的时段更新应用

应用商店通常希望避免更新正在使用的应用，因为这会导致应用正在运行的进程被终止，而这可能会中断用户正在执行的操作。

从 Android 14 开始，InstallConstraints API 让安装程序可以确保其应用更新在适当的时机进行。例如，应用商店可以调用 commitSessionAfterInstallConstraintsAreMet() 方法来确保仅在用户不再与相应应用互动时才进行更新。

无缝安装可选拆分

借助拆分 APK，应用的功能可以通过单独的 APK 文件提供，而不是以单体式 APK 的形式提供。借助拆分 APK，应用商店可以优化不同应用组件的提供。例如，应用商店可能会根据目标设备的属性进行优化。自在 API 级别 22 中引入以来，PackageInstaller API 一直支持拆分。

在 Android 14 中，setDontKillApp() 方法可让安装程序指明在安装新的拆分项时应用的运行进程不应终止。应用商店可以使用此功能，在用户使用应用时无缝安装应用的新功能。

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

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

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

为了打造更加标准化的屏幕截图检测体验，Android 14 引入了可保护隐私的屏幕截图检测 API。借助此 API，应用可以按 activity 注册回调。如果用户在该 activity 可见时截取屏幕截图，系统会调用这些回调并通知用户。

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

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

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 を介してシステム コンポーザとの通信が必要なユースケースに特に便利です。