この記事は Yafit Becher、Ray Brusca による Android Developers Blog の記事 "New Google Play SDK Index helps you choose the right SDKs for your app" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリ デベロッパーは、アプリやゲームに重要な機能やサービスを組み込む際に SDK を利用します。SDK は構成要素として欠かせないものですが、信頼できて安全に使用できる SDK を判断するのは難しいという声がデベロッパーから寄せられています。そのため、皆さんのようなデベロッパーが十分な情報をもとに SDK を適切に決定できることは、数十億ものユーザーに利用される Google Play を安全で信頼できる場所にするための取り組みの一環だと言えます。
2020 年、Google は Google Play SDK Console をリリースしました。これにより、SDK プロバイダが障害レポートや使用統計情報を提供したり、Google Play Console や Android Studio を通してアプリ デベロッパーに重大な問題を公開したりできるようになりました。今回は、さらにコミュニケーションを強化し、透明性を高めるための新たな手段として、Google Play SDK Index をリリースしました。このパブリック ポータルでは、特に広く使われている 100 以上の商用 SDK と、それぞれの SDK に関する分析情報を確認できます。
Google Play SDK Index には各 SDK の信頼性と安全性シグナルが表示されるため、その SDK がビジネスとユーザーに適切であるかどうか、判断できます。
また、SDK を検索 (英語) したり、広告と収益化 (英語) やアナリティクス (英語) といったカテゴリ別に SDK を調べたりすることもできます。Google Play SDK Index では、ビジネスとユーザーに適した SDK を選択できるように、各 SDK について Google Play アプリの使用状況データと SDK コード検出を組み合わせた分析情報を提供しています。たとえば、次の情報を確認できます。
SDK プロバイダは、Google Play SDK Console に登録した SDK について、次のような重要な情報を共有することもできます。
開発ライフサイクルのどの段階であっても、情報に基づいて SDK を選択するために Google Play SDK Index をご活用ください。SDK のデータ ポイント、カテゴリ、ボリュームは今後も追加されていきますので、定期的に最新情報をご確認ください。
さらに詳しくは以下をご覧ください :
この記事は Juan Sebastian Oviedo による Android Developers Blog の記事 " Google I/O 2022: What’s new in Android Development Tools " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 5 月 11 日、Google I/O 2022 の中で、Android Studio Dolphin Beta と Android Studio Electric Eel Canary で利用可能になった新しい機能を発表しました (どちらのリリースもこちら (英語) からダウンロードできます) 。Android アプリを作成する際の生産性を向上させたいというデベロッパーからのご要望を受け、豊富な情報を活用しながらスムーズに開発するための改善です。
Android Studio Dolphin リリースが、安定版に近い品質で提供され、次のような新機能や機能向上を Beta チャネルで利用できます。
さらに新しい Android Studio Electric Eel のプレビュー リリースの機能は、Canary チャンネルでお試しいただけます。
上記の機能は、皆さんからのフィードバックを基にさらに改善を加えてから、より安定したチャンネルでリリースにも昇格されますので、ぜひお試しください。
すべての新機能の実際の動作については、Android デベロッパー ツールの新機能に関するセッションをご覧ください。
次に、Android Studio Dolphin の主な新機能と機能向上について紹介します。
Compose アニメーションの調整
マルチプレビュー アノテーション
Compose 再コンポーズ回数
Wear OS エミュレータ ペア設定アシスタント
Wear OS エミュレータのサイド ツールバー
Wear OS 実行 / デバッグ構成の新しいタイプ
Logcat V2
Gradle マネージド デバイス
次に、Android Studio Electric Eel の主な新機能と機能向上について紹介します。
エミュレータ上の Live Edit
プレビュー上の Live Edit
Google Play SDK Index のインサイト
Firebase Crashlytics に基づく App Quality Insights
サイズ変更可能なエミュレータ
ビジュアル lint チェック
エミュレートされた Bluetooth を使った、2 つの Android Emulator のペア設定
デバイスのミラーリング
まとめると、安定版に近い品質の Android Studio Dolphin Beta では、以下の新機能と機能向上をご利用いただけます。
Jetpack Compose
Wear OS
開発ツール
Android Studio Electric Eel Canary では、以下の新機能と機能向上をご利用いただけます。
Google Play と Firebase
大画面デバイス
Android Studio Dolphin Beta と Android Studio Electric Eel Canary は、いずれもこちら (英語) からダウンロードできます。こちらの手順に従ってインストールし、現在の安定版 Android Studio と共存することができます。ベータ版のリリースは安定版のリリースに近い品質ですが、まだバグが存在する可能性があります。問題が見つかった場合は、こちらのフォーム (英語) でご報告ください。同様に、Canary リリースで問題が見つかった場合や、機能についてフィードバックがある場合もご連絡ください。
問題に関するフィードバックや機能リクエストは、私たちにとって有用です。Twitter や Medium で、Android Studio 開発チームをフォローしてください。
新機能の詳細は、プレビュー リリースノートをご覧ください。 (※翻訳のタイミングによって、英語版と日本語版のリリースノートの説明内容に多少の差があります。)
この記事は Dave Burke による Android Developers Blog の記事 " The Beta for Android 13 is out now: Android 13 Beta 1 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは Android 13 の機能と安定性を向上させる作業を着実に進めています。Android 13 では、プライバシーとセキュリティ、デベロッパーの生産性、タブレットと大画面のサポートという中核テーマを主眼に置いて開発しています。2022 年 4 月 26 日、その作業がサイクルの次の段階に入り、Android 13 最初のベータ版をリリースしました。
Android 13 には、デベロッパーが注目すべきたくさんの機能があります。まずは、新しい通知パーミッションや写真ピッカーなどのプライバシー機能です。そして、テーマ対応アプリアイコン、クイック設定タイルの配置、アプリごとの言語サポートなど、魅力的なエクスペリエンスを開発するために役立つ API があります。さらに、Bluetooth LE オーディオや MIDI 2.0 over USB といった機能も導入されます。ベータ版 1 では、メディア ファイルへのアクセスを細分化した新しいパーミッションの追加、オーディオ ルーティング API の改善などをしています。5 月 11～12 日の Google I/O では、さらに多くのことをお知らせしましたので、ぜひごアーカイブをご覧ください！
このリリースについてのフィードバックを提供してくださる先行ユーザーの皆さんが増えることは大歓迎なので、ぜひベータ版 1 を試してみてください。Android 13 ベータ版 1 は、2022 年 4 月 26 日からサポート対象の Pixel デバイスで試すことができます。こちら (英語) から登録すると、無線（OTA）アップデートを受け取ることができます。すでに Android 13 のデベロッパー プレビューをお使いの方には、今回のアップデートや今後のアップデートがデバイスに無線（OTA）で自動配信されます。いつものように、Pixel と Android Emulator 用のダウンロードも利用できます。アプリの開発やテストを開始する詳しい方法は、Android 13 デベロッパー サイトに掲載されています。
ベータ版 1 では、プライバシーとセキュリティへの注力を続けつつ、ユーザーにとって魅力的なエクスペリエンスを開発するために役立つ新しい API を提供しました。ベータ版 1 には、新しい通知パーミッション、写真ピッカー、テーマ対応アプリアイコン、ローカライズや言語サポートの強化など、以前にお知らせした機能への最新アップデートが含まれています。また、少数の新機能も導入されるので、ぜひ試してみて感想をお聞かせください。
メディア ファイルにアクセスするパーミッションの細分化 - これまで、ローカル ストレージの共有メディア ファイルを読み取るアプリは、READ_EXTERNAL_STORAGE (英語) パーミッションをリクエストする必要があり、このパーミッションが付与されると、すべての種類のメディア ファイルにアクセスできるようになっていました。今回は、透明性とユーザーの制御を向上させるため、アクセスできる共有メディア ファイルのスコープを細分化した一連のパーミッションを新たに導入します。
新しいパーミッションでは、共有ストレージ内の特定の種類のファイルへのアクセスをリクエストすることになります。 (以下、全て英語)
My App が、このデバイスに格納されている音楽などのオーディオ ファイルにアクセスすることを許可する
ユーザーがパーミッションを付与すると、アプリはそれぞれの種類のメディア ファイルに読み取りアクセスできるようになります。シンプルなユーザー エクスペリエンスを実現するため、アプリが READ_MEDIA_IMAGE と READ_MEDIA_VIDEO を同時にリクエストした場合、両方のパーミッションを付与するダイアログを 1 回だけ表示します。アプリから共有メディア ファイルにアクセスしている方は、アプリのターゲットを Android 13 にする際に、新しいパーミッションに移行する必要があります。詳しくはこちらをご覧ください。
Keystore と KeyMint のエラー報告の改善 - 鍵を生成するアプリに対して、Keystore と KeyMint がこれまでよりも正確で細かいエラー インジケーターを提供します。具体的には、java.security.ProviderException (英語) の下に例外クラス階層を追加し、Keystore/KeyMint のエラーコード (英語) や再試行可能なエラーかどうかを含む Android 固有の例外を提供します。また、鍵生成、署名、および暗号化のメソッドを変更して、新しい例外を投げるようにすることも可能です。改善版のエラー報告では、鍵生成の再試行に必要な内容が提供されます。
オーディオ ルーティングの予測 - メディアアプリでオーディオがどのようにルーティングされるかを把握しやすくするため、AudioManager (英語) クラスに新しいオーディオ ルーティング API を追加しました。新しい getAudioDevicesForAttributes() (英語) API を使うと、指定したオーディオの再生に使われる可能性があるデバイスのリストを取得できます。また、オーディオ ストリームを直接再生できるかどうかを把握しやすくするため、getDirectProfilesForAttributes() (英語) API を追加しました。以上の新 API を使うと、オーディオ トラックに最適な AudioFormat (英語) を判断できます。
まだ Android 13 でアプリの互換性テストをしていない方は、ぜひこのタイミングで行っておきましょう！Android 13 がベータ版になったので、デベロッパーだけでなく、先行ユーザーもアクセスできるようになります。つまり、これから数週間のうちに、Android 13 で皆さんのアプリを試すユーザーが増え、見つかった問題が報告される可能性があります。
互換性テストをするには、Android 13 ベータ版を実行しているデバイスかエミュレータに、Google Play などのソースで公開しているアプリをインストールし、アプリのフローをすべて試します。特に注意してテストをするべき点については、動作の変更点を確認してください。見つかった問題を解決できたら、できる限り早くアップデートを公開しましょう。
ベータ版を公開したことで、2022 年 6 月の Platform Stability に近づいています。その時点で、アプリに関連するシステムの動作、SDK/NDK の API、非 SDK リストが確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリをリリースしてください。デベロッパー向けのタイムラインの詳細は、こちらをご覧ください。
ベータ版 のリリースには、Android 13 の機能を試し、アプリをテストしてフィードバックを提供するために必要なすべてのものが含まれています。こちら (英語) からサポート対象の Pixel デバイスを登録するだけで、今回と今後の Android 13 ベータ版やフィーチャー ドロップのベータ版アップデートを無線（OTA）で受け取ることができます。すでにデベロッパー プレビュー ビルドをインストールしている方は、自動的にアップデートを受け取ります。開発を始めるには、SDK をセットアップが必要です。
サポートされている端末で幅広くテストしたい場合は、Android GSI イメージ (英語) の Android 13 ベータ版をお試しください。デバイスをお持ちでない場合は、Android Studio の SDK Manager から最新のエミュレータ システム イメージをダウンロードするだけで、Android Emulator でテストできます。
ベータ版の入手方法の詳しい説明は、Android 13 デベロッパー サイトをご覧ください。
この記事は Android チーム による Android Developers Blog の記事 " Twitter going all in on Jetpack Compose for feature development: greater productivity, less bugs " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
最も広く使われているソーシャル メディア プラットフォームの 1 つである Twitter は、ユーザーとの繋がりを強化する方法を常に探っています。同時に、既存の機能を維持しつつ効率よく新機能を構築するには、デベロッパーをサポートするインフラストラクチャも必要です。Twitter のエンジニアリング チームは、急務だったアプリの UI 基盤のオーバーホール作業に着手するにあたり、Jetpack Compose に注目しました。Compose を使うデベロッパーは、適切な API を簡単に見つけて使うことができます。また、柔軟にコンポーネントのスタイルを設定したり、コンポーネントをモジュール化したりできるので、最終的に少ないコードで多くのことを実現できます。
Android クライアント UI チーム、顧客獲得チーム、Twitter Blue チーム、コミュニティ チームなど、いくつかのチームが開発プロセスを刷新し、Twitter のエンジニアたちはそれに注目しました。「Twitter の複数のチームは、すでに Compose を日常のワークフローに採用しています」と、Twitter のシニア ソフトウェア エンジニアであり、Android アプリでコミュニティ チームのテクニカル リードを務める Sneha Patil 氏は語ります。Compose では、カスタムのテーマや属性の作成や設定作業は不要なので、ビューの場合よりも機能の記述やデザイン要件の実装をかなりすばやく簡単に行うことができます。Jetpack Compose を使うことで、各チームの作業時間が短縮され、効率が上がります。さらに、コードの再利用性が向上し、新しいエンジニアも作業に加わりやすくなります。
Compose では、簡単に動的コンテンツを生成できます。Twitter チームは、Adapter や ViewHolder を使わずに、LazyColumn コンポーザブルで UI を構築しました。それにより、コードの記述プロセスがシンプルになり、レイアウト、テーマ、スタイルをシームレスに動作することができます。記述するコードの行数が減ったことで、Twitter の開発チームはボイラープレートを削減し、開発やリリースの際のバグを減らすことができました。また、UI の実験が可能になり、テストプロセスがスピードアップしました。こういった改善によって生産性が高まったので、デベロッパーは Twitter ならではの機能の開発に時間をかけられるようになりました。
また、Compose を使って、複数のアプリで再利用できるステートレスなコンポーネントの開発も行われています。Compose は柔軟なので、デザイン要件をすばやく簡単に満たすことができ、新しいエンジニアでも経験を積んだエンジニアでも、簡単にテーマやスタイルを設定できます。
このような改善体験を受けて、Twitter は新機能をすべて Compose で開発することにしました。そして、Compose を使ってゼロからコミュニティ機能（ユーザーが興味のあることをディスカッションできる Twitter の専用スペース）を開発しました。これまでビューを使った他の機能の開発で積んできた経験に基づいて Compose で開発したところ、作業時間を大幅に短縮でき、バグも少なくなりました。 「まるで魔法のようでした」と Patil 氏は話します。「Compose は、Android での開発方法を変えるゲーム チェンジャーです」
Compose によって、Twitter エンジニアの UI 開発のスピードと効率が飛躍的に向上しました。デベロッパーは、簡単に Compose を組み込んで開発することができました。そのため、コードのモジュール化、コンポーネントの再利用、依存関係の解消が簡単になり、定期的に UI の実験ができるようになりました。さらに、Compose を使えば、ユーザーの操作、データの更新、異なる画面サイズに反応するコンポーネントが実際の環境でどのように見えるかがわかるので、安心感も深まりました。
各チームが最初にこのような成功を収めたことで、Twitter の他の開発チームも Compose を採用するようになりました。今では、複雑なレガシー コンポーネントを扱うエンジニアでさえ、Compose の採用を検討しています。
最終的に、Compose の導入によって、ビューを使っていたときに生じていた多くの問題を解消できただけでなく、ワークフローに楽しさがもたらされることにもなりました。一部のデベロッパーは、すでに古い手法をこの優れた手法に置き換えようとしています。「Compose で書くのが楽しみです。もう XML レイアウトを触ることはないでしょう。UI 開発が簡単になるだけでなく、楽しく、直感的になります」と、Twitter の Android クライアント UI ソフトウェア エンジニア、Yoali Sotomayor Baqueiro 氏は語りました。
UI 開発を Compose で最適化しましょう！
この記事は #TheAndroidShow 共同司会、Florina Muntenescu、Huyen Tue Dao による Android Developers Blog の記事 " Happening now! #TheAndroidShow: Tablets, Jetpack Compose & Android 13 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
※翻訳者注：本記事はライブ配信中 (2022 年 3 月 9 日) に投稿されたものです。日本語記事投稿時点では既にライブ配信が終了していることをご了承ください。
#TheAndroidShow の新しいエピソードを配信しましたので、ぜひご覧ください。このエピソードでは、Jetpack Compose と Android 13、そしてすべての Android タブレットのアップデートについて、その内側を紹介します。
※翻訳者注：当日のライブ配信では、Android タブレットについてどうしても聞きたいことがある方と、#AskAndroid を使って、専門家たちにリアルタイムでお答えいただく機会もありました。
今回の #TheAndroidShow では、まず Android の最新ネイティブ UI ツールキットである Jetpack Compose についてお話ししました。私たちは、2 月にJetpack Compose のバージョン 1.1 をリリースしました。このバージョンには、フォーカス処理の改善、タッチ ターゲットのサイズ設定、ImageVector のキャッシュ、Android 12 のストレッチ オーバースクロールのサポートといった新機能が含まれています。さらに、Compose 1.1 では、これまで試験運用版だったたくさんの API が安定版になっているほか、より新しいバージョンの Kotlin もサポートされています。今回の #TheAndroidShow では、アニメーション関係の開発に携わったエンジニア、Doris Liu と一緒に、アニメーションの世界の舞台裏に迫りました。その後、Compose を使って半分の時間で新機能を開発できるようになった Twitter から、その方法について話をうかがいました。
次に紹介したのは、タブレットの世界です。3 月初めには、大ニュースが届きました。12L フィーチャー ドロップが AOSP に正式リリースされ、3 月上旬から数週間のうちに、サポート対象のすべての Pixel デバイスにロールアウトされました。Android の大画面デバイスは、2.5 億台以上存在しています。12L には、アプリをドラッグ＆ドロップしてすばやく分割画面モードに切り替えることができる新しいタスクバー、通知シェードとロック画面の新しい大画面レイアウト、アプリの互換性モードの改善などのアップデートが含まれ、タブレットでの Android 12 がさらに改善されています。詳細については、こちら (英語) を参照してください。
12L は、今年中に行われるアップデートによって、Samsung、Lenovo、Microsoft のタブレットや折りたたみ式デバイスで利用できるようになる予定です。そのため、今のうちにアプリの準備を整えておくようにしましょう。さまざまなウィンドウ サイズの分割画面モードや異なる画面の向きでアプリをテストし、該当する場合は新しい互換性モードの変更点を確認することを強くおすすめします。デベロッパー向けの 12L の説明は、こちら (英語) をご覧ください。
私たちは、大画面機能を Android の将来にとって重要な機能と位置付けています。そのため、皆さんがタブレットや Chromebook、折りたたみ式デバイスで優れたエクスペリエンスを構築するために必要になるツールを提供できるように、今後も注力を続けます。詳細については、大画面向けの最適化を始める方法や、大画面デベロッパー リソースをご覧ください。
最後のまとめとして、Android デベロッパー リレーションズのディレクター、Maru Ahues Bouza から話を聞きました。Android 13 のことに加え、今年の Android に関する幅広い話題が登場しました。
すべての内容は、現在配信中の #TheAndroidShow でご覧いただけます。ぜひ YouTube (英語) にアクセスしてください！
サイバーエージェントは、コンバージョン率向上に向け、ユーザー評価の重要性に着目し、『IDOLY PRIDE』に Google Play In-App Review API を実装しました。これによりユーザーがゲームから離脱せず、ゲーム内でレビューが投稿できるようになったため、レビュー投稿へのハードルが軽減されました。また、サイバーエージェントは、よりレビューの数を増やすために、満足度が高いタイミング (最高レア確定補助チケットを初めて利用した直後など) にゲーム内でレビューを促すといった工夫も行っています。
「Google の In-App Review API は、私たちのゲームに対するユーザーからの意見と向き合う機会を与えてくれる便利なツールです。レビューやフィードバックの量が増えることで、ユーザーの好みを知り、よりユーザー満足度の高いゲームにしていく方法の一つとして有用だと思います」
株式会社サイバーエージェント QualiArts マーケティング責任者 木村 泰之 氏
サイバーエージェントは、ゲーム中の特定のタイミングでユーザーにレビューの投稿を促すことにより、ゲーム全体に対するポジティブなレビュー数の増加を達成することができました。また、いつ、どのようなレビューに返信するべきかというルールを設定し、個々のレビューに対して真摯な返信対応をすることで、『IDOLY PRIDE』は、過去 1 年間、アプリ評価を平均 4.0 以上に保ち、Google Play ストアのアプリ詳細ページでの高いコンバージョン率を達成しました。
Google Play In-App Review API の詳細については、こちらをご覧ください。
Written by Toru Shimazaki - Google Play, Partner Development Manager
この記事は Lauren Mytton による Android Developers Blog の記事 " Access Android vitals data through the new Play Developer Reporting API " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
品質は、Google Play でゲームやアプリが成功するための土台です。そして、Google Play Console の Android Vitals は、アプリのパフォーマンスをトラッキングする優れた方法です。実際、上位 1,000 デベロッパーの 80% 以上が、少なくとも月に 1 度は Android Vitals をチェックし、技術的品質のモニタリングやトラブルシューティングに役立てています。毎日チェックしているデベロッパーも少なくありません。
Google Play Console の Android Vitals の概要では、アプリやゲームの品質を一目で把握できます。しかし、Google Play Console 以外の場所からも Android Vitals データを扱いたいという要望が多くのデベロッパーから寄せられています。考えられるユースケースには、以下のようなものがあります。
2022 年 3 月 22 日より、新しい Google Play Developer Reporting API（英語） を使って、こういったユースケースを実現できるようになりました。
Google Play Developer Reporting API を使うと、Google Play Console 以外の場所で、デベロッパー アカウントからアプリレベルのデータを扱うことができます。今回の初回リリースでは、安定性と電池に関連する 4 つのコア Android Vitals 指標（クラッシュ発生率、ANR 発生率、過剰なウェイクアップの発生率、停止したバックグラウンド ウェイクロックの発生率）に加え、クラッシュと ANR に関連する問題とスタックトレースにアクセスできます。また、異常値、内訳（Android Vitals の新しい国フィルタも含む）、3 年間の指標の履歴も確認できます。
新しい Google Play Developer Reporting API へのアクセス設定は、Google Play Console の [API アクセス] ページから行う
API を有効化できるのは、Google Play Console デベロッパー アカウントのオーナーのみです。オーナーは、Google Play Console の [API アクセス] ページから数分でアクセスを設定できます。使い始めるうえで知っておくべきことは、すべてドキュメント（英語）に記載されています。
API ドキュメントには、サンプル リクエスト（英語）や公開されているエンドポイント（英語）の一覧が掲載されています（アルファ版とベータ版の両方について記載されています）。
API を有効化できたら、複雑なソリューションの実装に入る前に、手動でリクエストを送ってみましょう。そうすることで、API のリソースや操作についての感覚をつかむことができます。また、処理するデータ量によってクエリ時間が異なるので、それを確認するうえでも役立ちます。長期間を対象にしたクエリ、多くのディメンションにまたがるクエリ、巨大なアプリに対するクエリには、長い時間がかかります。
ほとんどの指標セットは、1 日に 1 回更新されます。リソースやリクエスト割り当てを無駄にすることがないように、提供されている手法を使ってデータが新しいかどうかをチェックし、新しいデータが利用できるようになっていることを確認してから、実際のクエリを発行することをおすすめします。
この機能をリクエストしてくださったすべてのデベロッパーの皆さん、どうもありがとうございます。この機能が、これからも皆さんのアプリやゲームの改善に役立つことを願っています。Android Vitals と Google Play Developer Reporting API についてもっと詳しく知りたい方は、Google for Games Developer Summit で私たちが発表したセッションをご覧ください。
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は Manuel Vivo による Android Developers - Medium の記事 " Migrating Architecture Blueprints to Jetpack Compose " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリ アーキテクチャ ガイドを最新化する作業の一環として、異なる UI パターンを使って実験し、最適に動作する方式や各方式間の類似点や相違点を確認して、最終的にはそこから得られた教訓をベスト プラクティスとしてまとめたいと考えています。
そこで発見したことをできる限り容易に理解していただくには、おなじみのビジネスケースを扱う複雑すぎないサンプルが必要でした。そう考えると、最適な題材は TODO アプリでしょう。そこで、アーキテクチャ ブループリントを選択しました。これまで、このブループリントは、アーキテクチャを選択する際の実験場として使われてきました。この点でも、まさにうってつけだと言えるでしょう。
実際のアーキテクチャ ブループリント アプリ
今回試したいパターンは、現在利用できるさまざまな API から明らかな影響を受けています。今回の新入りは、Jetpack Compose の State API です。Compose は、どんな単方向データフローともシームレスに連携できるので、UI のレンダリングに Compose を使うことで、公正な比較ができるようにします。
このブログ投稿では、どのようにしてアーキテクチャ ブループリントを Jetpack Compose に移行したかをお伝えします。LiveData もこの実験の代替手段と考えることができるので、このサンプルは移行時の状態のままにしています。今回のリファクタリングでは、ViewModel クラスとデータレイヤーには手を加えませんでした。
⚠️ この LiveData ベースのコードベースで使ったアーキテクチャは、最新のアーキテクチャ ベスト プラクティスに完全に従ってはいません。特に、LiveData はデータレイヤーやドメイン レイヤーで使うべきではありません。代わりにフローやコルーチンを使うようにしてください。
背景が明らかになったので、ブループリントを Jetpack Compose にリファクタリングした手法の説明に入りましょう。完全なコードは、dev-compose ブランチで確認できます。
提案された変更点が全員の共通認識となるように、実際 のコーディング作業を始める前に、移行計画を作成しました。最終的な目的は、ブループリントを単一アクティビティ アプリにすることです。その際に、画面はコンポーズ可能な関数にして、画面間の移動には推奨の Compose Navigation ライブラリを使います。
ありがたいことに、ブループリントはすでに単一アクティビティ アプリになっており、Jetpack Navigation を使ってフラグメントで実装された画面間を移動しています。これを、Navigation の相互運用性ガイドに従いながら、Compose に移行します。このガイドで推奨されているのは、フラグメントベースの Navigation コンポーネントを使うハイブリッド アプリです。そこでフラグメントを使い、ビューベースの画面、Compose の画面、ビューと Compose の両方を使う画面を格納します。残念ながら、同じナビゲーション グラフでフラグメントと Compose の遷移先を混在することはできません。
段階的移行の目的は、コードレビューを簡単にし、移行の全段階でプロダクトが公開できる状態を維持することです。移行計画は、3 つのステップに分かれています。
これで完了です。🧑💻 ここで 2 週間早送り ⏩ します。この段階で、 統計 画面（PR）、 タスクの追加と編集 画面（PR）、 タスク詳細 画面（PR）、そして タスク一覧 画面（PR）の移行と、最終 PR のマージが完了しています。最終 PR は、未使用のビューシステムへの依存関係の削除を含め、ナビゲーションとアクティビティのロジックを Compose に移行したものです。
ブループリントを Compose に段階的に移行する方法
移行を進めるにあたり、Compose に特有ないくつかの動作に対応する必要がありました。その点について説明します。
アプリに Compose を追加すると、Compose UI を確認するテストには Compose テスト API が必要になります。
画面レベルの UI テストでは、launchFragmentInContainer<FragmentType> API の代わりに、テストの文字列リソースを取得できる createAndroidComposeRule<ComponentActivity> API を使いました。このようなテストは、Espresso でも Robolectric でも実行できます。Compose はすでにこの両方をサポートしているので、追加の変更は必要ありません。それを確認してみたい方は、移行前の AddEditTaskFragmentTest と移行後の AddEditTaskScreenTest のコードを比較してみてください。ComponentActivity を使う場合は、androidx.compose.ui:ui-test-manifest アーティファクトへの依存関係を追加する必要がある点に注意しましょう。
エンドツーエンド テストや結合テストには、何の問題もありませんでした。Espresso と Compose の相互運用性のおかげで、Espresso のアサーションでビューをチェックし、Compose API で Compose UI をチェックすることができます。Compose への移行作業中の AppNavigationTest はこちらです。
問題になったのは、ブループリントが ViewModel イベントを扱う方法でした。ブループリントはイベント ラッパー ソリューションを実装しており、それを使って ViewModel から UI に コマンド を送信していました。しかし、Compose ではこの仕組みは動作しません。最新のガイドでは、このような「イベント」を状態としてモデリングすることが推奨されています。そこで、移行の際に実施しました。
例として、 画面にメッセージを表示する というイベントのユースケースを取り上げます。ここでは、LiveData の Event<Int> 型を Int? に置き換えました。これは、ユーザーに表示するメッセージがない場合をモデリングすることにもなります。この特定のユースケースの ViewModel では、メッセージが表示される場合、必ず UI での確認操作も必要になります。次のコードは、両方の実装の差分です。
/* Copyright 2022 Google LLC. SPDX-License-Identifier: Apache-2.0 */class AddEditTaskViewModel( private val tasksRepository: TasksRepository) : ViewModel() {- private val _snackbarText = MutableLiveData<Event<Int>>()- val snackbarText: LiveData<Event<Int>> = _snackbarText+ private val _snackbarText = MutableLiveData<Int?>()+ val snackbarText: LiveData<Int?> = _snackbarText+ fun snackbarMessageShown() {+ _snackbarText.value = null+ }}
SPDX-License-Identifier: Apache-2.0 */
class AddEditTaskViewModel(
private val tasksRepository: TasksRepository
) : ViewModel() {
- private val _snackbarText = MutableLiveData<Event<Int>>()
- val snackbarText: LiveData<Event<Int>> = _snackbarText
+ private val _snackbarText = MutableLiveData<Int?>()
+ val snackbarText: LiveData<Int?> = _snackbarText
+ fun snackbarMessageShown() {
+ _snackbarText.value = null
+ }}
UI のコードでイベントが一度だけ処理されることを保証するには、event.getContentIfNotHandled() を呼び出します。このアプローチは、フラグメントでは うまくいきそう ですが、Compose では動作しません。Compose では、再コンポーズがいつ起きるかわからないので、イベント ラッパーは有効なソリューションではありません。イベントが処理されて関数が再コンポーズされると（このアプローチをテストする際に、よく起きる現象です）、スナックバーがキャンセルされるので、ユーザーはメッセージを見逃してしまうかもしれません。これは許容できない UX の問題です。Compose アプリでは、イベント ラッパー ソリューションを使うべきではありません。
次の 変更前 （イベント ラッパー）と 変更後 （状態としてのイベント）のコード スニペットをご覧ください。画面にメッセージを表示するのは UI ロジック であることと、この画面コンポーザブルが複雑になってきたことから、単純な状態ホルダークラスを使ってその複雑さに対処することにしました。その例として、次の AddEditTaskState をご覧ください。
Copyright 2022 Google LLC. SPDX-License-Identifier: Apache-2.0 */// FRAGMENTS CODE CONSUMING THE EVENT WRAPPER SOLUTION- class AddEditTaskFragment : Fragment() {- override fun onViewCreated(view: View, savedInstanceState: Bundle?) {- …- viewModel.snackbarText.observe(- lifecycleOwner,- Observer { event ->- event.getContentIfNotHandled()?.let {- showSnackbar(context.getString(it), Snackbar.LENGTH_SHORT)- }- }- )- }- } // COMPOSE CODE CONSUMING USER MESSAGES AS STATE// State holder for the AddEditTask composable.// This class handles AddEditTask's UI elements' state and UI logic.+ class AddEditTaskState(...) {+ init {+ // Listen for snackbar messages+ viewModel.snackbarText.observe(viewLifecycleOwner) { snackbarMessage ->+ if (snackbarMessage != null) {+ // If there's a previous message showing on the screen+ // stop showing it in favor of the new one to be displayed+ currentSnackbarJob?.cancel()+ val snackbarText = context.getString(snackbarMessage)+ currentSnackbarJob = coroutineScope.launch {+ scaffoldState.snackbarHostState.showSnackbar(snackbarText)+ viewModel.snackbarMessageShown()+ }+ }+ }+ }
// FRAGMENTS CODE CONSUMING THE EVENT WRAPPER SOLUTION
- class AddEditTaskFragment : Fragment() {
- override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
- …
- viewModel.snackbarText.observe(
- lifecycleOwner,
- Observer { event ->
- event.getContentIfNotHandled()?.let {
- showSnackbar(context.getString(it), Snackbar.LENGTH_SHORT)
- }
- )
// COMPOSE CODE CONSUMING USER MESSAGES AS STATE
// State holder for the AddEditTask composable.
// This class handles AddEditTask's UI elements' state and UI logic.
+ class AddEditTaskState(...) {
+ init {
+ // Listen for snackbar messages
+ viewModel.snackbarText.observe(viewLifecycleOwner) { snackbarMessage ->
+ if (snackbarMessage != null) {
+ // If there's a previous message showing on the screen
+ // stop showing it in favor of the new one to be displayed
+ currentSnackbarJob?.cancel()
+ val snackbarText = context.getString(snackbarMessage)
+ currentSnackbarJob = coroutineScope.launch {
+ scaffoldState.snackbarHostState.showSnackbar(snackbarText)
+ viewModel.snackbarMessageShown()
+ }
リファクタリングをしていると、そこにあるものを すべて Compose に移行したくなってしまうかもしれません。それでもまったく問題はありませんが、アプリのユーザー エクスペリエンスや「正しさ」を犠牲にすべきではありません。段階的に移行する重要な理由は、アプリを公開できる状態を保ち続けることにあります。
私たちのチームでそれが起きたのは、一部の画面を Compose に移行しているときです。同時にたくさんの移行をしたくはなかったので、一部の画面を Compose に移行 してから 、イベント ラッパーを移行しました。Compose でイベント ラッパーを扱って最善でないエクスペリエンスを提供することは避け、他の画面のコードを Compose に移した後も、このメッセージはフラグメントで処理し続けました。例として、移行中の TasksFragment の状態をご覧ください。
すべてが想定どおり順調に進んだわけではありません。🫤 フラグメントの内容を Compose に変換するのは簡単でしたが、ナビゲーション フラグメントを Navigation Compose に移行する作業には、多少の時間と検討が必要でした。
今後の Compose への移行を簡単にするさまざまな側面について、ガイドの拡張や改善が必要となります。今回の作業をきっかけに議論が始まったので、近日中に新しいガイドができることを期待しています！🎊
私はナビゲーションについてあまり詳しくない ✋ 状態で Navigation Compose への移行を担当しましたが、次のような問題点に直面することになりました。
ナビゲーション フラグメントから Navigation Compose への移行は楽しい作業でした。おかしなことに、プロジェクトの移行自体よりも、ピアレビューの待ち時間の方が長くなりました。移行計画を作成したことと、全員の共通認識を合わせたことで、早い段階で期待する内容を定め、長いレビューが待っていることを知らせることもできました。
今回紹介した Compose への移行の手法が皆さんの役に立つことを期待しています。また、アーキテクチャ ブループリントで今後行う予定の実験や改善についても、さらにお伝えしたいと思っていますので、ご期待ください。
Compose コードを含むブループリントを見てみたい方は、dev-compose ブランチをご覧ください。また、段階的移行の PR を順番に確認したい方のために、一覧を記載します。
👋
2022 年 6 月 15 日 (水) 、16 日 (木) の 2 日間に渡って「Android Roadshow」を開催いたします。
Android 開発者の皆様に楽しんでいただけるよう Day 1、Day 2 でそれぞれ異なる内容をご用意しております。
参加人数に制限を設けておりませんので、お誘い合わせの上ご参加ください。
2022 年 6 月 15 日 (水) 10:00 - 12:00
参加登録はこちら
Day 1 では、5 月 11 日 - 12 日に開催した Google I/O 2022 の発表内容から、アプリ開発の技術戦略を各社でご検討される上で今後重要になってくる話題について、日本語字幕つき英語動画と、日本側の関係者による対談を通じてご紹介いたします。
今年の Google I/O の発表のうち、Android アプリ開発者に特にご注目いただきたいのは「Jetpack Compose」「大画面対応」「Android 13」「Wear OS」の 4 つの話題です。
今回のイベントの内容はどちらかというとゲームではないアプリの開発者向けの構成となっておりますが、大画面対応や Android 13 の話題は今後ゲームにも関連が深く、また開発現場での対応ノウハウなど業種が違ってもお役立ていただけそうな情報もあるかと思いますので、ゲームアプリの開発会社様もご興味のある箇所についてご視聴いただけますと幸いです。
2022 年 6 月 16 日 (木) 16:00 - 17:30
本イベントでは 2022 年 3 月 15 日（日本時間 3 月 16 日）に開催したゲームデベロッパー様向けイベント 「Google for Games Developer Summit 2022 」の発表内容から、ゲーム開発の技術戦略を各社でご検討される上で、特に重要になってくる話題について、日本語字幕付き英語動画と、日本側の関係者による対談を通じてご紹介いたします。
今回の発表のうち、Android アプリ開発者に特にご注目いただきたいのは「エコシステム関連のアップデート」「多画面対応のゲーム」「高品質の Android ゲーム開発」「成長支援ツール」の 4 つの話題です。
ぜひこの機会に最新動向を把握しましょう。たくさんの方に楽しんでご覧いただけるよう準備をしておりますので、皆さまお誘い合わせの上、ご参加ください。
Written by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は Max Bires による Android Developers Blog の記事 " Upgrading Android Attestation: Remote Provisioning " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
構成証明の機能は、Android 8.0 より必須となっています。リリースが重ねられるにつれて、構成証明は、ますます多くの機能やサービスの信頼性の中核となっています。その例として、SafetyNet や Identity Credential、Digital Car Key、そしてさまざまなサードパーティ ライブラリなどが挙げられます。従って、信頼チェーンのセキュリティを強化して、既知の脆弱性があったとしてもデバイスの信頼性を回復しやすくするために、このタイミングで構成証明インフラストラクチャを見直すべきです。
Android 12.0 より、出荷時の秘密鍵プロビジョニングを置換するオプションを提供する予定です。これは、出荷時の公開鍵の抽出と、Short-Lived 証明書の無線（OTA）プロビジョニングを組み合わせて実現します。この仕組みは、Android 13.0 で必須になる予定です。この新しい仕組みを、リモート鍵プロビジョニングと呼びます。
デバイス メーカーが、工場で直接デバイスに構成証明秘密鍵をプロビジョニングすることはなくなります。そのため、工場で構成証明の秘密鍵を管理する負担が取り除かれます。
後ほど詳しく説明しますが、構成証明の証明書チェーンの形式、アルゴリズム、長さが変わります。リライング パーティが、以前の証明書チェーン構造と完全に一致するよう証明書検証コードを設定している場合、そのコードを更新する必要があります。
構成証明書のデバイスへのプロビジョニング方法を変更する目的は主に 2 つあります。それは、デバイスが侵害された際の回復と、構成証明サプライ チェーンの強化です。現在の構成証明の仕組みでは、構成証明の信頼性シグナルに影響を与えるような形でデバイスのモデルが侵害された場合や、なんらかのメカニズムを介して鍵が漏洩した場合、鍵を取り消す必要があります。構成証明の鍵シグナルを利用するサービスが増加しているため、影響を受けるデバイスを使っているユーザーへの影響も大きくなる可能性があります。
今回の変更により、侵害されたことがわかっているソフトウェアを搭載したデバイスへのプロビジョニングを停止し、鍵が意図せずに漏洩する可能性をなくすことができます。そのため、ユーザーがサービスを使えなくなる可能性が大幅に減ります。
デバイスごとに、一意の静的な鍵ペアが生成されます。OEM は、工場でこの鍵ペアの公開鍵の部分を抽出します。公開鍵は Google のサーバーにアップロードされ、後に行われるプロビジョニングの信頼性の土台となります。秘密鍵は、生成時の安全な環境を離れることはありません。
箱から出されたデバイスがインターネットに接続されると、生成された鍵の証明書署名リクエストが生成されます。このリクエストは、工場で収集された公開鍵に対応する秘密鍵で署名されます。バックエンド サーバーはリクエストの正当性を検証し、公開鍵に署名して証明書チェーンを返します。この証明書チェーンはキーストアに保存され、構成証明をリクエストしたアプリに割り当てられます。
このフローは、証明書の有効期限が切れた場合や、現在の鍵の供給が枯渇した場合に、定期的に実行されます。この仕組みでは、各アプリは異なる構成証明鍵を受け取り、鍵自身は定期的にローテーションされるので、プライバシーが保護されます。さらに、Google のバックエンド サーバーはセグメントが分割されており、デバイスの公開鍵を検証するサーバーからは、アタッチされている構成証明鍵は見えないようになっています。つまり、Google が構成証明鍵とそれをリクエストした特定のデバイスを結びつけることはできません。
エンドユーザーは、この変更に気づくことはないでしょう。構成証明を利用しているデベロッパーは、以下の変更点に注意してください。
この記事は Krish Vitaldevara による Android Developers Blog の記事 " Expanding Play’s Target Level API Requirements to Strengthen User Security " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
デベロッパー コミュニティは、Google Play を通して、革新的で信頼できる世界最高レベルのアプリを数十億人に配布しています。これは継続的なプロセスであり、エコシステム全体でアプリの安全性を向上する取り組みは絶え間なく続いています。
ユーザーに安全なエクスペリエンスを提供するうえで核となるのは、Google Play の機能とポリシーです。それに加えて、毎回の Android OS のアップデートでも、プライバシー、セキュリティ、ユーザー エクスペリエンスの改善が行われています。ユーザーがこのような改善をすべて実感できるよう、Google Play に期待される信頼性の高いエクスペリエンスを維持するため、私たちはデベロッパーの皆さんとともに、新しい Android バージョンでもアプリがシームレスに動作するようにしています。
現在、新規アプリ、および、アプリのアップデートでは、最新のメジャー Android OS バージョンのリリース後 1 年以内に、その Android API レベルを対象にすることが義務づけられています。新規アプリやアプリのアップデートがこの要件を満たさない場合、Google Play で公開することはできません。厳密なスケジュールを確認したい方は、こちらのヘルプセンターの記事をご覧ください。
現在の新規アプリとアプリ更新のターゲット API レベル要件
2022 年 4 月 6 日、Google Play の最新のポリシー更新 の一環として、さらなる手段を講じることをお知らせしました。具体的には、ユーザーが最新のプライバシー機能やセキュリティ機能を搭載していない可能性があるアプリをインストールしてしまうことがないように、ターゲット API レベルの要件を追加します。
2022 年 11 月 1 日より、既存アプリは、最新のメジャー Android バージョンがリリースされた後、2 年以内に ターゲット API レベルにする必要があります。これをしない場合、既存アプリのターゲット API レベルより新しい Android OS バージョンを実行しているデバイスの新規ユーザーは、そのアプリを検索したり、インストールができなくなります。今後、新しい Android OS バージョンがリリースされると、要件の範囲もそれに応じて変わります。
11 月 1 日以降の既存アプリのターゲット API レベル要件
この変更の理由は簡単です。最新のデバイスを使っているユーザーや、すべての Android アップデートを適用しているユーザーは、Android が提供するすべてのプライバシーやセキュリティ保護を最大限に活用できると考えています。今回のターゲット API レベルの 要件を追加することで、保護が含まれていない可能性がある古いアプリがインストールされることを防ぎます。
朗報なのは、Google Play の大半のアプリがすでにこの基準を満たしていることです。そうでないアプリは、特に注意する必要があります。かなり早い段階でデベロッパーの皆さんにお知らせしているのはそのためで、必要なリソースも提供します。
デベロッパーの皆さんには、以下の対応をおすすめします。
Google Play で古いアプリをすでにインストールしている現在のユーザーは、そのアプリがサポートしている任意の Android OS バージョンが搭載されたすべてのデバイスで、引き続きそのアプリを検索、再インストール、使用が可能です。
2022 年 4 月 6 日にお知らせするポリシー更新は、ユーザーの保護と Google Play のユーザー エクスペリエンスを強化するためのものです。ターゲット レベル API ポリシーの厳格化は、その中の 1 つに過ぎません。この重要な作業の目的は、アプリの全般的なプライバシーやセキュリティ水準を上げ、Google Play や Android を誰にとっても安全なものにすることです。この件についての最新情報は、今後も継続的にお伝えします。
この記事は Mauricio Vergara と Thousand Ant（協力） による Android Developers Blog の記事 "How a single Android developer improved Lyft’s Drivers app startup time by 21% in one month" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Lyft は、優れたアプリの開発に特に注力しています。数千万人の乗客と数十万人のドライバに一刻を争う重要なサービスを提供するライドシェア企業には、どうしても欠かせません。このような規模のアプリで、パフォーマンス低下やフレームのフリーズ、クラッシュが発生すると、たくさんのユーザーの時間が無駄になる可能性があります。ちょっとした問題があるだけでも、多くの乗客やドライバが競合他社に流れる原因になりかねません。幸いにも、Lyft の開発チームは、アプリのパフォーマンスに常に目を光らせています。最初にドライバ向けの Android アプリの起動が遅いという問題に気づいたのは、そのためでした。
問題の原因をすばやく突き止め、解決方法を探して、その対応の必然性を上層部に納得してもらう必要がありました。そのためには、たくさんの難問を解かなければなりません。ボトルネックはどこにあるのでしょうか？ユーザー エクスペリエンスにどのように影響しているのでしょうか？また、どの程度の優先順位で対応すべきでしょうか？ありがたいことに、このチームには強力なツールがあり、それが答えを見つける際に役立ちました。Android vitals は、Android デバイスでアプリの安定性とパフォーマンスの向上することを目的とした Google Play のツールです。チームはこのツールの助けを借り、問題を特定して対応を優先することを上層部に説明し、適切な専任リソースを投入して解決することができました。その経過について説明しましょう。
Lyft の開発チームが最初に行わなければならなかったのは、上層部に依頼して専任のリソースを割り当ててもらうほど切迫した問題であるかどうかを判断することでした。どんなアプリの品質改善提案でも同じですが、Lyft Driver の起動時間改善でも同様に、開発リソースへのその他の需要（プロダクトへの新機能の導入、アーキテクチャの改善、データ サイエンスの強化など）との間で優先順位を検討する必要がありました。通常、上層部を説得してアプリの品質改善に投資してもらう場合、難しいことの 1 つに挙げられるのが、パフォーマンスの改善とビジネス指標を相関付けることです。
チームは、Android vitals を使ってこの問題による危険性の全容を正確に把握しました。デベロッパーは、Android vitals からアプリのパフォーマンスを表すデータにアクセスできます。これには、アプリの無応答エラー、電池の枯渇、レンダリング、アプリの起動時間などが含まれます。それぞれの指標について、現在のパフォーマンスとパフォーマンスの履歴が実機でトラッキングされ、それを同じカテゴリ内の他のアプリと比較することもできます。開発チームは、この強力なツールの助けを借りて、Lyft Driver アプリの起動時間が同じカテゴリの他の 10 個のアプリと比べて 15～20% 遅かったことを発見しました。これは切迫した問題です。
次に必要だったのは、プロジェクトの適切なスコープを定めることでした。つまり、このパフォーマンス低下がビジネスの目的やユーザー エクスペリエンスに与える影響に見合ったスコープを定めるということです。Android vitals のデータから、問題は明らかでした。ライドシェア業界の競合他社と直接比較していることを考えれば、なおさらです。開発チームは、1 人のデベロッパーが 1 か月作業すれば、アプリの起動時間を十分に改善できると見積もりました。
開発チームは、この充実したデータを活用して上層部に説明し、Lyft が優れたアプリ体験を重視していることを訴えました。明らかにカスタマー エクスペリエンスを改善できるチャンスがあることを示し、適切なスコープと実現可能な目標、そして明確な競合の情報を提示したことで、上層部の許可を得ることができました。
Lyft が主に起動時間の指標として活用したのは、「操作できるようになるまでの時間」です（完全表示までの時間とも呼ばれています）。これに影響する要因を把握するため、Lyft のチームはアプリの起動ステージごとにプロファイリングし、問題点を探しました。Lyft Driver アプリの起動処理は、4 つのステージに分かれています。1）最初に、アプリのプロセスが起動します。2）“Activity” が UI のレンダリングを開始します。3）“Bootstrap” がネットワーク リクエストを送信し、ホーム画面のレンダリングに必要なデータを取得します。4）最後に、“Display” がドライバのインターフェースを開きます。徹底したプロファイリングにより、パフォーマンスの低下は 3 番目の Bootstrap フェーズで起きていることがわかりました。ボトルネックが特定できたので、それを解消するために、いくつかの段階を踏むことになりました。
最初に、重要な起動パスから不要なネットワーク呼び出しを削除しました。バックエンド サービスを分割することで、ネットワーク呼び出しの一部を完全に、かつ安全に起動パスの外に出すことができました。また、できる限り、ネットワーク呼び出しは非同期的に行うようにしました。アプリの動作には必要なものの、起動時に必要ないデータは、それがなくても起動処理が進むように、ノンブロッキングで呼び出すようにしました。ブロックを伴うネットワーク呼び出しは、安全にバックグラウンドに移動することができました。さらに、セッション間でデータをキャッシュするようにしました。
比較的小さな変更のように聞こえるかもしれませんが、結果的にアプリの起動時間がなんと 21% も高速になりました。そして、Lyft Driver のドライバのセッション数は、5% 増加しました。この実績により、チームは上層部からの確かな信頼を得て、モバイル パフォーマンスに特化した一連の作業フローを作成し、改善作業の過程で 1 人のエンジニアを追加しました。この取り組みが成功したことで、全社の注目が集まり、アプリの品質をさらに向上しようと考える数人のマネージャーから連絡が入りました。
成功につながった一連の作業には、どんな組織にも当てはまる大きな教訓が含まれています。
アプリの成長とともにチームの規模が大きくなると、質の高いアプリを保つことがそれまで以上に重要になります。多くの場合、最初にパフォーマンスの問題を見つけるのは、アプリの細かい部分に注目するデベロッパーです。しかし、デベロッパーは、組織全体に問題提起するのは難しいと考えてしまいがちです。Android vitals は、それを行う強力なツールです。デベロッパーが気づいたことについて、シンプルな形でデータとして証拠を示してくれるので、パフォーマンス指標とビジネスに及ぼす影響との関連を説明しやすくなります。
アプリの品質改善作業を始めるときは、まずは小さな成功を目指し、その上に実績を積み上げるとよいでしょう。適切なリソースを投入することで大きな成果につながる実現可能なプロジェクトを慎重に選びましょう。
また、ほとんどの場合、早めにかつ頻繁に相談して、組織全体を開発チームの品質改善作業に巻き込むことも重要です。目標、計画、結果を継続的に更新し続けることが、チーム全体の協力を維持するうえで役立ちます。
Android エコシステムには、アプリの起動時間や全般的なパフォーマンスについて理解して改善するためのツールが数多く存在しています。Android vitals は、そのようなツールの 1 つでしかありません。もう 1 つの補完的なツールが、Jetpack Macrobenchmark です。これを使うと、開発やテストの際に、さまざまな指標に関する知見を得ることができます。Android vitals はユーザーの実機からデータを取得しますが、Macrobenchmark では、コードの一部分のみに限定したベンチマーク評価やテストを行うことができます。アプリの起動時間のベンチマーク評価やテストも可能です。
Jetpack App Startup ライブラリ（英語）は、アプリの起動時に、コンポーネントをシンプルかつ効率的に初期化します。このライブラリを使うと、起動シーケンスを効率化したり、初期化の順序を明示的に指定したりできます。また、リーチとデバイスを活用すると、ユーザーや問題の分布を把握し、開発対象とするスペック、リリースする場所、テストの内容などについての意思決定に役立てることができます。このツールのデータがあれば、品質改善作業の優先順位をつけたり、多くのユーザーに最大限の影響を与えることができる改善内容を判断したりできます。Perfetto (英語) も貴重なアセットの 1 つです。これはオープンソースのシステム トレースツールで、コードのインストルメンテーションや起動時の問題を診断します。ここで紹介したツールを併用すれば、アプリをスムーズに動作して、ユーザーを満足させ続けることができるほか、組織全体が品質改善作業をサポートするようになるでしょう。
自分のチームでも質の高いアプリを追求する取り組みを進めたい（または Lyft に入社したい）と思った方は、プロダクトのオーナーや経営者向けに凝縮したケーススタディをご覧ください。こちら（英語）のリンクから参照できます。
この記事は Jose Alcérreca による Android Developers Blog の記事 "Write better tests with the new testing guidance" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリの機能と複雑さが増すにつれて、手動でアプリをテストして動作を検証するのは、退屈な作業になったり、高価な費用がかかったり、不可能になったりしています。最近のアプリでは、たとえ簡単なものであっても、UI フロー、ローカライズ、データベース移行など、確認しなければならないテストポイントは増える一方です。手動でアプリの動作検証を行う QA チームを設けるのも 1 つの選択肢ですが、その段階でバグを修正すると、高いコストがかかります。問題を修正するのは、開発プロセスの早い段階であるほどよいのです。
早い段階でバグを見つけるアプローチとして最も優れているのは、テストの自動化です。自動テスト（以降は テストと記述します）は幅広い領域です。Android では、たくさんのツールやライブラリが提供されているので、機能が重複する可能性があります。そのため、初心者はテストが難しいと思いがちです。
この意見に応え、Compose や新しいアーキテクチャ ガイドラインに対応するため、d.android.com のテストに関する 2 つのセクションを改訂しました。
まず、新しいテストのトレーニングを準備しました。ここには、Android でのテストの基本について、 2 つの新しい記事が含まれています。1 つは、初心者向けのガイドで、何をテストすべきか (英語) について説明します。もう 1 つは、テストダブル (英語) についての詳細ガイドです。
単体テストで依存関係を偽装する
概論を説明した後は、2 種類の主なテストの実例を中心に解説します。（以下、全て英語）
UI テストで依存関係を偽装する
次に、Android Studio からコマンドラインによるテストまで、テストの作成や実行に役立つあらゆるツールに重点を置いて、テストのツールに関するセクションを更新しました。
統合 Gradle テストランナー
異なるバリアントを扱う方法、インストルメンテーション マニフェスト オプション、Android Gradle プラグインの設定など、高度なテストの設定機能を説明した記事も含めています。
この 2 つのセクションから、Android アプリでどうテストすればよいのか、どこをテストすればよいのかについて、一般的な知識を得ることができるはずです。テスト固有の機能やライブラリの詳細については、それぞれのドキュメントのページをご覧ください。たとえば、Kotlin Flow のテスト、テスト ナビゲーション、Hilt テストガイドなどです。
残念ながら、ドキュメントの正確性を自動化による検証はできません。そのため、記述に誤りを見つけた方や提案がある方は、ドキュメント Issue Tracker でバグ報告を送信してください。
この記事は 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 に継続的に関心を寄せていただき、ありがとうございます。皆さんと共同で、ユーザーのためにすばらしいカメラ体験を作成できることが楽しみです。
.png)
.png.jpeg)
.png)
.png)
