この記事は エンジニアリング部門副社長、Dave Burke による Android Developers Blog の記事 " The first developer preview of Android 14 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android を数十億人に上る Android ユーザーの一人ひとりに適した動作にすることは、私たちと Android ハードウェア メーカー、そしてデベロッパー コミュニティの皆さんとの共同作業です。
Android は、年間を通して機能強化と新機能を提供し続けます。Android の継続的改善においては、Android 14 デベロッパー プレビューと Quarterly Platform Release (QPR) ベータ版プログラムのフィードバックが重要な役割を果たします。Android 14 デベロッパー サイト (英語) には、Pixel にダウンロードする方法やリリース スケジュールなど、プレビュー版に関する多くの情報が掲載されています。皆さんの感想を聞くのを楽しみにしています。そして、Android を誰もが使えるプラットフォームにするために、引き続き協力をお願いいたします。
Android 14 は、タブレットや折りたたみ式のフォーム ファクタに対応するために Android 12L と 13 で行った作業を土台として開発されています。さまざまな画面サイズに対応したアプリを開発できるように、ウィンドウ サイズクラス、SlidingPaneLayout、アクティビティの埋め込み、制約付きボックス (英語) などの機能を作成しました。これらの機能は、すべて Jetpack Compose でサポートされています。毎回のリリースの目的は、アプリをあらゆる Android に最適化する作業を簡単にすることです。
アプリを効率的に準備できるように、大画面向けのアプリ品質ガイドを更新し、大画面や折りたたみ式端末向けの開発についてさらに詳しく学習できるように準備しました。大画面ギャラリーでは、実績のあるデザイン パターンや、ソーシャル&コミュニケーション、メディア、仕事効率化、ショッピング、読書など、アプリがサポートするマーケットでのデザイン アイデアを紹介しています。
マルチデバイス エクスペリエンス (英語) は、Android の重要な機能です。クロスデバイス SDK (英語) のプレビュー版を使うと、さまざまな種類のデバイスやフォーム ファクタで直感的に利用できる高度な操作を今日からさっそく実現できます。今後もさらに多くの機能が利用できるようになる予定です。
Android 14 では、さまざまなアプリが同時に動作する方法を最適化し、システムの健全性やバッテリー駆動時間を向上させ、エンドユーザー エクスペリエンスを洗練する作業を続けています。
WiFi が利用できるときに大きなファイルをダウンロードする場合など、一部のバックグラウンド動作は必要以上に複雑になっています。アプリ開発をシンプルにし、ユーザー エクスペリエンスの向上につなげるため、この動作を標準パスで実現できるように作業しています。また、フォアグラウンド サービスの使用方法を厳格化するとともに、特に優先度が高いユーザー向けタスクのみに限定することで、Android のリソース消費とバッテリー駆動時間を改善します。
Android 14 では、既存の Android API (フォアグラウンド サービス (英語) と JobScheduler (英語))を変更し、ユーザーが開始するデータ転送 (英語) の新機能などを追加しています。また、フォアグラウンド サービスのタイプ (英語) の宣言要件を更新します。ユーザーが開始するデータ転送 (英語) ジョブを使うことで、ユーザーが開始するダウンロードやアップロードを簡単に管理できるようになります。Wi-Fi のみでダウンロードするといった制約が必要な場合は、特に便利です。フォアグラウンド サービスのタイプ (英語) の宣言要件により、アプリのバックグラウンド動作の意図をはっきりと定義でき、フォアグラウンド サービスに適したユースケースも明確になります。さらに、こういった API が適切に利用されるようにするため、Google Play にも新しいポリシーを導入する予定です。詳細は近日中にお伝えします。
内部ブロードキャスト システムにいくつかの最適化を適用し、バッテリー駆動時間と応答の速さを改善しています。ほとんどの最適化は Android の内部処理に関連することなので、アプリへの影響はありません。ただし、アプリがキャッシュに保存された状態で、コンテキスト登録されたブロードキャストを受け取る場合は調整しています。コンテキスト登録されたレシーバーへのブロードキャストは、キューに格納され、キャッシュに保存された状態から抜けたときにアプリに配信される場合があります。さらに、BATTERY_CHANGED (英語) のように、コンテキスト登録されたブロードキャストが繰り返される場合は、アプリがキャッシュに保存された状態から抜けたときに、最後の 1 つのブロードキャストに統合されてから配信されることがあります。
正確なアラームは、バッテリー駆動時間などのデバイスのリソースに重大な影響を与える可能性があります。そこで Android 14 では、Android 13 以降 (SDK 33 以降) をターゲットとした時計やカレンダー以外のアプリが新規インストールされた場合、ユーザーに SCHEDULE_EXACT_ALARM (英語) という特別な権限をリクエストしてからでないと、正確なアラーム設定 (英語) ができなくなります。インテントを使ってアプリから設定ページを開き、この権限を切り替えてもらうこともできますが、ユースケースを評価し、可能であれば柔軟にスケジュール設定できる別の方法 (英語) を使うことをおすすめします。
Android 13 以降 (SDK 33 以降) をターゲットとした時計やカレンダーのアプリが、中核となるワークフローで正確なアラームを使う場合は、標準の権限である USE_EXACT_ALARM (英語) を宣言できます (インストール時に付与されます)。マニフェストでこの権限が宣言されたバージョンのアプリは、ポリシーの文言に基づいて適格性が認められない限り、Google Play ストアに公開できません。
ユーザー補助の強化や国際化機能など、Android ユーザーが個々のニーズに合わせて動作をチューニングできるようにする作業を継続しています。
Android 14 より、フォントを 200% まで拡大できるようになります。これまで、Pixel デバイスの最大フォントサイズは 130% でした。
テキストが大きくなりすぎる問題を緩和するため、Android 14 以降では、ノンリニアなフォント拡大曲線が自動的に適用されます。これにより、すでに十分大きくなっているテキストは、小さなテキストと同じ比率で拡大されなくなります。
Android 14 では、[Accessibility] > [Display size and text] 設定にある [Font size] オプションで最大フォントサイズを設定してアプリの UI をテストしてください。調整した大きなテキストサイズの設定が UI に反映し、テキストが切れていないことを確認してください。その他のベスト プラクティスはドキュメント (英語) で説明しています。
LocaleManager.setOverrideLocaleConfig (英語) でアプリの localeConfig を動的に更新すると、Android の設定でアプリ別の言語リストに表示される言語セットをカスタマイズできます。これにより、地域別に言語リストをカスタマイズしたり、A/B テストを実施したり、サーバーサイドからローカライズされたプッシュ通知を送るために最新の言語 / 地域を提供したりできます。
IME は LocaleManager.getApplicationLocales (英語) を使って現在のアプリの UI 言語を確認できるので、キーボードの言語を更新できます。
Grammatical Infection API (英語) を使うと、文法的性のある言語の話者に対応しやすくなります。次に例を示します。
男性形 : “Vous êtes abonné à...”
女性形 : “Vous êtes abonnée à…”
中性形 : “Abonnement à…activé”
文法的性は言語に固有で、英語以外の一部の言語で簡単に言い換えられない場合があります。この新しい API を使うと、文字列単位で適用しなければならない ICU の SelectFormat よりも少ない作業量で利用者の性別 (話の対象ではなく、UI を見ている人) に対応できます。
対象言語で両方の文法的性で語形変化した翻訳を追加し、この API を組み込むだけで、パーソナライズした翻訳を表示できます。
Android 14 をターゲットとするアプリで動的に Context.registerReceiver() (英語) を使う場合、それを「exported」として扱うか「unexported」として扱うかを指定する必要があります。これは、以前のリリースから継続して行っているマニフェストレベルの作業の一環です。詳細についてはこちら (英語) を参照してください。
悪意のあるアプリによってインテントが盗聴されるのを防ぐため、Android 14 をターゲットとするアプリでは、パッケージを指定しないインテントを内部的に送信する操作が制限されます。詳細についてはこちら (英語) を参照してください。
動的コード読み込み (DCL) は、マルウェアやエクスプロイトの侵入経路になります。動的にダウンロードされた実行ファイルが意図せずに改ざんされ、コード インジェクションが発生する可能性があるからです。Android 14 をターゲットとするアプリで動的読み込みを行うには、ファイルを読み取り専用にする必要があります。詳細についてはこちら (英語) を参照してください。
多くのマルウェアは、新しいバージョンの Android に導入されたセキュリティやプライバシーの保護を回避しようとして、古い API レベルを狙います。これを防ぐため、Android 14 以降では targetSdkVersion が 23 未満のアプリをインストールできなくなります。このバージョンが選ばれた理由は、targetSdkVersion 22 を使って 2015 年に Android 6.0(API レベル 23)で導入されたランタイム権限モデルを回避するマルウェア アプリがあるからです。
targetSdkVersion が 23 未満のアプリがインストールされているデバイスを Android 14 にアップグレードした場合、アプリはインストールされたままになります。
古い API レベルをターゲットにしたアプリをテストする場合は、次の ADB コマンドを利用できます。
adb install --bypass-low-target-sdk-block FILENAME.apk
先日、新しい Jetpack API である Credential Manager (英語) のアルファ版リリースについてお知らせしました。これを使うと、ユーザーの認証操作をシンプルにしつつ、パスキーをサポートしてセキュリティを強化できます。パスキーはフィッシングによって侵害される可能性があるパスワードなどの認証要素に代わるもので、安全性を大幅に向上することができるうえ、ユーザーの利便性も向上します (生体認証とスワイプだけで、どのデバイスでも安全にログインできます)。詳細についてはこちら (英語) を参照してください。
毎回のプラットフォーム リリースでは、アプリの互換性を優先することで、高速でスムーズなアップデートを実現できるように努力しています。Android 14 では、アプリに関連する変更のほとんどをオプトインできるようにすることで、十分に時間を取ってアプリに必要な変更を追加できるようにしています。また、対応に必要な時間を減らすために、ツールやプロセスもアップデートしています。
OpenJDK 17 サポート - 今回のプレビューで、300 個の OpenJDK 17 クラスにアクセスできるようになります。今後のデベロッパー プレビューで Java 17 の言語機能をフル活用できるようにするため、懸命な作業を続けています。これには、レコードクラス、複数行文字列、instanceof のパターンマッチングなどが含まれます。Google Play システム アップデート (Project Mainline / 英語) のおかげで、6 億台以上のデバイスがこの変更を含む最新の Android ランタイム (ART) アップデートを受け取れるようになっています。これは、アプリの一貫性を向上させ、さまざまなデバイスの環境を安全にし、プラットフォーム リリースとは別に新機能を提供できるようにする作業の一環です。
変更点のテストやデバッグの簡易化 - アプリに影響を与える可能性がある変更点を簡単にオプトインしてテストできるように、今年も多くの変更点をトグルスイッチにより切り替え可能にしていきます。この切り替えを利用すると、それぞれの変更を開発者向けオプションや adb から強制的に有効化、無効化できます。詳細はこちら (英語) をご覧ください。
Platform Stability マイルストーン - アプリの互換性作業を計画する時間を長くとれるように、昨年と同様にかなり早いタイミングで Platform Stability マイルストーンをお知らせします。このマイルストーンでは、最終版の SDK や NDK API、内部 API やアプリに関連するシステム動作の最終版を配信します。2023 年 6 月に Platform Stability に到達することを想定しています。その後、数週間の最終テストの期間を経て、公式リリースを迎える予定です。詳しいリリース スケジュールはこちら (英語) をご覧ください。
Android 14 の利用を開始する
デベロッパー プレビューには、Android 14 の機能を試し、アプリをテストしてフィードバック (英語) を提供するために必要なすべてのものが含まれています。タブレットや折りたたみ式でアプリのテストを始める一番簡単な方法は、Android Studio SDK Manager (英語) の最新プレビュー版で、タブレットまたは折りたたみ式設定の Android Emulator を使うことです。スマートフォンの場合は、システム イメージ (英語) を Pixel 7 Pro、Pixel 7、Pixel 6a、Pixel 6 Pro、Pixel 6、Pixel 5a 5G、Pixel 5、Pixel 4a (5G) のいずれかのデバイスに書き込むと、すぐに始めることができます。Pixel デバイスをお持ちでない方は、Android Studio で 64 ビット システム イメージと Android Emulator を使うことができます。
Android 14 に向けてより良い開発体験をするには、Android Studio Giraffe (英語) (または Giraffe 以降の最新版) の最新プレビュー版を使うことをおすすめします。セットアップ (英語) の完了後にやるべきことは、以下のとおりです。
新機能や新 API を試す - 早い段階のデベロッパー プレビューでは、皆さんからのフィードバックが不可欠です。問題は、フィードバック ページ (英語) のトラッカーで報告してください。
現在のアプリの互換性をテストする - アプリが Android 14 のデフォルト動作の変更による影響を受けるかどうかを確認し、Android 14 を実行しているデバイスやエミュレータにアプリをインストールして幅広くテストします。
変更をオプトインしてアプリをテストする - Android 14 では、動作の変更点はターゲットに新しいプラットフォームを指定した場合にのみアプリに影響するようになっており、それをオプトインすることができます。変更点を早めに把握し、評価することが重要です。簡単にテストできるように、変更点のオン、オフを個々に切り替え (英語) られるようになっています。
プレビュー システム イメージと SDK は、Android 14 のリリース サイクル期間を通じて定期的にアップデートされる予定です。このプレビューの第 1 弾リリースは、デベロッパーのみを対象としています。日常的な使用やユーザーの使用を想定したものではありません。そのため、手動のダウンロードのみで入手できます。プレビュー ビルドを手動でインストールすると、今後のプレビューやベータ版の無線 (OTA) アップデートをすべて自動的に受け取ります。詳細についてはこちら (英語) を参照してください。
デバイスをワイプせずに Android 13 QPR ベータ版プログラムから Android 14 デベロッパー プレビュー プログラムに移行したい場合は、今のうちにデベロッパー プレビュー 1 に移行することをおすすめします。移行しない場合、Android 13 ベータ版のビルド日付が新しくなった場合に、データをワイプせずに Android 14 デベロッパー プレビューに直接移行できなくなる時間帯が発生する可能性があります。
ベータ版リリースに近づいたら、ユーザーも招待して Android 14 を試していただく予定です。その際には、Android ベータ版プログラムへの登録もオープンします。現在のところ、Android 14 のベータ版プログラムはまだ利用できない点に注意してください。
詳細な情報については、Android 14 デベロッパー サイト (英語) でご覧いただけます。
Java および OpenJDK は Oracle および /またはその関連会社の商標または登録商標です。
この記事は Gurupreet Singh, Developer Advocate; Android による Android Developers Blog の記事 " Material Design 3 for Compose hits stable " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年 2022 年 10 月 24 日に、Compose マテリアル 3 (英語) の最初の安定版がリリースされました、このライブラリを使うと、マテリアル デザインの次の進化版であるマテリアル デザイン 3 (英語) を使って Jetpack Compose の UI を構築できます。マテリアル デザイン 3 は、皆さんのアプリに利用できます。
注 : 「マテリアル デザイン 3」、「マテリアル 3」、「M3」という用語はどれも同じものを指しています。
マテリアル 3 には、アップデートされたテーマ設定やコンポーネントのほか、ダイナミック カラーなどの新機能が含まれており、最新の Android のビジュアル スタイルやシステム UI との整合性が取れるようにデザインされています。
build.gradle ファイルに Compose Material 3 への依存関係を追加すると、アプリでマテリアル デザイン 3 を使い始めることができます。
// モジュールの build.gradle に依存関係を追加implementation "androidx.compose.material3:material3:$material3_version"
// モジュールの build.gradle に依存関係を追加
implementation "androidx.compose.material3:material3:$material3_version"
// ダイナミック カラーは Android 12 以降で利用可能val dynamicColor = Build.VERSION.SDK_INT >= Build.VERSION_CODES.Sval colorScheme = when { dynamicColor && darkTheme -> dynamicDarkColorScheme(LocalContext.current) dynamicColor && !darkTheme -> dynamicLightColorScheme(LocalContext.current) darkTheme -> darkColorScheme(...) else -> lightColorScheme(...)}MaterialTheme( colorScheme = colorScheme, typography = typography, shapes = shapes) { // M3 App のコンテンツ}
Switch( checked = isChecked, onCheckedChange = { /*...*/ }, thumbContent = { Icon( imageVector = Icons.Default.Check, contentDescription = stringResource(id = R.string.switch_check) ) }, )
ModalNavigationDrawer { ModalDrawerSheet( drawerShape = MaterialTheme.shapes.small, drawerContainerColor = MaterialTheme.colorScheme.primaryContainer, drawerContentColor = MaterialTheme.colorScheme.onPrimaryContainer, drawerTonalElevation = 4.dp, ) { DESTINATIONS.forEach { destination -> NavigationDrawerItem( selected = selectedDestination == destination.route, onClick = { ... }, icon = { ... }, label = { ... } ) } }}
CenterAlignedTopAppBar( title = { Text(stringResources(R.string.top_stories)) }, scrollBehavior = scrollBehavior, navigationIcon = { /* ナビゲーション アイコン */}, actions = { /* アプリバーのアクション */} )
val typography = Typography( titleLarge = TextStyle( fontWeight = FontWeight.SemiBold, fontSize = 22.sp, lineHeight = 28.sp, letterSpacing = 0.sp ), titleMedium = TextStyle( fontWeight = FontWeight.SemiBold, fontSize = 16.sp, lineHeight = 24.sp, letterSpacing = 0.15.sp ), ...}
bodyLarge = TextStyle( fontWeight = FontWeight.Normal, fontFamily = FontFamily.SansSerif, fontStyle = FontStyle.Italic, fontSize = 16.sp, lineHeight = 24.sp, letterSpacing = 0.15.sp, baselineShift = BaselineShift.Subscript)
val shapes = Shapes( extraSmall = RoundedCornerShape(4.dp), small = RoundedCornerShape(8.dp), medium = RoundedCornerShape(12.dp), large = RoundedCornerShape(16.dp), extraLarge = RoundedCornerShape(28.dp))
// モジュールの build.gradle に依存関係を追加implementation "androidx.compose.material3:material3-window-size-class:$material3_version"
Scaffold( contentWindowInsets = WindowInsets(16.dp)) { // Scaffold のコンテンツ}
この記事は Sara Hamilton による Android Developers Blog の記事 " Leading Health and Fitness Apps Roll Out Health Connect Integrations " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリ デベロッパーの皆さんは、昨年導入されたヘルスコネクト (英語) を使って、健康とフィットネスのデータを共有するプラットフォームに早期アクセスできます。このプラットフォームは、ユーザーの同意のもと、Android デバイスをまたいでデータを安全に共有するもので、Samsung と連携して開発しています。この仕組みにより、アプリ間の接続がシンプルになり、ユーザーは一元的にプライバシーを管理できるようになります。今回、プライバシー設定を集中的に管理する場所として、ヘルスコネクト(ベータ版)アプリを Google Play でダウンロードできるようにしています。細かい制御によってどのアプリがどの時点でデータにアクセスするかを確認できます。
2022 年 11 月 14 日以降、10 以上の健康、フィットネス、ウェルネス関係のアプリで、このプラットフォームとの連携機能が公開されています。これらのアプリには、ヘルスコネクトの先行ユーザーである MyFitnessPal、Oura、Peloton も含まれています。
この連携機能の第 1 弾を通して、ヘルスコネクトがデベロッパーに多くの重要なメリットをもたらしていることがわかっています。
健康とフィットネスのアプリ同士が相互に連携できるようになることで、それぞれのアプリが質の良い総合的な健康情報をユーザーに提供できるようになります。
これまでは、複数の API 接続を駆使しなければ別のアプリとデータを共有できなかったため、連携機能の開発やメンテナンスには費用がかかっていました。それがデベロッパーのデータ共有能力の足かせになっていたため、ユーザーが別のアプリでデータを活用するのは困難でした。
ヘルスコネクトを使うと、新しいアプリとの連携機能はヘルスコネクトから新しいデータを読み取るだけで簡単に開発できます。新たな連携機能を開発する必要はありません。
たとえば、Android ユーザーは、Oura、MyFitnessPal、WeightWatchers、Lifesum といったアプリで Peloton ワークアウトを同期したりその実績を反映したりできるようになります。ヘルスコネクトとの連携機能が 1 つあるだけで、Peloton メンバーはワークアウトの統計情報を健康サポートアプリのエコシステム全体に共有できるようになります。
ヘルスコネクトには標準データスキーマがあり、6 つのカテゴリで 40 種類以上のデータがサポートされています。スキーマは直感的に利用でき、エクササイズ、睡眠管理、バイタルサインなどのさまざまなユースケースに対応しています。ヘルスコネクトに格納されているものであれば、どんな種類のデータでも数行のコードだけで読み書きできます。さらに、ヘルスコネクトは複雑な集計もサポートするので、アプリのユースケースに合わせて自由自在にクエリをカスタマイズできます。
「当社のエンジニアは、既存のアーキテクチャを簡単にヘルスコネクトの API に対応させ、栄養、水分補給、運動、歩数といったユーザーの健康データを読み書きすることができました。この連携機能があれば、ヘルスコネクトに書き込みを行うすべてのサードパーティ製アプリのデータも利用できるので、ユーザーの選択肢が広がります。同時に、細かな権限設定でどのデータを共有するかを選べるので、ユーザーの柔軟性も向上します」
– MyFitnessPal の最高技術責任者、Jason Peterson 氏
これまで、ユーザーは複数のアプリを開いてデータの権限を管理しなければなりませんでした。また、権限管理の UI はデベロッパーが自前で準備する必要がありました。
ヘルスコネクトを使うと、ユーザーは 1 か所で簡単に権限を管理でき、細かい制御によってどのアプリがどの時点でデータにアクセスしているかを確認できます。
デベロッパーにとって、ヘルスコネクトは権限管理ハブであり、すぐに設定して使える詳細な権限 UI です。
さまざまな種類のデータが示された詳細権限画面
たとえば、Signos はヘルスコネクトを使った権限チェックを簡単に設定できました。「うれしい驚きの 1 つは、ユーザーのオンボーディング UX でした」と Signos のデベロッパーである Jake Smith 氏は話します。「簡単に挿入できるコードで権限を設定できるので、ユーザーにもメリットがあります」
多くのデベロッパーがすでにヘルスコネクトとの連携をしています。ユーザーに高度な情報を提供できるチャンスを見逃さないように、ぜひヘルスコネクトを導入してください。ドキュメント、便利な動画チュートリアル (動画/日本語字幕あり) 、コードサンプルを確認し、さっそく今日から開発を始めましょう!