機能と API の概要

Android 14 では、デベロッパー向けに優れた機能と API が導入されました。以下では、アプリの機能を確認し、関連する API を試すことができます。

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

多言語対応

アプリ別の言語設定

Android 14 expands on the per-app language features that were introduced in Android 13 (API level 33) with these additional capabilities:

  • Automatically generate an app's localeConfig: Starting with Android Studio Giraffe Canary 7 and AGP 8.1.0-alpha07, you can configure your app to support per-app language preferences automatically. Based on your project resources, the Android Gradle plugin generates the LocaleConfig file and adds a reference to it in the final manifest file, so you no longer have to create or update the file manually. AGP uses the resources in the res folders of your app modules and any library module dependencies to determine the locales to include in the LocaleConfig file.

  • Dynamic updates for an app's localeConfig: Use the setOverrideLocaleConfig() and getOverrideLocaleConfig() methods in LocaleManager to dynamically update your app's list of supported languages in the device's system settings. Use this flexibility to customize the list of supported languages per region, run A/B experiments, or provide an updated list of locales if your app utilizes server-side pushes for localization.

  • App language visibility for input method editors (IMEs): IMEs can utilize the getApplicationLocales() method to check the language of the current app and match the IME language to that language.

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 の寸法は比例しない場合があるため、4sp + 20sp と 24sp は異なる場合があります。

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

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

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

lineHeight には sp 単位を使用する

行の高さがテキストに合わせてスケーリングされるように、android:lineHeight は常に dp ではなく sp 単位で定義してください。テキスト メッセージに sp は 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 upgrades and improves camera extensions, allowing apps to handle longer processing times, which enables improved images using compute-intensive algorithms like low-light photography on supported devices. These features give users an even more robust experience when using camera extension capabilities. Examples of these improvements include:

センサー内ズーム

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 でサポートします。

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

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

ヘルスコネクト

Health Connect 是设备端用户健康与健身数据的存储区。它 让用户可以在喜爱的应用之间共享数据 控制他们要与这些应用分享哪些数据

在搭载 Android 14 之前版本的 Android 设备上，Health Connect 会 可在 Google Play 商店中以应用的形式下载。从 Android 14 开始，Health Connect 将成为 Android 平台的一部分，并通过 Google Play 系统更新接收更新，而无需单独下载。这样，健康 Connect 可能会经常更新，并且您的应用可以依赖于 Health Connect 在搭载 Android 14 或更高版本的设备上可用。用户可以访问“健康”应用 通过设备中的“设置”连接，以及集成到 与系统设置有关

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

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

有关详情，请参阅 Health Connection 文档以及关于 Android Health 的新变化。

OpenJDK 17 の更新

Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.

The following features and improvements are included:

  • Updated approximately 300 java.base classes to Java 17 support.
  • Text Blocks, which introduce multi-line string literals to the Java programming language.
  • Pattern Matching for instanceof, which allows an object to be treated as having a specific type in an instanceof without any additional variables.
  • Sealed classes, which allow you restrict which classes and interfaces can extend or implement them.

Thanks to Google Play system updates (Project Mainline), over 600 million devices are enabled to receive the latest Android Runtime (ART) updates that include these changes. This is part of our commitment to give apps a more consistent, secure environment across devices, and to deliver new features and capabilities to users independent of platform releases.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

アプリストアの改善

Android 14 引入了多个 PackageInstaller API，可帮助应用商店改善其用户体验。

下载之前请求批准安装

安装或更新应用可能需要用户批准。 例如，当使用 REQUEST_INSTALL_PACKAGES 权限的安装程序尝试安装新应用时。在之前的 Android 版本中，应用商店只有在 APK 写入安装会话且该会话已提交之后才能请求用户批准。

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

承担未来更新的责任

通过 setRequestUpdateOwnership() 方法，安装程序可以告知系统它打算负责未来安装的应用更新。此功能可实现更新所有权强制执行，即只有更新所有者才能为应用安装自动更新。更新所有权强制执行有助于确保用户仅从预期的应用商店接收更新。

任何其他安装程序（包括使用 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 を使用すると、アプリはアクティビティごとにコールバックを登録できます。アクティビティが表示されている間にユーザーがスクリーンショットを撮ると、これらのコールバックが呼び出され、ユーザーに通知されます。

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

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

Android 14 updates the system sharesheet to support custom app actions and more informative preview results for users.

Add custom actions

With Android 14, your app can add custom actions to the system sharesheet it invokes.

Screenshot of custom actions on the sharesheet.

Improve ranking of Direct Share targets

Android 14 uses more signals from apps to determine the ranking of the direct share targets to provide more helpful results for the user. To provide the most useful signal for ranking, follow the guidance for improving rankings of your Direct Share targets. Communication apps can also report shortcut usage for outgoing and incoming messages.

Direct Share row in the sharesheet, as shown by 1

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

Video: Predictive back animations

Android 13 introduced the predictive back-to-home animation behind a developer option. When used in a supported app with the developer option enabled, swiping back shows an animation indicating that the back gesture exits the app back to the home screen.

Android 14 includes multiple improvements and new guidance for Predictive Back:

With this Android 14 preview release, all features of Predictive Back remain behind a developer option. See the developer guide to migrate your app to predictive back, as well as the developer guide to creating custom in-app transitions.

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

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

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

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

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

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

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

アプリの画面共有

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

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

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

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

On Pixel 8 Pro devices with the December Feature Drop, developers can try out higher-quality smart replies in Gboard powered by on-device Large Language Models (LLMs) running on Google Tensor.

This feature is available as a limited preview for US English in WhatsApp, Line, and KakaoTalk. It requires using a Pixel 8 Pro device with Gboard as your keyboard.

To try it out, first enable the feature in Settings > Developer Options > AiCore Settings > Enable Aicore Persistent.

Next, open a conversation in a supported app to see LLM-powered Smart Reply in Gboard's suggestion strip in response to incoming messages.

Gboard utilizes on-device LLMs to provide higher-quality smart replies.

グラフィック

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

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