この記事は 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 に入社したい）と思った方は、プロダクトのオーナーや経営者向けに凝縮したケーススタディをご覧ください。こちら（英語）のリンクから参照できます。
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は 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)
