Android 14 では、デベロッパー向けに優れた新しい機能と API が導入されました。下記のセクションで、アプリ向けの機能について確認し、関連する API を使ってみることができます。
新しい API、変更された API、削除された API の一覧については、API 差分レポートをご覧ください。新しい API について詳しくは、Android API リファレンスをご覧ください。新しい 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
を登録して、地域の設定が変更されたときに言語 / 地域の構成の変更を処理することも可能です。
これらの設定を確認するには、設定アプリを開いて [システム] > [言語と入力] > [地域の設定] に移動します。


Android システム設定の地域の設定画面
Android システム設定の地域の設定に関する温度オプション
ユーザー補助
非線形フォント スケーリングを 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
を使用して方程式をハードコードしないでください。フォントのスケーリングが非線形になったため、これらのフィールドは正確ではなくなっています。
ユーザー エクスペリエンス
共有シートのカスタム アクションとランキングの改善
Android 14 では、システム共有シートが更新され、カスタムのアプリ アクションと有益なプレビュー結果をユーザーに提供できるようになりました。
カスタム アクションを追加する
Android 14 では、アプリで呼び出すシステム共有シートにカスタム アクションを追加できます。共有シートを使用してアクションをカスタマイズするには、ChooserAction.Builder
を使用してカスタム ChooserAction
を作成し、ChooserActions
のリストを Intent.createChooser
で作成された Intent
の Intent.EXTRA_CHOOSER_CUSTOM_ACTIONS
として指定します。

直接共有ターゲットのランキングを改善する
Android 14 では、アプリからの多数のシグナルを使用して、直接共有ターゲットのランキングを決定し、より有用な結果をユーザーに提供しています。ランク付けに最も有用なシグナルを提供するには、ユーザーが連絡先にメッセージを送信したときに、対応するショートカットを指定して pushDynamicShortcut
を呼び出してショートカットの使用状況を報告し、ShortcutInfoCompat.Builder#addCapabilityBinding("actions.intent.SEND_MESSAGE")
を呼び出して対応する機能「actions.intent.SEND_MESSAGE」をそのショートカットにアタッチします。
アプリストアの改善
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 では、スクリーンショットの検出の標準化されたエクスペリエンスを実現するため、プライバシーを保護するスクリーンショット検出 API が導入されました。この API を使用すると、アプリはアクティビティごとにコールバックを登録できます。アクティビティが表示されている間にユーザーがスクリーンショットを撮ると、これらのコールバックが呼び出され、ユーザーに通知されます。
グラフィック
パスのクエリと補間に対応
Android の Path
API は、ベクター グラフィックを作成してレンダリングするための強力かつ柔軟なメカニズムです。パスのストロークや塗りつぶし、線分、二次曲線、または三次曲線からのパスの作成、ブール演算の実行による複雑な図形の取得が可能で、これらをすべて同時に実行することもできます。ただし、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 を使用できます。
コア機能
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 およびその関連会社の商標または登録商標です。