この記事は 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 ユーザーは楽しく音楽制作にあたることが出来ています。
この記事は Dan Galpin による Android Developers Blog の記事 " Android Basics and Training Update " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 10 月、Android Basics in Kotlin (Kotlin による Android の基礎) (英語) の最後のユニットを公開しました。この無料の自習型プログラミング コースで学べば、誰でも Android 開発ができるようになります。このコースでは、プログラミングの経験がない方向けに、Android アプリを開発する方法を説明します。学習を通して、プログラミングの基本や Kotlin プログラミング言語の基礎を習得できます。
私たちは、教育者や学習者からのフィードバックをもとに、コースの教材を見直す作業を続けており、学んだことを応用できるプロジェクトや、さらに高度な教材の足がかりとなる新たなトピックを追加しています。
今回のアップデートにより、現在の Android Basics in Kotlin (Kotlin による Android の基礎) は、Android Kotlin Fundamentals の核となる教材を網羅するようになっています。そのため、後者のコースの提供は終了する予定です。さらに上級の学習者の方にも、本教材に取り組むことをおすすめします。よく知っている内容のセクションはスキップし、直接理解度チェックに挑戦しましょう。重要なコンセプトを見逃す可能性のある中級者や上級者も、成功のために必要なことを本教材から学べます。私たちのチームも、最新のガイダンスをコースに確実に反映する作業に注力できます。あらゆるレベルの学習者に応えるため、コースに加えて、Codelabやコードサンプル、ドキュメントや動画コンテンツの提供も続けます。
私たちは、次のコースとして、Jetpack Compose による Android アプリのプログラミングを説明するコースの準備を進めています。 Android のネイティブ UI 開発用最新ツールキットについて説明できるようになる日が待ち遠しいです。このコースによって、Android の UI 開発のあらゆる側面がシンプルになり、高速になるからです。
現在のコースを受講すると、アプリ開発の基本を学ぶことができます。その経験は、既存の Jetpack Compose の学習パス (英語) を受講する際にも、近日公開の Android Basics with Compose コースを受講するうえでも、絶好のスタート地点となります。Android 開発の世界を探索し続けるうえで、土台となる部分をしっかりと身につけることができます。Android Basics は両方のバージョンが共存する予定で、どちらの UI ツールキットでも Android を学べるようになります。
まだアプリを作ったことはないけれども、その方法を学びたいと思っている皆さん。そして、最新のベスト プラクティスを通じて技術に磨きをかけたい皆さん。ぜひ Android Basics in Kotlin コース (英語) をチェックしてみてください。
この記事は Chet Haase による Android Developers - Medium の記事 " JankStats Goes Alpha " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
イラスト : Virginia Poltrack
ジャンク（名詞）: アプリケーションのパフォーマンスが悪いこと。フレーム落ちが発生したり、UI の動作が断続的になったりして、悪いユーザー エクスペリエンスにつながる。「不幸なユーザー」も参照。
パフォーマンスの問題をデバッグするのは、難しいことです。多くの場合、どこから始めればよいか、どのツールを使うか、ユーザーにどんな問題が起きているのか、その問題が実際のデバイスにどう出現しているのかは、明確ではありません。
Android チームは、ここ数年をかけて、問題のさまざまな部分をデバッグするツールを増やしてきました。たとえば、起動パフォーマンス (英語) の分析、特定のコードパスのテスト、特定のユースケースのテストや最適化、IDE のビジュアル プロファイラなどです。これらはすべて開発時のテスト用で、ローカルで確認できる問題をデバッグして修正する際に役立ちます。
一方、Google Play の Android Vitals、そして Firebase は、どちらもダッシュボードを提供しており、そこで実際のユーザーのデバイスでアプリがどのように動作しているかを確認できます。
しかしそれでも、実環境のアプリで発生する問題の見つけ方を知るのは難しいことです。とりわけ、ユーザーのデバイスで発生し、自分の席で快適に利用できる便利な開発マシンだけでは見ることができない問題はそう言えます。パフォーマンス ダッシュボードは役立ちますが、ユーザーに問題が発生しているときに、そこで何が起こっているかがわかるほどの詳しい情報が提供されるとは限りません。
そこで登場するのが、JankStats です。これは、ユーザーのデバイスで発生しているアプリのパフォーマンスの問題を計測して報告することに特化した AndroidX 初めてのライブラリです。
JankStats はかなり小さな API で、根本的な目的が 3 つあります。それは、フレームごとのパフォーマンス情報をキャプチャすること、アプリを（開発環境だけでなく）ユーザーのデバイスで実行すること、そしてパフォーマンスの問題が起きたときにアプリで発生していることを計測したり報告したりできるようにすることです。
Android プラットフォームでは、フレームのパフォーマンス データを取得する方法がすでに提供されています。たとえば、API 24 以降では FrameMetrics を使えます。また、最近のリリースでは、さらに詳しい情報を提供できる機能が追加されています。それ以前のリリースで実行している場合も、精度は落ちますが、さまざまな手法で有用なタイミング情報を取得できます。
そのため、すべてのリリースで動作する独自のフレーム時間ロジックが必要なら、さまざまな API バージョンでさまざまなメカニズムを実装しなければなりません。しかし、そうする代わりに 1 つの JankStats API を使うだけで、それが皆さんの代わりにすべてをしてくれます。さらに、その他の機能も提供されます。
JankStats では、1 つの API でフレームごとの時間を報告できるので、簡単に計測できます。内部的には、適切なメカニズム（API 24 以降の FrameMetrics (英語) など）に委譲しています。データがどこから来るかを気にする必要はなく、単に JankStats にどのくらい時間がかかったかを聞けばいいだけです。すると、コールバックでその情報が返されます。
実際に JankStats のデータを生成したりリスニングしたりするのも、それと同じくらい簡単です。生成して、あとはリスニングして待てばいいだけです（厳密に言えば、待つのはコードですが）。JankStats のサンプル JankLoggingActivity から、この手順の例を紹介しましょう。
val jankFrameListener = JankStats.OnFrameListener { frameData -> // real app would do something more interesting than log this... Log.v("JankStatsSample", frameData.toString())}jankStats = JankStats.createAndTrack( window, Dispatchers.Default.asExecutor(), jankFrameListener,)
val jankFrameListener = JankStats.OnFrameListener { frameData ->
// real app would do something more interesting than log this...
Log.v("JankStatsSample", frameData.toString())
}
jankStats = JankStats.createAndTrack(
window,
Dispatchers.Default.asExecutor(),
jankFrameListener,
)
Log.v()
JankStats.OnFrameListener: FrameData(frameStartNanos=827233150542009, frameDurationUiNanos=27779985, frameDurationCpuNanos=31296985, isJank=false, states=[Activity: JankLoggingActivity])JankStats.OnFrameListener: FrameData(frameStartNanos=827314067288736, frameDurationUiNanos=89903592, frameDurationCpuNanos=94582592, isJank=true, states=[RecyclerView: Dragging, Activity: JankLoggingActivity])JankStats.OnFrameListener: FrameData(frameStartNanos=827314167288732, frameDurationUiNanos=88641926, frameDurationCpuNanos=91526926, isJank=true, states=[RecyclerView: Settling, RecyclerView: Dragging, Activity: JankLoggingActivity])JankStats.OnFrameListener: FrameData(frameStartNanos=827314183945923, frameDurationUiNanos=4731405, frameDurationCpuNanos=8283405, isJank=false, states=[RecyclerView: Settling, Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827233150542009, frameDurationUiNanos=27779985, frameDurationCpuNanos=31296985, isJank=false, states=[Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827314067288736, frameDurationUiNanos=89903592, frameDurationCpuNanos=94582592, isJank=true, states=[RecyclerView: Dragging, Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827314167288732, frameDurationUiNanos=88641926, frameDurationCpuNanos=91526926, isJank=true, states=[RecyclerView: Settling, RecyclerView: Dragging, Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827314183945923, frameDurationUiNanos=4731405, frameDurationCpuNanos=8283405, isJank=false, states=[RecyclerView: Settling, Activity: JankLoggingActivity])
ログに出力された frameData には、いくつかの興味深い点があります。
frameData
isJank=true
JankLoggingActivity
Thread.sleep()
FrameMetrics
Activity
JankStats は、最近のベンチマーク用ライブラリとは異なり、ユーザーのデバイスから結果を取得できるように作られています。開発マシンで問題をデバッグできるのはすばらしいことですが、実世界の実ユーザーが、制約の異なるさまざまなデバイスでアプリを使っている状況では、開発マシンでのデバッグは役に立ちません。
JankStats では、アプリを計測して必要なパフォーマンス データを提供する API や、そのデータをアップロードしてオフラインで分析できるようにするための報告メカニズムが準備されています。
最後に（このライブラリの本当に新しい注目点はここです）、JankStats では、パフォーマンスの問題が起きたときに、アプリで実際に何が起きていたのかを把握できる仕組みが提供されています。私たちがよく耳にする不満は、既存のツールやダッシュボード、アプローチでは、ユーザーが経験しているパフォーマンスの問題に関する十分な コンテキスト が得られないというものです。
たとえば、FrameMetrics API（API 24 で導入され、JankStats で内部的に使用されています）は、フレームの描画にどのくらい時間がかかったかを教えてくれるので、そこからジャンク情報を導き出すことができます。しかし、そのときにアプリで何が起こっていたかはわかりません。FrameMetrics などのパフォーマンス測定ツールを組み込み、コードを計測しようとしているのは皆さんなので、問題を見つけるのは皆さんの仕事です。しかし、皆さんは忙しくて、このような内部インフラストラクチャを構築することはできません。そのため、ジャンクの計測は行われず、パフォーマンスの問題が残り続けるのが一般的です。
同じように、Android Vitals ダッシュボードは、アプリでパフォーマンスの問題が発生していることは教えてくれますが、その問題が発生しているときにアプリが何をしていたかは教えてくれません。そのため、その情報を使って何をすればよいのかを知るのは困難です。
JankStats では、PerformanceMetricsState API が導入されます。これはシンプルなメソッドの集まりで、任意のタイミングでアプリの中で起きていることを教えてもらうように、システムに依頼します。結果は String のペアで表され、特定の Activity や Fragment がアクティブなタイミングや、RecyclerView がスクロールされるタイミングなどを知ることができます。
PerformanceMetricsState API
String
Fragment
RecyclerView
次の例は、JankStats サンプルのコードです。RecyclerView を計測し、その情報を JankStats に渡す方法を示しています。
val scrollListener = object : RecyclerView.OnScrollListener() { override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) { val metricsState = metricsStateHolder?.state ?: return when (newState) { RecyclerView.SCROLL_STATE_DRAGGING -> { metricsState.addState("RecyclerView", "Dragging") } RecyclerView.SCROLL_STATE_SETTLING -> { metricsState.addState("RecyclerView", "Settling") } else -> { metricsState.removeState("RecyclerView") } } }}
val scrollListener = object : RecyclerView.OnScrollListener() {
override fun onScrollStateChanged(recyclerView: RecyclerView,
newState: Int)
{
val metricsState = metricsStateHolder?.state ?: return
when (newState) {
RecyclerView.SCROLL_STATE_DRAGGING -> {
metricsState.addState("RecyclerView", "Dragging")
RecyclerView.SCROLL_STATE_SETTLING -> {
metricsState.addState("RecyclerView", "Settling")
else -> {
metricsState.removeState("RecyclerView")
この状態は、アプリのどこからでも（あるいは、別のライブラリからでも）挿入できます。JankStats は、結果を報告するときにこの状態を取得します。そのため、JankStats からレポートを取得すると、各フレームでかかった時間だけでなく、そのフレームでユーザーが何をしていたのかまでわかります。その操作がジャンクの原因になっているかもしれません。
JankStats をさらに詳しく知るためのリソースをいくつか紹介します。
AndroidX プロジェクト : JankStats は、AndroidX の androidx.metrics ライブラリにあります。
ドキュメント : デベロッパー サイトに新しいデベロッパー ガイドがあり、そこで JankStats の使い方が説明されています。
サンプルコード : このプロジェクトにサンプルがあります。JankStats オブジェクトをインスタンス化してリスニングする方法や、重要な UI 状態情報を使ってアプリを計測する方法が示されています。
performance-samples/JankStatsSample at main · android/performance-samples
バグ : ライブラリの問題を見つけた方や、API のリクエストがある方は、バグを送信してください。
JankStats は、最初のアルファ版がリリースされたばかりです。つまり、「私たちはこの API と機能を 1.0 リリースに妥当なものだと考えていますが、ぜひ試してみて感想をお知らせください」という意味です。
今後、JankStats で行いたいと考えていることは他にもあります。たとえば、集計メカニズムのようなものの追加や、既存のアップロード サービスとの同期などです。しかし、基本機能を搭載した最初のバージョンを公開し、皆さんの使い方や要望を確認したいと思いました。現在の基本的な状態でも、十分役に立つことを期待しています。簡単に計測して UI 状態情報を記録できるだけでも、何の機能もないよりはよいはずです。
ぜひこれを入手してお試しください。そして、問題があればお知らせください。いち早くパフォーマンスの問題を見つけて修正しましょう！ユーザーは皆さんを待っています。
この記事は 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 は、インストール時にそのプロファイルを使ってアプリをコンパイルします。プロファイルの追加は、アプリのビルドの一環として行うことができます。
忘れずに改善の測定を行うようにしましょう。生成されたプロファイルを使ってローカルで起動を測定するには、こちらの手順に従います。
ぜひフィードバックを共有し、皆さんの体験をお知らせください！ (英語)
この記事は Florina Muntenescu による Android Developers Blog の記事 " Jetpack Compose 1.1 is now stable! " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは、Android の最新ネイティブ UI ツールキット、Jetpack Compose のロードマップを実現する作業を続けており、2022 年 2 月 9 日にバージョン 1.1 をリリースしました。今回のリリースには、フォーカス処理の向上、タッチ ターゲットのサイズ調整、ImageVector のキャッシュ、Android 12 のストレッチ オーバースクロールのサポートなどの新機能が含まれています。さらに、Compose 1.1 では、これまで試験運用版だったたくさんの API が安定版になっているほか、より新しいバージョンの Kotlin もサポートされています。すでにサンプル、Codelab、Accompanist ライブラリもアップデートしており、Compose 1.1 と合わせて利用できるようになっています。
Compose 1.1 に ImageVector のキャッシュ機能を導入し、パフォーマンスを大幅に向上させています。painterResource API にキャッシュ機構を追加しており、解析した ImageVector のすべてのインスタンスを、与えられたリソース ID やテーマと合わせてキャッシュできるようになっています。このキャッシュは、構成が変わると無効になります。
Compose 1.0 と比較した場合、マテリアル コンポーネントのレイアウトでは、マテリアルのアクセシビリティ ガイドライン（英語）に記載されているタッチ ターゲット サイズ（英語）を満たすようにレイアウト領域が拡大されます。たとえば、RadioButton のタッチ ターゲットは、最小サイズの 48x48 dp に拡大されます。RadioButton のサイズをそれ以下に設定した場合も同様です。これにより、Compose のマテリアルとマテリアル デザイン コンポーネントの動作が一致し、ビューと Compose が共存しても、動作の一貫性が保たれます。また、この変更により、Compose のマテリアル コンポーネントを使って UI を作成すれば、タッチ ターゲットのアクセシビリティ最低要件が確実に満たされるようになります。
この変更によって既存のレイアウト ロジックが壊れる場合は、LocalMinimumTouchTargetEnforcement (英語) を false に設定することで、この動作を無効化できます。ただし、アプリのユーザビリティが低下する可能性があることを認識したうえで、慎重に利用するようにしてください。
RadioButton のタッチ ターゲットの更新
左 : Compose 1.0、右 : Compose 1.1
いくつかの API が試験運用版から安定版になっています。主なものを紹介します。 (以下、リンク先はすべて英語)
Compose に新機能を導入する作業も続いています。いくつかの主な機能を紹介します。
@OptIn (英語) を使うと、新しい API を試すことができます。ぜひフィードバックをお願いします！
注 : Compose 1.1 を使うには、Kotlin 1.6.10 が必要です。詳しくは、Compose と Kotlin の互換性マップをご覧ください。
次に登場するのは何でしょうか。現在検討中または作業中の機能は、更新版のロードマップで確認できます。たとえば、遅延項目アニメーション、ダウンロード可能フォント、移動可能コンテンツなどです。
Jetpack Compose は安定版で、本番環境で利用できます。また、要望が寄せられた機能を追加する作業も続いています。すでに多くのアプリで Jetpack Compose が本番環境として使われ始めているのを見て、とてもうれしく思っています。皆さんが開発したアプリを見るのが、待ち遠しくてたまりません。
アルファ版やベータ版を通して Issue Tracker (英語) にバグレポートや機能リクエストをお送りいただき、大変感謝しています。Compose の改善や、皆さんに必要な API を作るうえで役立っています。Compose をよりよいものにするために、今後もフィードバックをお願いします！
Compose をお楽しみください！
この記事は Madan Ankapura による Android Developers Blog の記事 " Building apps for Android Automotive OS " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 1 月 27 日、Car App Library のバージョン 1.2 ベータ版が公開されたことをお知らせします。これにより、アプリ デベロッパーの皆さんは、Android Automotive OS 向けにナビゲーション、駐車場、充電スポットのアプリ開発を始めることができるようになります。
現在、デベロッパーの皆さんは、これらのカテゴリのアプリについて、Automotive OS エミュレータを使って構築とテストを始めることができます。Android Automotive OS と Android Auto の両方が対象となります。V1.2 ベータ版でのすべての変更点のリストは、リリースノートをご覧ください。自動車用のアプリ開発を始めるには、最新版のデベロッパー ドキュメント、自動車向けアプリの品質ガイドライン、デザイン ガイドライン (英語) をご覧ください。
以前 (英語) お知らせしましたが、Polestar 2 や Volvo の自動車を運転している方は、Google グループに参加し、Google Play ストアでご自分の Gmail アカウントを使って各アプリのベータ版をオプトインすると、充電スポット（ChargePoint、PlugShare）、駐車場（Spothero、Parkwhiz）、ナビゲーション（Flitsmeister、Sygic）のアプリをダウンロードできます。これらのアプリは、Car App Library を使って開発されています。
Android Automotive OS 上の Car App Library アプリは、各自動車の他のエクスペリエンスと一貫性を保つように自動的にレンダリングされます。デベロッパーがなんらかの作業を追加で行う必要はありません。次に例を示します。
Polestar 2
Volvo
Polestar 2 の設定、PlugShare でラベル付きのオン / オフ スイッチを表示
Volvo の設定、PlugShare でスライディング スイッチを表示
Polestar 2 での SpotHero のログイン画面
Volvo での SpotHero のログイン画面
Android Automotive OS でのアプリのカスタマイズ例
ナビゲーション以外では、ライドシェアのドライバは車の中で長い時間を過ごすため、車の画面でライドシェア関連のアプリを安全に使えるようになれば、メリットになります。今後数か月のうちに、Lyft や Kakao Mobility のドライバ向けアプリを車内で体験できるように、両社と連携して作業を進めています。
GPS マップが表示された車の画面のイメージと Lyft のロゴ
もう 1 つ、うれしいお知らせがあります。すべての有名スポットアプリを含めるように、サポートを拡大しているところです。これにより、充電スポットや駐車場だけでなく、観光名所などをマップ上で見つけたり、探したりするほか、場合によってはその場所へナビゲーションできるアプリを実現できます。早期アクセス パートナーとして、MochiMochi、Fuelio、Prezzi Benzina、NAVITIME JAPAN と連携しています。
今後の早期アクセスプログラムに参加したい方は、こちらのフォーム (英語) から登録してください。g.co/androidforcars にアクセスして、Android for Cars App Library をさっそく使ってみてください。
.png.jpeg)
.png)
.png)
