この記事は Marwa Mabrouk による Android Developers Blog の記事 " The exciting aspects of Android Camera" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Camera はエキサイティングな領域です。カメラは、消費者がスマートフォンを購入する理由の上位に挙がる要因です。また、Android Camera は、さまざまなツールを通じて、デベロッパーの可能性を広げています。Camera 2（英語） は、Android 5.0 Lollipop 以降の Android に含まれるフレームワーク API です。CameraX は Camera 2 を活用して動作する Jetpack サポート ライブラリであり、すべての Android デベロッパーが利用できます。この 2 つのソリューションは、お互いに機能を補完し合うことで、Android Camera エコシステムのニーズを満たすことができるように作られています。
Android Camera を始めたい方、アプリを最新に更新したい方、または Camera 1 からアプリを移行している方にとって、最初に使ってみるべきツールは CameraX です。CameraX が提供する主なメリットは、デベロッパーのできることを増やし、複雑なエコシステムに対処できることです。
カメラで非常に特殊な機能を開発するために撮影フローを低レベルで制御しなければならない方や、デバイスの違いを考慮に入れなければならない方は、Camera 2（英語） を利用してください。
Camera 2 は、すべての Android デバイスでカメラのハードウェアを利用できるようにする共通 API で、現在世界中の市場に出回っている数十億台の Android デバイスすべてに組み込まれています。Camera 2 はフレームワーク API なので、デベロッパーは写真やデバイス実装に関する深い知識を活用できます。Camera 2 の質を確かなものにするため、デバイス メーカーは自社のデバイスをテストし、基準に準拠していることを示します。この API には、デバイス メーカーの選択に応じて、デバイスの違いが現れます。この違いを活用することにより、自社の判断で特定のデバイスにカスタム機能を導入できます。
さらに詳しく理解するため、例を挙げて説明しましょう。ここでは、カメラの撮影機能について比較します。Camera 2 では、スマートフォンの各カメラの撮影パイプラインで、特殊な制御を同時に行えるようになっています。さらに、非常に細かい手動設定もできます。CameraX では、高解像度、高画質の写真撮影ができるほか、自動ホワイトバランス、自動露出、自動フォーカス機能が提供され、シンプルな方法でカメラを手動制御することもできます。
応用例を考えてみましょう。Samsung は、Samsung Galaxy デバイスで Camera Framework API を使い、高度なプロレベルのカメラシステムを通じて、さまざまなライティングや設定を利用してスタジオ品質の写真を撮影できるようにしています。API は共通ですが、Samsung はそれぞれのカメラアプリで、各デバイスの独自の能力の違いを活用することができました。Camera Framework API のおかげで、Samsung は低レベルのカメラ機能にアクセスでき、デバイスに合わせてネイティブ アプリをカスタマイズできます。
もう 1 つ例を挙げましょう。Microsoft は、Microsoft Lens が使われているすべての仕事効率化アプリ（Office、Outlook、OneDrive など）で高画質イメージを扱えるように、CameraX を組み込むことにしました。Microsoft Lens チームは、CameraX に切り替えたことで、API がシンプルになってデベロッパー エクスペリエンスを向上できただけでなく、アプリのパフォーマンスとデベロッパーの生産性も上がり、市場投入までの時間も短縮できました。この事例については、こちら（英語）で詳しく紹介しています。
両方の API に多くの新機能が追加されている今、Android Camera は躍動の時期を迎えています。
今後も、Android Camera に追加する予定の魅力的な機能について、詳しくお知らせしたいと思っています。皆さんとともに作業を進め、CameraX メーリング リスト camerax-developers@android.com や AOSP Issue Tracker を通してフィードバックをいただけることを楽しみにしています。
Android Camera に継続的に関心を寄せていただき、ありがとうございます。皆さんと共同で、ユーザーのためにすばらしいカメラ体験を作成できることが楽しみです。
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は Greg Hartrell による Android Developers Blog の記事 " Things to know from the 2022 Google for Games Developer Summit " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちはこの数年間、アプリやゲームは単なるエクスペリエンスではなく、皆さんのような才能のある人々が主導するビジネスであることを実感しています。そのため、私たちの目的は、皆さんがさらなる高みへ到達できるように、ビジネスを支え続けることです。Google のさまざまなチームは高品質なエクスペリエンスから収益化できるように次世代のサービス、ツール、機能を作ったり、皆さんのニーズに合ったプログラムやベスト プラクティスが記載された教育リソースなどの作成を続けています。先日開催された Google for Games Developer Summit では、その内容についてお知らせしました。基調講演、各セッション動画はこちら (英語) から日本語字幕付きでご覧いただけます。
私たちは、高品質なゲームを簡単に開発できるようにし、すばらしいエクスペリエンスをますます多くのユーザーやデバイスに提供できるようにすることで、ゲーム開発ライフサイクル全体にわたって皆さんをサポートしたいと考えています。
私たちは、ゲームを新しい画面やデバイスに対応させて、プレーヤーがどこにいてもゲームをプレイできるようにしたいと考えています。
私たちは、高品質な Android ゲームの開発をサポートすることに尽力しています。自前のネイティブ C/C++ エンジンを含むゲームエンジンとも連携しつつ、開発を簡単にするツールや SDK への注力、ゲームについての知見の提供を続けています。昨年は、Android ゲーム開発の効率を上げるために役立つツールとライブラリを集めた Android Game Development Kit（AGDK）をリリースし、デベロッパーの皆さんからのフィードバックに基づいて継続的なアップデートも行いました。 注: 以下、リンク全て英語。
Google Play Console は、ゲームのライフサイクルに役立つ貴重なリソースで、リリースの前後に利用できるさまざまなツールや知見が提供されます。
Google for Games Developer Summit (英語) でお知らせしたすべての内容を知りたい方は、g.co/android/games からその他のリソースやドキュメントをご覧ください。私たちは今後も、デベロッパー エコシステムをサポートすることに尽力します。皆さんからの恒常的なフィードバックと、世界中のプレーヤーのために高品質なゲーム エクスペリエンスを作成しようとする取り組みに深く感謝します。
この記事は Arjun Dayal による Android Developers Blog の記事 " Google Play Games beta launches on PC in Korea, Taiwan, and Hong Kong" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
12 月に、Google Play Games が PC に対応することをお知らせしました。プロダクトとサービスの連携を強化するという幅広い目標の一環として、Google Play Games では、プレーヤーがどこにいても、できる限り多くのデバイスでゲームを楽しんでもらえるように取り組みを続けています。2022 年 1 月 20 日、韓国、台湾、香港でGoogle Play Games のベータ版への登録 (注: 現時点で日本は対象外) を開始したことをお知らせします。
ベータ版に参加するユーザーは、Windows PC で Google が開発したスタンドアロン アプリケーションを使って対象の Google Play ゲームをプレイできます。世界で特に人気が高いいくつかのモバイルゲームも、開始と同時に利用できるようになります。たとえば、「モバイル·レジェンド: Bang Bang」、「サマナーズウォー」、「State of Survival: The Joker Collaboration」、「Three Kingdoms Tactics」などです。毎月数億人のプレーヤーが、世界中でこういったゲームを楽しんでいます。
今回の対応で、Google Play の最高のゲームを楽しめるノートパソコンやデスクトップ パソコンが増え、スマートフォン、タブレット、Chromebook、そして Windows PC でシームレスにゲームのセッションに没入できるようになります。プレーヤーは、お気に入りのモバイルゲームを PC で簡単にブラウジング、ダウンロード、プレイできるだけでなく、大画面、マウスやキーボードによる入力といったメリットも活用できます。Google Play Games のユーザプロファイルと連動するので、デバイスを切り替えて進捗や実績が失われることがなくなります。また、Google Play Points は、PC での Google Play Games のアクティビティにも付与されます。
プラットフォームを拡張し、プレーヤーの皆さんがお気に入りの Android ゲームをさらに楽しめるようにできるのは、私たちにとって最大の喜びです。g.co/googleplaygames から登録すると、今後のお知らせを受け取ったり、韓国、台湾、香港ではベータ版にアクセス頂くことができます。 (注: 現時点で日本は対象外) Google Play Games について詳しく知りたい Android デベロッパーの皆さんは、デベロッパー サイトから申請をお願いします。今後のベータ版のリリースや利用可能地域については、近日中にお知らせします。
Windows は、Microsoft のグループ会社による商標です。
ゲームのタイトルは、地域によって異なる場合があります。
この記事は Android Team による Android Developers Blog の記事 " Helping Users Discover Quality Apps on Large Screens " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
大画面デバイスの普及が進んでおり、現在アクティブな Android タブレット、折りたたみ式デバイス、ChromeOS デバイスの数は、2 億 5,000 万台を超えています。需要が加速し続ける中で、ユーザーはソーシャルやゲーム、マルチタスクや仕事に至るまで、さまざまなことを大画面で行うようになっています。そこで私たちは、大画面デバイスを最大限に活用してもらうため、Google Play を大きく変更して、ユーザーが高品質なアプリやゲームを探して活用できるようにしたいと考えています。
Google Play ストアは、主に 3 つのアップデートをします。その 3 つとは、ランキングとプロモーションの変更、低品質のアプリへのアラート、デバイス固有の評価とレビューです。
先日、大画面で優れたユーザー エクスペリエンスを作成するためのガイドとして、アプリの中核品質ガイドラインに加えて、大画面アプリ品質ガイドライン (英語) を公開しました。このガイドでは、縦向きと横向きのサポートといった基本的な互換性要件から、キーボードやタッチペンの機能といった細かな差別化要件まで、幅広い機能を網羅しています。今後数か月の間に、大画面デバイスにおける Google Play ストアのおすすめやランキングのロジックを更新し、アプリの品質ガイドラインに基づいて、高品質なアプリやゲームを優先するようにします。具体的には、ユーザーが自分のデバイス向けに最適化されたアプリを見つけやすくなるように、検索結果でのアプリの表示順やホームページでのおすすめを変更します。また、Google Play ストア内の記事コンテンツについても、大画面に最適化されたアプリを紹介できるように、力を入れていく予定です。
基本的な互換性要件 (英語) を満たさないアプリに対しては、インストール後のアプリがどのような画面や機能か想定できるように、現在大画面ユーザーに表示されているアラートを更新します。これによってアプリが大画面デバイスではうまく動作しない可能性があることをユーザーに通知できます。この変更に関しては、改めて追加情報をお伝えしようと考えておりますので、今年の最新情報にご注目ください。
最後は以前お知らせした通り、ユーザーがデバイスタイプ（タブレット、折りたたみ式、Chrome OS、Wear、Auto など）ごとの評価とレビューを確認できるようになります。これにより、自分に合ったアプリはどれかを判断しやすくなります。ユーザーが使用するデバイスでのアプリのエクスペリエンスを把握しやすくなるように、可能な場合は、デフォルトでその種類のデバイスにおける評価が Google Play ストアに表示されます。Google Play Console でデバイスタイプごとの内訳を確認すると、デバイスごとの評価とレビューをプレビューできます。
デバイスタイプごとの内訳で評価とレビューを分析し、大画面向けの最適化を計画する
大画面向けの最適化をしているデベロッパーは、ユーザーのエンゲージメントや維持率が向上するというプラスな効果を感じています。ここでは、アプリを大画面向けに最適化するにあたってのヒントやリソースを紹介します。
[リーチとデバイス] のデバイスタイプのフィルタで、1 つまたは複数のデバイスタイプを選択して分析する
デバイスタイプの内訳で、ユーザーと問題の分布を確認し、現在のタイトルの最適化や次のタイトルの計画に役立てる
Google Play ストアの機能は、今後数か月間で徐々にロールアウトされます。変更が行われる前に大画面アプリの品質改善計画を立て、一歩先にスタートすることをおすすめします。今後も、大画面の最適化を最大限にサポートしてユーザー エクスペリエンスを改善できるように、フィードバックを集めて、優れたアプリを開発するデベロッパーの皆さんをサポートし続けたいと考えています。
この記事は Lidia Gaymond、Vicki Amin による Android Developers Blog の記事 " Freeing up 60% of storage for apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ユーザーがアプリをアンインストールする主な理由の 1 つが、容量を空けるためです。そこで、不要なアンインストールを防ぎ、ユーザーがデバイスでできることを増やすために、アプリをアーカイブできるようにする新機能の開発を始めています。
アーカイブとは、アプリを完全にアンインストールするのではなく、その一部を削除することで、ユーザーがアプリのストレージの最大 60% を一時的に取り戻せるようにする新機能です。アーカイブしたアプリはデバイスに残り、互換性のある最新バージョンを簡単に復元できます。ユーザーのデータは保持されます。
まもなく迎える Bundletool バージョン 1.10 のリリースは、すべてのデベロッパーが App Bundle を使ってアーカイブを利用できるようにするための第一歩になります。私たちは、Android Gradle プラグイン 7.3 でビルドしたアプリ用に、新しいタイプの APK である「アーカイブ APK」の生成を開始します。アーカイブ APK は、アプリが復元されるまでユーザーのデータを保持しておくための非常に小さな APK です。なお、今回私たちはアーカイブ APK の作成を開始しますが、今年後半にアーカイブ機能が一般向けにリリースされるまでは動作しません。
アーカイブ機能がリリースされると、ユーザーとデベロッパーの双方にとって、大きなメリットをもたらします。ユーザーは、アプリをアンインストールするのではなく、「アーカイブ」できるようになります。すると、一時的に容量を空けつつ、すばやく簡単にアプリを復元できます。デベロッパーには、アンインストール数が減り、お気に入りのアプリを取り戻してもらう際の手間が大幅に減るというメリットがあります。
これまでと同様に、生成されたすべての APK は、生成済み APK API や Google Play Console の App Bundle エクスプローラからダウンロードや調査できます。この機能はオープンソースなので、デベロッパーはコードを調べることができます。また、他のアプリストアもこの機能を利用できます。
アーカイブ APK の生成をオプトアウトしたい場合は、プロジェクトの build.gradle ファイルを次のように変更します。
android { bundle { storeArchive { enable = false } }}
android {
bundle {
storeArchive {
enable = false
}
または Gradle を使わずにアプリをビルドしている場合は、BundleConfig の新オプションを使ってオプトアウトできます。
{ "optimizations": { "storeArchive": { "enabled": false } }}
{
"optimizations": {
"storeArchive": {
"enabled": false
アプリのアーカイブに関する情報は今後も Android Developers Blog でお伝えしますので、ご注目ください。
この記事は Dave Burke による Android Developers Blog の記事 " Android 13 Developer Preview 2 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 3 月、2 億 5,000 万台以上の大画面 Android デバイスをさらに活用してもらうための 12L フィーチャー ドロップが、Android オープンソース プロジェクト（AOSP）にアップされました。そしてその直後、今回のリリースを迎えました。Android 13 やタブレット、Jetpack Compose でのデベロッパーの生産性向上の詳細については、#TheAndroidShow の最新エピソードをご覧ください。
デベロッパー プレビュー 2 の説明に入る前に、先ほどの話をしましょう。12L フィーチャー ドロップが正式に AOSP にリリースされ、今後数週間のうちにサポート対象のすべての Pixel デバイスにロールアウトされます。12L には、アプリをドラッグ＆ドロップしてすばやく分割画面モードに切り替えることができる新しいタスクバー、通知シェードとロック画面の新しい大画面レイアウト、アプリの互換性モードの改善などのアップデートが含まれ、タブレットでの Android 12 がさらに改善されています。詳細についてはこちら (英語) を参照してください。
12L は、年内行われるアップデートによって、Samsung、Lenovo、Microsoft のタブレットや折りたたみ式デバイスで利用できるようになる予定です。そのため、今のうちにアプリの準備も整えておくようにしましょう。さまざまなウィンドウ サイズの分割画面モードや異なる画面の向きでアプリをテストし、該当する場合は新しい互換性モードの変更点を確認することを強くおすすめします。デベロッパー向けの 12L の説明はこちら (英語) をご覧ください。
最も良いのは、12L の大画面機能が Android 13 の土台となっていることです。そのため、Android 12L を搭載したタブレットのベースもカバーできることを認識したうえで、Android 13 の開発やテストをすることができます。私たちは、大画面機能を Android の将来にとって重要な機能と位置付けています。そのため、皆さんがタブレットや Chromebook、折りたたみ式デバイスで優れたエクスペリエンスを構築するために必要になるツールを提供できるように、今後も注力を続けます。詳細については大画面向けの最適化を始める方法や大画面デベロッパー リソースをご覧ください。
それでは、今回の Android 13 デベロッパー プレビュー 2 の新機能の紹介に入りましょう。
ユーザーは、重要な個人情報や機密情報、リソースを安心してデバイスに預けることができる OS やアプリを求めています。プライバシーとユーザーの信頼は Android の製品理念の中核です。Android 13 では、すべての人に対して高品質で責任あるプラットフォームを構築することに引き続き重点を置いています。それを実現するため、デバイスでより安全な環境を実現し、ユーザーがより多くのことを制御できるようにします。デベロッパー プレビュー 2 の新機能は以下のとおりです。
通知権限 - ユーザーが最も重要な通知に集中できるようにするため、Android 13 にはアプリから通知を送信する新しい実行時の権限として、POST_NOTIFICATIONS (英語) が導入されます。Android 13 を対象とするアプリは、通知を送信する前に、ユーザーに対してこの通知権限をリクエストする必要があります。Android 12 以前を対象にするアプリでは、システムがアップグレード フローを処理します。このフローは、今後も微調整が続けられる予定です。ユーザーが自身でコントロールできる範囲を増やすため、できる限り早くアプリの対象を Android 13 に変更し、通知権限をリクエストすることをおすすめします。詳しくはこちら (英語)をご覧ください 。
Android 13 の通知権限 ダイアログ
デベロッパーがダウングレードできる権限 - アプリによっては、以前にユーザーが許可した特定の機能を有効にするための権限や、古い Android バージョンで取得した機密性の高い権限が不要になることがあるかもしれません。Android 13 では、以前に許可された実行時の権限をダウングレードしてユーザーのプライバシーを保護できるよう、新しい API (英語) を提供します。
コンテキスト登録されたレシーバの安全なエクスポート - Android 12 では、デベロッパーがマニフェストで宣言されたインテント レシーバをエクスポートするかどうか、明記することを義務付けました。Android 13 では、コンテキスト登録されたレシーバについても同様に求められます。つまり、システム以外のソースのレシーバを登録する際に、RECEIVER_EXPORTED (英語) フラグか RECEIVER_NOT_EXPORTED (英語) フラグを追加します。これにより、明示的に指定しない限り、他のアプリがレシーバを使ってブロードキャストを送信することはできなくなります。Android 13 では必須ではありませんが、アプリのセキュリティ強化の一環として、エクスポートするかどうかを宣言することをおすすめします。
Android 13 では、洗練されたエクスペリエンスと高いパフォーマンスをユーザーに提供していただけるよう、さらにツールを充実させる作業を続けています。ここでは、今回のリリースに含まれるアップデートの一部を紹介します。
日本語テキストの折り返しの改善 - TextView でテキストを文字ではなく、文節（自然に感じられる言葉の最小単位）やフレーズで折り返すことができるようになり、日本語のアプリで洗練性と読みやすさが向上します。TextView で android:lineBreakWordStyle="phrase" (英語) を指定すると、この折り返し設定を利用できます。
android:lineBreakWordStyle="phrase"
phrase スタイルを有効にして折り返した日本語テキスト（下）と、有効にしていない日本語テキスト（上）
非ラテン文字の行の高さの改善 - Android 13 では、非ラテン文字（タミル文字、ビルマ文字、テルグ文字、チベット文字など）の表示が改善され、各言語に応じた行の高さが利用されます。新しい行の高さになることで、文字が欠けることがなくなり、文字の位置も改善されます。この改善は、アプリの対象を Android 13 にするだけで反映されます。この変更は非ラテン言語の UI に影響する可能性があるため、新しい行間を使う場合は、必ずアプリのテストをするようにしてください。
Android 13 をターゲットにしたアプリでの非ラテン文字の行の高さの改善（下）
テキスト変換 API - 日本語や中国語などを話す人は、ふりがなで入力します。そのため、検索やオートコンプリートなどの機能をすばやく使用できないことがあります。Android 13 では、新しいテキスト変換 API (英語) を呼び出すことで、ユーザーが探しているものをすばやく簡単に見つけられるようになります。たとえば、日本語ユーザーが検索をする場合、これまでは（1）検索語句（場所やアプリ名など）の発音をひらがなで入力する（2）キーボードを使ってひらがなを漢字に変換する（3）漢字を使って再検索する（4）検索結果を取得する という手順を踏む必要がありました。新しいテキスト変換 API を使うと、日本語ユーザーがひらがなを直接入力するだけで、漢字の検索結果が直接表示され、手順 2 と 3 を省くことができます。
カラー ベクター フォント - Android 13 では、COLR バージョン 1（仕様 (英語) 、紹介動画 (英語) ）フォントのレンダリングがサポートされ、システムの絵文字が COLRv1 形式にアップデートされます。COLRv1 は、非常にコンパクトな新しいフォント形式で、サイズを問わず高速にくっきりと表示できます。システムがすべての処理をしてくれるので、ほとんどのアプリでは何もしなくても動作します。デベロッパー プレビュー 2 より、アプリで COLRv1 をオプトインできるようになります。アプリでシステム フォントを使って独自にテキストをレンダリングしている場合は、オプトインして絵文字のレンダリングをテストすることをおすすめします。COLRv1 の詳細は、Chrome でのお知らせ (英語) をご覧ください。
COLRv1 ベクター絵文字（左）とビットマップの絵文字
Bluetooth LE Audio - LE（低電力）Audio は、従来の Bluetooth に代わる次世代ワイヤレス オーディオで、新しい使用例や接続トポロジーを実現します。これにより、オーディオを共有して友だちや家族にブロードキャストしたり、情報や娯楽、ユーザー補助を目的として一般公開されているブロードキャストを登録したりできるようになります。また、電池寿命を犠牲にすることなく、非常に再現性の高いオーディオを受信し、従来の Bluetooth では不可能だったユースケース間でシームレスな切り替えができるように設計されています。Android 13 は LE Audio をビルトインでサポートするので、デベロッパーは互換デバイスで新機能を無料で利用できます。
MIDI 2.0 - Android 13 は、新しい MIDI 2.0 標準をサポートします。これには、USB 経由で MIDI 2.0 ハードウェアに接続する機能も含まれます。この最新の標準では、コントローラの分解能の増加、西洋以外のイントネーションのサポート強化、音符単位のコントローラによる演奏の表現力向上などの機能が提供されます。
新しいバージョンのプラットフォームをリリースするたびに、アプリの互換性を優先し、迅速かつスムーズにアップデートできるように作業をしています。皆さんが時間に余裕を持てるよう、Android 13 ではアプリに関連する変更がオプトイン方式になっています。また、短時間で対応できるように、ツールやプロセスをアップデートしています。
リリースに一歩近づいたデベロッパー プレビュー 2 では、全般的な安定性を改善する作業を続けています。そのため、新機能や変更点を試してフィードバックを送るには、今が絶好のタイミングです。特に、API に関するご意見や、プラットフォームの変更点がアプリに与える影響に関して詳しい情報をお待ちしています。フィードバック ページ (英語) にアクセスし、感想の共有または問題の報告をお願いします。
また、今は互換性テストをして必要な作業を洗い出し始めるべきタイミングでもあります。Android 13 ベータ版 1 までに互換性のあるアップデートをリリースできるように、早めにこの作業をすることをおすすめします。現時点では、アプリの targetSdkVersion を変更する必要はありませんが、開発者向けオプションの動作変更切り替えを使うことをおすすめします。Android 13 の変更点をオプトインすることで、アプリがどのような影響を受ける可能性があるかについての予備知識を得ることができます。
2022 年 7 月に プラットフォームの安定版に到達すると、アプリに関連するすべてのシステム動作、SDK/NDK API、非 SDK リストが確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリをリリースできます。デベロッパー向けのタイムラインの詳細はこちらをご覧ください。
開発者向けオプションでのアプリの互換性切り替え
デベロッパー プレビューには、Android 13 の機能を試し、アプリをテストしてフィードバック (英語) を提供するために必要なすべてのものが含まれています。Pixel 6 Pro、Pixel 6、Pixel 5a 5G、Pixel 5、Pixel 4a（5G）、Pixel 4a、Pixel 4 XL、Pixel 4 のいずれかにデバイス システム イメージを書き込むと、すぐに始めることができます。Pixel デバイスをお持ちでない方は、Android Studio Dolphin で 64 ビット システム イメージと Android Emulator を使うことができます。さらに幅広くテストできるように、GSI イメージも公開しています。すでにプレビュー ビルドを Pixel デバイスにインストールしている方は、今回のアップデートや、今後のプレビューやベータ版をすべて無線（OTA）で自動的に受け取ります。Android 13 を入手する方法はこちらをご覧ください。
その他、詳しい情報はAndroid 13 デベロッパー サイト (英語) でご覧いただけます。
この記事は Krish Vitaldevara による Android Developers Blog の記事 " Keeping Google Play safe with our key 2022 initiatives " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ユーザーとデベロッパーの皆さんのために、 Google Play の安全性を維持することは、私たちにとって、最優先事項です。ここ数年、デベロッパーの皆さんと連携して、アプリの安全性の確保に務めてきました。私たちは、デベロッパーの皆さんがアプリを保護(英語)し、データ セーフティ関連の情報をユーザーと共有する準備を整え、プライバシー保護をより優先する新しい広告ソリューションの提供などを実現させるサポートをしました。また、不正なコンテンツや悪意のあるコンテンツを含むアプリをインストール前に遮断 (英語) できるように、機械学習による検知や、アプリの審査の強化の取り組みも続けています。
また、私たちは、デベロッパーの皆さんが、この進化するプライバシーとセキュリティの状況の変化のペースについて行くことが大変だということも理解しています。Google Play Console の 受信トレイ メッセージやウェビナー、教育リソースの追加などの施策を通じて、より分かりやすいアップデート、変更に対応するための時間、そして有益な情報を提供できるよう努めております。このブログ記事で、2022 年に予定されていることを共有することで、皆さんが準備をするための充分な時間を用意できればと考えています。
デベロッパーの皆さんから、ご自身のアプリのデータの安全性について、わかりやすくシンプルな形でユーザーに説明したいと伺いました。そこで、アプリの Google Play ストア上の掲載情報には、データ セーフティ セクション が表示される予定です。このセクションでは、、デベロッパーの皆さんが、アプリがユーザーのデータをどのように収集、共有、保護するかを説明することができます。すでにユーザーからは、この情報に基づいて、アプリが自分に適したものであるかどうかを判断できるようになるというお声をいただいています。2022 年 4 月後半には、Google Play ストアにデータ セーフティ セクションの表示が開始される予定なので、お早めにデータ セーフティ フォームを送信してください。2022 年 7 月 20 日より、すべてのアプリで、アップデートの際にデータ セーフティ フォームの入力が必須になります。
先日、プライバシー サンドボックス (英語) の取り組みを Android に展開することをお知らせしました。私たちは、ユーザーのプライバシーを向上させる革新的なソリューションに取り組む一方で、デベロッパーの皆さんにとって、ビジネスを構築し、誰もが無料でアプリにアクセスできるようにするための重要なメカニズムをサポートするため、デベロッパーの皆さんと緊密に連携し、この取り組みを進めていきます。最新情報を受け取りたい方は、ニュースレター (英語) にご登録ください。
デベロッパーの皆さんがゲームやアプリを保護することをサポートするとともに、デベロッパーの皆さんが設計した通りの体験をユーザーが確実に得られるようにするために、新しい Play Integrity API (英語) の展開を開始しました。現在、デベロッパーの皆さん全員が、この新しい API にアクセスできるようになっており、疑わしいトラフィックを簡単に検知し、チートや不正行為などの問題にすばやく応答可能となりました。アップグレードに必要なビルド時間をほとんどかけずに、簡単に新機能を手に入れられるよう、将来を見据えた方法で構築しています。皆さんのアプリにこの機能を設定する方法は、こちらをご覧ください。
デベロッパーの皆さんより、SDK プロバイダからの重要なアップデート情報をより迅速に受け取りたいという声が寄せられています。そこで 2021 年、SDK プロバイダが Google Play Console で緊急の問題について通知 できる仕組みを導入しました。また、ビルド時間を無駄にしたり、ユーザーの安全性が損なわれたりすることがないように、SDK の安全性や信頼性について詳しく知りたいという声もありました。今後数か月のうちに、SDK の採用レベル、維持率、使われたランタイム権限の数などの情報を共有し、貴社ビジネスやユーザーに適した SDK を選択できるようにサポートする予定です。
2021 年は、広告と子供向けアプリに関する大人の事前承認の要件を見直す作業を続け、子どものプライバシーや安全性をさらに強化しました。対象となるデベロッパーは、近日中に追加されるデータ セーフティ セクションにバッジを追加して、ファミリー ポリシーへの準拠を宣言していることを明示できます。2022 年も引き続き、子どもの安全やプライバシー保護のためのポリシーを更新していく予定です。最新情報は、ポリシー関連のウェビナーや PolicyBytes でご確認ください。
デベロッパーの皆さんは、アプリの機能や改善に必要なデータのみを収集、利用する必要があります。この点に関する実践的なヒントは、ベスト プラクティス (英語) ガイドに掲載されています。2022 年も、権限を調整して適切なユースケースに近づける作業を継続しています。さらに、古いバージョンの Android OS の API を利用するアプリから生じるリスクを軽減する方法について、デベロッパーの皆さんと積極的に話し合っています。近日中に詳細をお知らせしますので、ポリシー更新関連のメールをお待ちください。
Google Play が誰にとっても信頼できるアプリとゲームの提供元であり続けるためご協力いただきますよう、お願いいたします。
Reviewed by Konosuke Ogura - Trust & Safety - Play & Android, Global Content Operations Lead, Tamao Imura - Developer Marketing Manager, Google Play
この記事は Phalene Gowling による Android Developers Blog の記事 " Grow your game’s revenue with Google Play Console’s new strategic guidance " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年のモバイルゲームへの消費者支出は7.3% 増の 932 億ドル (英語) に達し、勢いが衰える気配はありません。競争が激しいこの成長市場で、効率的に収益を上げることはこれまでになく重要になってきています。しかし、戦略コンサルタントを利用しない限り、どのように自社の収益化戦略を強化すべきか判断することが難しいのではないでしょうか。
このような課題を支援するため、Google Play は Play Console の一連のツールを拡張し続けています。2021 年には、皆さんのビジネス拡大に役立てていただくため、統計情報のページに新しいエンゲージメントと収益化の指標をリリースしました。そして今回、収益化の成功に役立つ新たな戦略的ガイダンス ツールを発表しました。
ゲームの収益化の向上を支援するため、指標に基づいたガイダンスが表示されたことで以下が可能になります。
戦略的ガイダンス指標の階層（詳細は Google Play アカデミーの KPI のモニタリング もしくはこちらのブログ (英語) をご確認下さい）
Google はこの数年間、一部のパートナーとともにダッシュボードをテストし、このガイダンスを完成に近づける作業をしてきました。この戦略的ガイダンスに対するフィードバックは好意的なものでした。皆さんも、ぜひご活用ください。
「この機能は本当に便利です！このような種類のインサイトは、まさに私たちが Google に期待していたものです。なぜなら、これらは私たちのビジネスを拡大するために非常に役立つものだからです。」
- Gameloft のプロダクト マネージャー
戦略的ガイダンスは、Google Play Console の売上レポートから確認できます。モバイルゲームの成長に関するエキスパートの協力のもと、簡単に類似アプリとパフォーマンス比較ができるよう、主要な収益化指標（新しい指標を含む）とその相関関係を追加しました。すべての指標は ヘルプセンターの記事 で確認できます。
この指標階層は、ゲームのどの下位指標（購入者のコンバージョンなど）を改善すると全体の収益増加に最も効果的かを理解するうえで役立つツールです。 類似アプリグループのベンチマークや国別の内訳を利用すると、どの市場では不調で、どの市場ではマーケット リーダーであるかなどの成長機会をすばやく特定することができます。
指標を選択して詳細を確認し、時系列でパフォーマンスを追跡してみましょう。戦略的ガイダンスでは、選択した指標の地域別の内訳が表示されるので、ゲームをグローバルに展開する機会を見出すのに役立ちます。また、詳細な指標分析を活用することにより、小さな投資で大きな効果を得られるところを特定できます。
一日あたりの購入者比率を改善するための戦略的ガイダンスの指標提案例
カジュアル ゲームから RPG まで、各指標個別の推奨事項は、さまざまなゲーム デベロッパーの皆さんに役立つ多くのインサイトを得られるように設計されています。プロモーション コンテンツの多様化、ゲームの仕組みの改善、購買力平価を実現するための新しい価格帯のテストなどにご活用ください。
広告のみのマネタイズからアプリ内購入 (IAP)へとビジネスモデルをシフトするデベロッパーが増える中、Google は、 IAP による収益化を全体の戦略の中に組み込んでいるデベロッパーの皆さんのために戦略的ガイダンスを開発しました 。今回のローンチにより、このようなゲーム デベロッパーの皆さんに、グロース コンサルティングの機会を幅広く提供できることを嬉しく思います。2022 年も皆さんの収益拡大を支援するために、さまざまなローンチを予定しておりますので、ご期待ください。
この記事は Smule Engineering team (David Gayle, Chris Manchester, Mark Gills, Trayko Traykov, Randal Leistikow, Mariya Ivanova) による Android Developers Blog の記事 " Smule Adopts Google’s Oboe to Improve Recording Quality & Completion Rates " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
これまでで最も多くダウンロードされたカラオケアプリをリリースしている Smule Inc. は、Android で全般的な音質を向上させる取り組みを進めています。具体的にはレイテンシ (遅延) の改善、例えば歌いながらヘッドセットで自分の声を聴けるようにすることです。1,000 万人以上の Android ユーザーに使われている Smule アプリを OpenSL オーディオ API から Oboe オーディオ ライブラリに移行するため、オーディオと動画の専門チームは 2021 年に必要な変更をしました。これにより、録音完了率が 10% 以上向上しています。
Smule Inc. は、たくさんの人々がお気に入りの歌を歌い、日々それを共有できるカラオケアプリのリーディング企業の 1 社です。Smule アプリは、共同制作に特化することで従来のカラオケの枠を超え、友人やプラットフォーム上の他のシンガー、さらにはお気に入りの音楽アーティストと音楽を共有し共同作業ができるという、他にはない機会をユーザーに提供します。特に重要なのは音質で、Smule チームは 2020 年に Android でのエクスペリエンスを改善する可能性を見いだしました。
世界市場の多様なデバイスをサポートしつつ、最新デバイスの超高速ハードウェアを活用するには、Smule が使っていた以前の OpenSL 実装は適切なものではありませんでした。Smule の開発チームは、オーディオ システムのアップグレードが不可欠で、それは合理的な改善であると判断しました。
この改善には 2 つのアプローチがあります。1 つは、Android O で導入され、低レイテンシが求められるアプリ向けに設計された高パフォーマンス Android C オーディオ API である AAudio を直接ターゲットにする方法。もう 1 つは、内部に AAudio と OpenSL の両方を包含した Oboe (英語) を使う方法です。Smule の開発チームは、慎重に評価を行い、使いやすいコードベース、幅広い互換デバイス、手厚いコミュニティ サポートを特徴とする Oboe を採用することにしました。その結果、レイテンシを最低限にとどめ、利用できるネイティブ オーディオを最大限活用することができました。
Oboe への移行は、アーキテクチャとテクノロジーの大きな進化を意味します。そのため、ロールアウト プロセスは慎重に臨みました。段階的にリリースする計画を立て、少数のデバイスモデルから始めて品質を評価しつつ、週を追うごとに有効化するデバイスを増やしました（Oboe で問題が発生したごく一部のデバイスは、OpenSL に戻しました）。この入念な段階的アプローチにより、リスクを最小化でき、エンジニアリング チームも発生したデバイス固有問題に対応できました。
Smule が Oboe に切り替えたのは、アプリのエクスペリエンス向上のためです。期待した成果は、オーディオ再生時のクラッシュを大幅に減らし、録音時のエコーや雑音などの問題をなくし、オーディオ レイテンシを減らすことでした。Android デベロッパー ブログの昨年の記事には、人気のデバイス上位 20 種類での平均レイテンシが、2017 年の 109 ミリ秒から、Oboe を使う現在では 39 ミリ秒に減少したことが記載されています。109 ミリ秒の遅延があると、明らかなエコーとして聞こえるため、ライブで歌う際に邪魔になります。しかし、39 ミリ秒であれば、リアルタイム アプリに許容されるしきい値内に収まります。現在のトップデバイス間のレイテンシの差は、すべて 22 ミリ秒以内に収まっています。この一貫性も大きなプラスです。
Smule が Oboe を使うようになってから録音完了率が上昇したことも、このレイテンシの改善が関連しているでしょう。レイテンシが低下すると、Smule のワールドクラスのオーディオ効果を適用しながら、エコーなしに自分の歌声をヘッドセットで聴くことができます。
Smule が Oboe を組み込む際、Google のチームも深く関与しました。具体的には Oboe 用の GitHub ポータルによる効率的な共同作業を通した、重要な知見やサポートの提供です。2 つのチームの共同作業により、何百万ものアクティブ ユーザーという、これまでで最大の Oboe 展開をリリースすることができました。Smule チームはいくつかの Oboe コードの問題に対処し、Google のチームは一部のモバイル デバイス メーカーとの調整をし、Oboe の互換性をさらに向上させました。
音質は、シンガーのコミュニティにとって最も重要なもの。共同作業によって、できる限り最高のエクスペリエンスを提供し、Smule での音楽制作をサポートできたことに感謝しています。- Smule CTO 、Eric Dumas 氏
大規模に利用されることを考えれば、デバイス固有の問題に直面するのは当然のことです。その顕著な例が、未処理のオーディオ ストリームにエコー効果を挿入する OS ビルトイン機能でした。このような機能が存在すると、Smule 独自の DSP アルゴリズムやオーディオ フィルタを正しく適用できなくなります。その際、Google チームは迅速にライブラリのアップデートやパッチを提供するよう試みました。Oboe の問題を報告するプロセスをシンプルで明確に定義することで、タイムリーに対応したのです。
Smule は特定のチップセットで発生するエラーなど、その他のデバイス固有の問題も協力して克服しました。例えば、Oboe がモノラルのマイク入力を要求したとき、一部のデバイスではステレオ入力を 1 つにミックスし、疑似的にモノラルのマイク入力を提供したのです。Smule は Oboe の GitHub でチケットを作成し、例を提示して、Oboe テスターアプリで問題を再現しました。
Google が開発した Oboe テスターアプリは、実装の問題を特定して解決するうえで便利なツールでした。特に役に立ったのは Oboe、AAudio、OpenSL ES のさまざまな機能のテスト、Android デバイスのテスト、レイテンシや不具合の測定などです。このアプリには非常に豊富な機能があり、ほぼすべてのオーディオ設定をシミュレーションできます。また、Android Intent を使ってシェル スクリプトから Oboe テスターアプリを起動すれば、自動テストにも利用できます。Smule は、大量のデバイスが対象になることを考慮し、この自動テストを有効活用しました。
Smule は、デバイス固有の問題が解消され、Oboe オーディオが十分安定したと確信できた段階で、大規模なスプリット テスト ロールアウトによるアプローチに切り替えました。わずか数週間のうちに、問題のないデバイスで Oboe の利用比率を 10% から 100% に増やしました。これが実現できたのは、リリースが始まってから Oboe に対して継続的に寄せられていた肯定的なフィードバックと、順調な KPI 指標があったからに他なりません。
良い結果も出ています。Oboe 対応の Smule ユーザーは、より多く歌っているのです。重複を省いたカラオケ録音数や歌唱への参加数（デュエット）は、なんと 8.07% も増加しました。また、重複を省いたアップロード数は 3.84%、最後まで歌われた曲の数は 4.10% 増加しました。2021 年の第 3 四半期と第 4 四半期には、録音完了率 が 10% 以上増加しました。
Smule は Google の Firebase Crashlytics ツールを使い、Oboe を完全リリースして以降、オーディオ関連のクラッシュが減少してアプリの安定性が向上したことを把握しています。これはローエンド デバイスでも同様です。Smule の専属カスタマー サポートチームは、意図しない自動音声やエコーなどといったオーディオ関連の苦情が 33% 減少したことに、喜びの声をあげています。
Oboe に切り替えるという決断は、確かに成果をもたらしました。アプリの動作はこれまで以上に良好になり、オーディオのさらなる進化や最新テクノロジーを搭載したハードウェアに対応する準備も整っています。何より、Smule ユーザーは楽しく音楽制作にあたることが出来ています。
この記事は Rohan Shah による Android Developers Blog の記事 " Material You: Coming to more Android devices near you " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
まもなく、Material You、とりわけダイナミック カラーが利用できる Android 12 スマートフォンが世界中で増加します。これには、Samsung (英語) 、OnePlus、Oppo、Vivo、realme、Xiaomi、TECNO などによるデバイスが含まれます。
Android 12 のリリースと Material You の導入により、ユーザーの Android エクスペリエンスは、これまでになく軽快でパーソナルなものになっています。豪華な新デザインのおかげで、ダイナミックさが増したタッチリップル、とてもなめらかなスクロール、広々としたレイアウトなどのエクスペリエンスが、現実のものになりました。ただし、そのエクスペリエンスの中心であり、これからもそうであり続けるのは、ダイナミック カラーです。この機能では、お気に入りの壁紙を選ぶと、ホーム画面から一部のお気に入りのアプリまで、スマートフォンのエクスペリエンス全体が皆さんをよりよく表現するものに変換されます。
Material You が導入された今、パーソナライゼーションは Android の決定的な特徴となっています。このエコシステムは、これを土台に、今後何年にもわたって成長し続けることになるでしょう。デベロッパーの皆さんには、自信を持ってこの道のりに参加し、アプリでこれまで以上にパーソナルなルック アンド フィールをユーザーに提供していただきたいと思っています。
Material You をサポートする一部の Android デバイスのエクスペリエンスで、さまざまな壁紙ベースのテーマを適用した虹色の Gmail
これからの数か月で、さらに多くの Android 12 デバイスが登場します。OEM パートナーは、重要なデザイン API、特にダイナミック カラー関連が Android エコシステム全体で一貫して動作するように、私たちと連携して作業を進めています。それにより、デベロッパーには安心を、ユーザーには安定した体験によるメリットを提供できます。
マテリアル チームは、ダイナミック カラーの実装方法と、それを総合的なブランド ストーリーに組み入れる方法について理解を深めていただけるように、マテリアルのカスタマイズに関する包括的な記事 (英語) を公開しました。合わせて、ビュー (英語) や Jetpack Compose でこれを使ってみるための Codelab やガイドも提供しています。デザインや実装に必要なツールとして、 Material Theme Builder や Material Color Utilities を更新する作業も続いています。今後数か月間は、お見逃しなく。
マテリアル テーマ ビルダーを使って、アプリでダイナミック カラーを視覚的に確認
Google アプリ（Gmail、フォト、Chrome など多数）も、まさにこのツールとガイドを使って、ブランド体験でカラーによるストーリーを実現しています。皆さんにも、ぜひお試しいただきたいと思っています。どうすればユーザーが選択したカラーと調和させる (英語) ことができるかについての知識が増え、アプリでダイナミック カラーを使えるようになったら、Material Android Issue Tracker (英語) にフィードバックをお送りいただけると幸いです。ぜひ、カラーをお楽しみください！
この記事は Android Team による Android Developers Blog の記事 " Chrome’s multitasking usage increases 18x on large screens " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google Chrome は、世界で最も広く使われているブラウザです。そして Chrome チームは、そのユーザーがあらゆるデバイスで確実にすばらしい体験ができるようにしたいと願っています。多くの Chrome ユーザーは、モバイル、タブレット、折りたたみ式デバイスにも生産性機能が追加され、PC 版 Chrome の機能に匹敵するようになることを望んでいます。こういったニーズに応えるため、マルチタスク機能を推進できる仕組みを構築することにしました。この機能の開発対象にはスマートフォンも含まれていますが、最もよく使われると思われるタブレットや折りたたみ式などの大画面デバイスを特に主眼において実装することにしました。
まずは、複数の Chrome ウィンドウ（インスタンス）を並べて開く方法の開発に注力することにしました。それに当たり、タスクバーなどの 12L の機能や、Samsung のエッジパネルを活用しました。
横に並べる機能は、singleInstancePerTask (英語) 起動モードを使って構築しました。必要だったのは、ユーザーが同時にたくさんのウィンドウを使えるようにすることと、機能のユーザビリティを両立することです。そこで、ユーザビリティのベスト プラクティスを調査し、大画面デバイスでの他のマルチウィンドウ体験を観察し、デバイスで最適なメモリ使用量を保証するための制限について検討しました。そして、大画面デバイスでは最大 5 つのウィンドウを並べても快適に利用できると判断し、この機能をサポートするようにアプリを更新しました。
また、ユーザーにとって使いやすい機能にするため、メニューに新規ウィンドウのショートカットを追加しました。このショートカットは、新しいインテント フラグの組み合わせ LAUNCH_ADJACENT | NEW_TASK (英語) を使って作成しました。プロダクト内でこの機能が目立つように表示されたことで、使用頻度が大幅に向上し、 マルチウィンドウの利用が 18 倍になりました。
これは新機能ですが、Chrome アプリのマルチインスタンスの利用は、この機能をサポートしているスマートフォンと比較して、タブレットと折りたたみ式では 42% 多いことがすでにわかっています。利用状況から、この機能は大画面デバイスの Chrome ユーザーに好意的に受け止められていることが示されています。また、このような機能を構築して、大画面の Chrome ユーザーのエクスペリエンスを拡張することは、価値がある作業であることもわかります。
さらに、アプリのレビューという形でも、以下のように大画面ユーザーからたいへん好意的なフィードバックが寄せられています。「このアプリはすばらしい 👌！画面を分割したり、タブを変更したりできます。その中でたくさんのゲームをプレイすることもできます。私はこのアプリに 5 つ星をつけます」
今後も、大画面での Chrome エクスペリエンスとユーザーの生産性をさらに向上させたいと考えています。
大画面向けにアプリの最適化を始める方法は、こちらをご覧ください。
この記事は Adarsh Fernando による Android Developers Blog の記事 " Android Studio Bumblebee (2021.1.1) Stable " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Studio チームは、Android 公式の IDE とビルドシステムの最新版である Android Studio Bumblebee (2021.1.1) 🐝 と Android Gradle プラグイン (AGP) 7.1.0 の安定版リリースに向けて取り組んできました。一般的なデベロッパー ワークフローの幅広い領域で機能強化をしました。具体的には、ビルドとデプロイ、プロファイリングと検査、そしてデザインです。
注目すべき追加機能をいくつか挙げてみましょう。Android Studio と継続的インテグレーション (CI) サーバー間での統合テストの実行 ✅、ADB over Wi-Fi をサポートするための便利なペア設定フロー 📲、アプリのジャンクを特定して分析する際に役立つプロファイラ ツールの強化 🕵️、アプリをデバイスにデプロイせずにアニメーションをプレビューしたり 🎥 UI インタラクションしたりする新たな方法などです。
今回のリリースも、プレビュー ユーザーの皆さんからの早期フィードバックがなければ実現できなかったはずです。以下では、今回の安定版の主な特長や新機能について紹介します。さっそく自分で試してみたい方は、公式ウェブサイトから Android Studio Bumblebee (2021.1.1) (英語) をダウンロードしてください。
以下では、Android Studio Bumblebee (2021.1.1) のすべての新機能を 3 つの主なテーマにまとめています。
デバイス マネージャ
ADB over Wifi によるデバイスのペア設定
異なるランナーを使うと、結果が一致しない
今回より、Android Studio は Gradle からインストルメンテーション テストを実行
CPU Profiler の詳細なフレーム ライフサイクル情報
<profileable android:shell="true"/>
Background Task Inspector でのジョブ、アラーム、ウェイクロックの検査
Compose プレビューを操作して動作を検証
アニメーション付きベクター型ドローアブルのプレビュー
以下、Android Studio Bumblebee (2021.1.1) に含まれる主な機能拡張と新機能をまとめます。
この記事は Kateryna Semenova, Rahul Ravikumar, Chris Craik による Android Developers Blog の記事 " Improving App Performance with Baseline Profiles " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
多くのアプリにおいて、アプリのパフォーマンスとユーザー エンゲージメントとの間に相関性があることがわかっています。ユーザーが期待するのは、応答性が高く、読み込みが速いアプリです。起動時間は、アプリのパフォーマンスと品質の重要な指標の 1 つになっています。
私たちのパートナーのいくつかは、アプリの起動を最適化するために、すでに多くの時間とリソースを費やしています。その一例として、Facebook のストーリーをご確認ください。
この記事では、ベースライン プロファイルと、それがどのようにアプリやライブラリのパフォーマンスを改善するかを紹介します。その結果、起動時間が最大 40% 短縮されることもあります。ここでは起動に注目しますが、ベースライン プロファイルはジャンクにも大変有効です。
Android 9 (API レベル 28) では、アプリの起動時間短縮を目的として、Play Cloud に ART 最適化プロファイル (英語) が導入されました。クラウド プロファイルが利用できる場合、アプリのコールド スタートは、さまざまなデバイスで少なくとも平均 15% 高速になることがわかっています。
アプリがインストール後やアップデート後に初めて起動する場合、JIT コンパイルが行われるまでの間、コードはインタープリタ モードで動作します。APK では、Java と Kotlin のコードは dex バイトコードにコンパイルされますが、完全にコンパイルしたアプリの保存や読み込みにかかるコストの関係で、完全にマシンコードにコンパイルされることはありません (Android 6 以降)。アプリのクラスやメソッドのうち、頻繁に使われるものやアプリの起動に使われるものは、プロファイルのファイルに記録されます。そしてデバイスがアイドルモードになると、ART がそのプロファイルに基づいてアプリをコンパイルします。これにより、その後のアプリ起動が高速になります。
Android 9 (API レベル 28) より、Google Play もクラウド プロファイルを提供するようになっています。デバイスでアプリを実行すると、ART が生成したプロファイルが Play Store アプリにアップロードされ、クラウドに集約されます。アプリに対して十分な数のプロファイルがアップロードされると、Play アプリは集約したプロファイルを利用して、その後のインストールを行います。
クラウド プロファイルが利用できる場合、それが大きな効果を発揮してくれますが、アプリをインストールするときに常に利用できるとは限りません。通常、プロファイルの収集と集約には数日かかるため、多くのアプリで毎週アップデートが行われると、この点が問題になります。クラウド プロファイルが利用できるようになる前に、多くのユーザーがアップデートをインストールすることになるからです。そこで、Google の Android チームは、プロファイルが用意できるまでの時間を短縮する別の方法を探し始めました。
ベースライン プロファイルは、プロファイルを提供する新たなメカニズムであり、Android 7 (API レベル 24) 以降で利用できます。ベースライン プロファイルは、Android Gradle プラグインが生成する ART プロファイルです。人間が読むことができるプロファイル形式になっており、アプリやライブラリによって提供されます。たとえば、次のようなものです。
HSPLandroidx/compose/runtime/ComposerImpl;->updateValue(Ljava/lang/Object;)VHSPLandroidx/compose/runtime/ComposerImpl;->updatedNodeCount(I)IHLandroidx/compose/runtime/ComposerImpl;->validateNodeExpected()VPLandroidx/compose/runtime/CompositionImpl;->applyChanges()VHLandroidx/compose/runtime/ComposerKt;->findLocation(Ljava/util/List;I)I
HSPLandroidx/compose/runtime/ComposerImpl;->updateValue(Ljava/lang/Object;)V
HSPLandroidx/compose/runtime/ComposerImpl;->updatedNodeCount(I)I
HLandroidx/compose/runtime/ComposerImpl;->validateNodeExpected()V
PLandroidx/compose/runtime/CompositionImpl;->applyChanges()V
HLandroidx/compose/runtime/ComposerKt;->findLocation(Ljava/util/List;I)I
Compose ライブラリの例
バイナリのプロファイルは、APK のアセット ディレクトリの特定の場所 (assets/dexopt/baseline.prof )に格納されます。
ベースライン プロファイルは、ビルド時に作成され、APK の一部として Play に提供されます。そして、ユーザーがアプリをダウンロードするときに、Play からユーザーに送信されます。クラウド プロファイルがまだ利用できない場合、ベースライン プロファイルが ART クラウド プロファイル パイプラインの足りない部分を補います。クラウド プロファイルが利用できる場合、ベースライン プロファイルは自動的にクラウド プロファイルと結合されます。
ベースライン プロファイルの作成からエンドユーザーへの配信までのワークフローを示した図
ベースライン プロファイルの特に大きなメリットは、ローカルで開発や評価が行える点です。そのため、デベロッパーは実際にエンドユーザーが体験するパフォーマンスの向上を確認できます。また、クラウド プロファイルは Android 9 以降でしか利用できませんが、ベースライン プロファイルはそれよりも古いバージョンの Android (7 以降) でもサポートされています。
2021 年の前半に、Google マップのリリース サイクルが 2 週間から 1 週間に変更されました。アップデートの頻度が高くなるということは、ローカルの作成済みプロファイルがより頻繁に破棄され、Play クラウド プロファイルが存在しないために起動が遅くなるユーザーが増えるということでもあります。しかし、ベースライン プロファイルを使うことで、Google マップの起動時間は平均 30% 短縮され、それに伴って検索が 2.4% 増加しました。このように既に定着したアプリにとっても、非常に大きな成果です。
ライブラリに含まれるコードも、アプリのコードと同じです。デフォルトでは完全にコンパイルされないので、起動時のクリティカル パスで大量の処理を行う場合、問題につながる可能性があります。
Jetpack Compose は、Android システム イメージには含まれない UI ライブラリです。そのため、多くの Android View ツールキットのコードとは異なり、インストール時に完全にコンパイルされることはありません。そのため、パフォーマンスの問題が発生することがありました。特にそれが顕著だったのが、最初の数回のコールド スタート時です。
この問題を解決するため、Compose はプロファイル インストーラを利用します。これがベースライン プロファイルのルールを提供してくれるので、Compose アプリの起動時間やジャンクが減少します。
Google Play ストアの検索結果ページは、Compose を使って書き直されています。Compose からベースライン プロファイル ルールを取り込んだ後では、イメージを含む最初の検索結果ページを表示するまでの時間が最大 40% 短縮されました。
Android チームも、関連する AndroidX ライブラリにベースライン プロファイルを追加しました。これは、対象のライブラリを使うすべての Android アプリにメリットがあります。Constraint Layout では、プロファイルのルールを提供 (英語) することで、アニメーションのフレーム時間が 1 ミリ秒以上短縮されました。
ベースライン プロファイルを含めると、アプリやライブラリのデベロッパーすべてがメリットを得られます。理想的な方法は、特に重要なユーザー操作について、デベロッパーが複数のプロファイルを作成することです。それにより、クラウド プロファイルが利用できるかどうかによらず、常にその操作のパフォーマンスが高速になります。アプリ デベロッパーとライブラリ デベロッパー向けのベースライン プロファイルの設定方法は、詳細なガイドをご覧ください。
すぐにはアプリのベースライン プロファイルを作成できないという方でも、依存関係を更新することで、ベースライン プロファイルによるメリットを享受できます。Android Gradle Plugin 7.1.0-alpha05 以降でビルドすれば、ライブラリ (Jetpack など) が提供するベースライン プロファイルを APK に含めることができます。Google Play は、インストール時にそのプロファイルを使ってアプリをコンパイルします。プロファイルの追加は、アプリのビルドの一環として行うことができます。
忘れずに改善の測定を行うようにしましょう。生成されたプロファイルを使ってローカルで起動を測定するには、こちらの手順に従います。
ぜひフィードバックを共有し、皆さんの体験をお知らせください！ (英語)
.png.jpeg)
.png)
.png)
.png)
.png)
.png)
