この記事は 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
この記事は 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 に継続的に関心を寄せていただき、ありがとうございます。皆さんと共同で、ユーザーのためにすばらしいカメラ体験を作成できることが楽しみです。
この記事は 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 でお伝えしますので、ご注目ください。
2022 年 3 月 9 日にマンガアプリ カテゴリに特化した Google Play のカテゴリ イベント、マンガアプリ DAY を開催いたしました。近年マンガアプリを取り巻く環境は変化を続け、マンガアプリ自体も大きな進化を遂げています。 その中で、業界の活性化に貢献できるイベントをご提供できないかと考え、「コンテンツ戦略」をテーマの軸としイベントを実施しました。
この記事では、Google Play 担当者がイベント内で解説した「ゲーム手法から考えるコンテンツ戦略」というセッションの内容を一部ご紹介いたします。
一見マンガアプリとはあまり関係のなさそうなゲームですが、実はコンテンツ流通の最大化を目指す点などマンガアプリでも参考にできるような共通点があります。イベントでは、ゲームアプリで使われるコンテンツ戦略の考え方や手法を Google Play 担当者よりご紹介いたしました。
こういった形で、ゲームアプリは、コンテンツの需要を高めたり、それにまつわる通貨資産の管理を行っています。ゲームアプリとマンガアプリには類似点があることから、マンガアプリにも活用できるようなポイントがあるのではないでしょうか。
“ゲームの成功体験やメカニズムから、隣接であるマンガアプリの発展に結びつけようという企画が良かった”
“他のサービスにも展開しやすい形に噛み砕いていただいたので、各アプリでどう組み込んでいくかが考えやすいものになっていたと思いました”
このように、デベロッパーの皆さまが持続可能なビジネスを構築できるよう支援することは Google Play のミッションです。業界に特化したイベントを開催することで、業界の活性化や、デベロッパーの皆さまのビジネスをサポートすることを引き続き目指してまいります。
この記事の一部は、ココネ株式会社に寄稿いただいたゲスト記事です。
ココネ株式会社より「長年ユーザーに愛されるコンテンツやプロダクトに必要なサービス設計とは」をテーマに、お客様が愛着を持てる「世界設定」などサービス戦略についてお話しいただきました。この記事では、ココネ株式会社 冨田様・井出様より寄稿いただいたプレゼンテーションサマリーをご紹介します。
※ココネ株式会社
複数のアバターサービスを運営。アバターを武器に日本発のメタバースへ挑戦中の企業。『ポケコロ』は2021年で10周年、『リヴリーアイランド』はブラウザ版も含めると2022年で20周年など、長期間お客様に愛されるサービス運営に強みがあります。
はじめにココネが考えるサービス設計(思想)について。
次にサービス作りで大切にしている、世界設定・体験・つながりの 3要素について、『リヴリーアイランド』の事例を元に、お話しました。
アプリ内表現の例
実際のお買い物体験を目指したガチャ画面
“体験を変えていくことを考えるきっかけになりました”
“マンガアプリ以外での視点だったことが特に良かった。広い視野で改めてマンガアプリについて考えることができました”
この記事は Andrew Flynn & Jon Boekenoogen による Android Developers Blog の記事 " Play Time with Jetpack Compose " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2020 年、Google Play ストアのエンジニアリング チームのリーダー陣は、ストアのショーウィンドウにあたる部分全体の技術スタックを再構築するという大きな決断を下しました。既存のコードは 10 年以上前のもので、無数の Android プラットフォーム リリースや機能アップデートを経て、大きな技術的負債を抱えていました。デベロッパーの生産性やストア自体のユーザー エクスペリエンスとパフォーマンスに悪影響を与えることなく、数百名のエンジニアが開発できるようにスケールアップできる新しいフレームワークが必要でした。
ネットワーク レイヤからピクセルのレンダリングに至るまで、ストアのあらゆるものを更新するため、複数年にわたるロードマップを作成しました。その一環として、インタラクティブ性とユーザーの快適さを目標とした最新の宣言型 UI フレームワークも採用したいと考えました。さまざまな選択肢を分析した結果、まだアルファ版にもなっていなかった Jetpack Compose を使うという、(当時としては)大胆な決断をすることになりました。
それ以来、Google の Google Play ストアチームと Jetpack Compose チームは、ストアの具体的なニーズを満たせるバージョンの Jetpack Compose を実現するため、非常に密接な連携のもと、リリースや改善を重ねてきました。この記事では、移行のアプローチやその過程で明らかになった課題や利点について説明し、多くのエンジニアが関わるアプリで Compose を採用するとはどういうことかについて共有したいと思います。
新しい UI レンダリング レイヤとして Jetpack Compose を検討するときの最優先事項は次の 2 つでした。
Google Play ストアはすでに 1 年以上 Jetpack Compose で UI のコードを記述しており、Jetpack Compose によって UI 開発がこれまで以上にシンプルになっていることを実感しています。
特にうれしいのは、UI の記述に必要なコードがかなり減ったことで、場合によってはコードが最大 50% 少なくなったことです。これが実現できたのは、Compose が宣言型 UI フレームワークであることに加え、簡潔な Kotlin を活用できるからです。カスタムの描画やレイアウトを作成する際も、ビューをサブクラス化してたくさんのメソッドをオーバーライドする必要はなく、シンプルな関数呼び出しで実現できます。
評価テーブルを例に説明しましょう。
ビューを使う場合、このテーブルは以下の要素で構成されます。
Compose を使う場合、このテーブルは以下の要素で構成されます。
@Composable
「そうは言っても、ライブラリの依存関係でビューが提供される場合どうすればいいのか」と疑問に思う方もいらっしゃるかもしれません。たしかに、すべてのライブラリ所有者が Compose ベースの API を実装しているとは限りません。私たちが最初に移行をしたときは特にそうでした。しかし、Compose では ComposeView と AndroidView API によって、ビューを簡単に利用できる相互運用性が実現されています。ExoPlayer (英語) や YouTube の Player などの人気ライブラリは、この方法によって問題なく統合できました。
Google Play ストアチームと Jetpack Compose チームは、Compose がビュー フレームワークと同じくらい速くジャンクなしで動作できるようにするため、密接に連携しました。Compose は Android フレームワークの一部というよりはアプリにバンドルされるものなので、これは難しい要件でした。画面上の個々の UI コンポーネントのレンダリングは高速でしたが、アプリが Compose フレームワーク全体をメモリに読み込むために必要な時間をすべて合わせれば、かなりの時間になりました。
Google Play ストアで Compose を採用するうえで、特に大きなパフォーマンス改善に貢献したのはベースライン プロファイルの開発でした。以前から利用できたクラウド プロファイルもアプリの起動時間の短縮に役立ちますが、これが利用できるのは API 28 以降に限られ、頻繁な周期で(毎週)リリースされるアプリにとっては効果的ではありません。この問題に対応するため、Google Play ストアチームと Android チームが連携して、ベースライン プロファイルの開発にあたりました。ベースライン プロファイルは、デベロッパーが定義し、アプリの所有者が指定してバンドルできるプロファイルです。アプリに同梱され、クラウド プロファイルとは完全な互換性があり、アプリレベルに限定して定義することも、ライブラリレベルで定義することもできます(Compose を採用すると、このプロファイルもついてきます!)。ベースライン プロファイルをロールアウトすることで、Google Play ストアの検索結果ページの最初のレンダリング時間は 40% 短縮されました。これは大きな成果です。
Compose は、特にスクロールの際に効率的なレンダリングをします。その中核をなす仕組みとなっているのが、UI コンポーネントの再利用です。Compose は、スキップできることがわかっている Composable の再コンポーズをできる限りスキップしようとします(不変である場合など)。しかし、すべてのパラメータが @Stable (英語) アノテーション要件を満たしている場合は、デベロッパーが強制的に Composable をスキップ可能にすることもできます。Compose のコンパイラでも、特定の関数をスキップできない理由を説明した便利なガイドが提供されています。Google Play ストアでは、スクロールが発生する状況で頻繁に再利用される UI コンポーネントを作りましたが、不要な再コンポーズが積み重なってフレーム時間が足りなくなり、ジャンクにつながるという状況が発生しました。そこで、デバッグ設定でもそのような再コンポーズを簡単に見つけることができるように、Modifier を作成しました。この手法を UI コンポーネントに適用することで、ジャンクを 10-15% 減らすことができました。
@Stable
Modifier
Modifier による再コンポーズの視覚化の例。青(再コンポーズなし)、緑(1 回の再コンポーズ)
Google Play ストア アプリの Compose を最適化するうえで、もう 1 つの重要な要素となったのが、アプリ全体の一連の移行戦略を詳細に作成したことです。最初に組み込みの実験をしたとき、「二重スタック問題」に直面しました。これは、1 つのユーザー セッション内で Compose とビューの両方のレンダリングを実行すると、特にローエンドのデバイスにおいて、メモリに大きな負荷がかかるという問題です。これはコードを同じページに展開した場合だけでなく、異なるスタックのそれぞれに 2 つのページ(Google Play ストアのホームページと検索結果ページなど)が存在する場合にも発生しました。これに起因する起動の遅さを解消するには、ページを Compose に移行する順番やスケジュールについて、具体的な計画を立てることが重要でした。さらに、アプリが完全に移行されるまでの穴埋めとして、よく使うクラスの短期的なプリウォーミングを追加することも有用であることがわかりました。
Compose は Android フレームワークにバンドルされていないので、Google Play ストアチームが Jetpack Compose に直接的に関与する手間も少なくすみました。その結果、短い時間でデベロッパーに役立つ改善をすることができました。Jetpack Compose チームとの共同作業で、LazyList のアイテムタイプのキャッシュのような機能追加をしたり、無駄なオブジェクトの割り当てなどに関する簡単な修正をすばやくしたりすることもできました。
Google Play ストアで Compose を採用したことで、チームのデベロッパー満足度は大幅に上昇し、コードの品質と健全性も大きく向上しました。Google Play ストアの新機能は、すべてこのフレームワーク上に構築されています。Compose はアプリの速度向上や利便性に貢献しています。Compose への移行戦略の性質上、APK サイズの変化やビルド速度は細かく測定できませんでしたが、可視化できたものについてはすべて順調に進んでいます。
Compose は Android UI 開発の未来です。Google Play ストアの事例から言うと、これ以上すばらしいものはありません!
この記事は 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