この記事は Jeremy Walker による Android Developers Blog の記事 " Sharing Tiles with your smartwatch users: " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
タイル (英語) は、ウォッチフェイスのホーム画面をスワイプするだけで情報やアクションにすばやくアクセスする機能を提供いたします。これにより、スマートウォッチ ユーザーはどんな情報やアクションを表示するかを細かく制御できます。Wear OS を実行するスマートウォッチで、タイルが特に便利で役立つ機能の 1 つとなっていることも不思議ではないでしょう。
2021 年 8 月 11 日（日本時間 8 月 12 日）に、スマートウォッチ ユーザーとタイルを共有できることを発表いたしました。Jetpack Tiles API の最新のアルファ リリースをダウンロードすると、カスタムタイルを作成できます。作成したタイルを含むアプリを Google Play にアップロードすると、ユーザーはタイルをダウンロードして使い始めることができます。新しい体験を試せるようになったことをユーザーにもお知らせしましょう。Google Play Console で、Google Play ストアのプレビュー 用アセットにタイルのスクリーンショットをアップロードすることもできます。
Calm や 睡眠サイクル などのアプリは、既にカスタムタイルの作成を始めています。
「API はわかりやすく、ドキュメントもとても明確でした。そのため、わずか数時間で、実データを使って最初のタイルを動作させることができました。気軽に使ってみることができる最新の API だと感じています」 - 睡眠サイクル のTechnical Lead、Viktor Åkerskog
ディベロッパーの皆さんからのアルファ版ライブラリへのフィードバックには大変感謝しています。皆さんから頂いた多くのリクエストやパフォーマンスの改善を今回の API に含めました。追加のフィードバックはこちら (英語)からお送りください。今後のリリースに向けて、API の改善の優先順位を決めるうえで役立ちますので、ご協力をお願いいたします。
まだ API を試していない方はこちらのガイドをチェックしてください。チュートリアルを体験してみたい方はタイルの Codelab をお試しください。
それでは、コーディングをお楽しみください。
Reviewed by Saryong Kang - Partner Developer Advocate, Developer Relations Team
このイベントでは、Android/Google Play のゲーム向け製品開発の責任者である Greg Hartrell の基調講演の内容を中心に日本の Google 関係者が解説を行いました。
この記事では、イベント内で解説した内容とご紹介した関連動画やリソースをまとめます。
その他にも、イベント内では、海外デベロッパーの事例が聞けるセッションのご紹介も行いました。
なお、イベントのアーカイブ配信は、こちらのウェブサイトから登録後、いつでもご視聴いただけます。イベントを見逃した方は、ぜひアーカイブ配信もご活用ください。ウェブサイト上では、イベント内でご紹介した URL も多数公開していますので、こちらのリンク集からご確認ください。
この記事は Jacob Lehrbaum による Android Developers Blog の記事 " Working Towards Android App Excellence " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
すばらしいアプリ体験は、ビジネスにもすばらしい成果をもたらします。実際、Google Play に5 つ星の評価を残した Android アプリユーザーの約 3 分の 1 が、アプリ体験の質*1つまり、スピードやデザイン、ユーザビリティに触れています。Google では、すべてのデベロッパーが優れたアプリの開発を実現し、ユーザーの獲得、維持、収益化を果たせるようなサポートを提供したいと考えています。
では、「優れたアプリ」とは何でしょうか。これは遠い目標のように聞こえるかもしれませんが、多くのアプリでも手が届くところにあります。その第一歩となるのは、ユーザーにフォーカスし続けることです。具体的には、直感的なユーザー エクスペリエンスでアプリの主要機能にできる限り早く到達できるようにすることです。しかし、これはまだ始まりに過ぎません。優れたアプリにはすべての画面や操作に一貫性があり、使うデバイスによらず快適に動作します。アプリ開発に携わっているあらゆるメンバーがアプリ体験に集中すれば、優れたアプリの開発が実現できます。
優れたアプリの開発を阻むものの 1 つが、曖昧で不明確な責任分担です。クラッシュや読み込み時間など、アプリの質を測る主な指標の中には、エンジニアリング チームなどの社内の 1 グループの責任であると見なされるものがあります。しかし、業界のトップクラスの組織の方々にどのようにして優れたアプリの開発を実現しているか聞いたところ、*2エンジニアリング、デザイン、プロダクト、ビジネスの各チームが共通の目的に向かって連携する、部門間の協力的なアプローチが重要であることが明確になりました。
では、優れたアプリ開発のための裏側にある内部的なベスト プラクティスはどのようなものでしょうか。
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。クロス プラットフォーム アプリのソフトウェア エンジニア
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。
クロス プラットフォーム アプリのソフトウェア エンジニア
優れたアプリは、ビジネスの成果につながります。新機能の追加はすばらしいことですが、それでアプリの起動時間が遅くなったり、デバイスの容量を使いすぎたりすると、アプリの使用頻度が減り、やがて削除される結果をうみます。多くの場合、エンジニアは品質問題がビジネスの成果に与える影響を定量化することで、全社的に品質を重視する体制を構築しています。具体的には、次の方法で定量化しています。
機能（ユーザー ジャーニーの各ステージ）を担当するチームを編成している企業は、サポートするそれぞれのオペレーティング システム全体で一貫した操作を提供し、新しいアプリや機能を市場に投入するまでの時間が短くなり、すべてのお客様に優れたアプリ体験を提供できる可能性が高くなります。多くの場合、このようなチームは、エンジニア、マーケティング、UX、プロダクトなどの機能を横断するグループです。そして、あらゆるデバイスやプラットフォームで、機能やユーザー ジャーニーのステージ*3を成功させる責任を担います。この構造により、優れた体験や機能レベルが実現できるだけでなく、機能領域を超えた統一目標ができます。また、縦割りを減らして、特定の目標に集中的に対処することにもつながります。
ビジネス目標を重視するチーム構成により、ユーザーに対するフォーカスが高まる
ユーザーの大半が特定の種類のデバイスを使っている場合、主なデバイスとして同じスマートフォンやタブレット、スマートウォッチを使えば、ユーザーがどのような体験をしているか理解が深まるでしょう。特にこれが当てはまるのは、多くユーザーの日々の体験に影響を与える意思決定が求められる組織の経営幹部です。たとえば、Duolingo はこれを自社の DNA に組み込んでいます。ユーザー ベースの大部分と同様の環境を作り出すために、CEO も含む、すべての Duolingo の社員は、エントリーレベルの Android デバイスのみを使っているか、あるいは使える状態にあります。
ビジネスを成長させるうえで、品質および優れたアプリの開発に対するユーザー中心のアプローチは欠かせません。優れたアプリの開発を実現する方法を詳しく学びたい方は、実用的なヒントを含むケーススタディをご覧ください。また、Android App Excellence (英語) のページにアクセスし、ぜひ App Excellence Summit に参加してください。（事前登録制です）
今後のブログ投稿では、優れたアプリの開発を実現する 2 つの要素について詳しく取り上げる予定です。具体的には、アプリ パフォーマンスとそれによるユーザー行動への影響、そして複数のデバイス間のシームレスなユーザー エクスペリエンスの開発です。こちらのページから Android デベロッパー向け ニュースレターに登録すると、次号の発行時に通知が届き、Android チームからの最新ニュースや知見を得られますので、ぜひご登録ください。
注
1. 2021 年の Google Play 内部データ
2. 2021 年の Google App Quality Research
3. アプリを使ううえで、それぞれのユーザーが体験する一連の手順を「ユーザー ジャーニー」と呼びます。ユーザー ジャーニーのステージの例として、インストール、オンボーディング、エンゲージメント、リテンションなどがあります
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
この記事は Dave Burke による Android Developers Blog の記事 " Android 12 Beta 4 and Platform Stability " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
デベロッパーの皆さんにとって、Beta 4 は プラットフォームの安定版 を意味します。つまり、Android 12 の API とアプリに面する動作がすべて確定します。アプリやゲームにとっては、互換性と品質に注力していただく時期です。今年後半の公式リリースに間に合うように、互換性のあるアプリやゲームへのアップデート準備をお願いいたします。
Beta 4 は、Pixel デバイスで試すことができます。こちらから登録 (英語) するとOTA (無線)アップデートを受け取ることができます。以前登録している方は、自動的に今回のアップデートを受け取ります。ASUS、OnePlus、Oppo、realme、シャープ、ZTE など、いくつかのパートナーの一部のデバイスでも Android 12 Beta 4 を試すことができます。詳しくは android.com/beta をご覧ください。使用を開始する方法についての詳細は、Android 12 デベロッパー サイトにアクセスしてください。
Android 12 Beta 4 は、プラットフォームの安定版 に到達しました。これは、Android 12 のアプリに面する部分とその動作がすべて確定したことを示すマイルストーンです。公式の SDK と NDK API だけでなく、アプリに影響する可能性がある非 SDK インターフェースでも、アプリに面するシステム動作や制限が確定します。Beta 4 以降では、プラットフォームが変更されないことがわかっているので、安心して互換性アップデートをリリースできます。スケジュールの詳細はこちらをご覧ください。
すべてのアプリとゲームのデベロッパーは、最終リリース前にできるだけ早く最終の互換性テストを開始し、互換性アップデートを公開する準備をしてください。
すべての SDK、ライブラリ、ツール、ゲームエンジン デベロッパーの皆さんは、今すぐテストを始めて、できる限り早く互換性アップデートをリリースすることが非常に重要です。下流のアプリやゲームのデベロッパーは、皆さんのアップデートを受け取るまで作業できないかもしれません。互換性アップデートをリリースしたら、デベロッパーに向けてアナウンスしてください。
Android アプリの互換性とは、新しいバージョンのプラットフォームでアプリが意図したとおりに動作することを意味します。アプリの互換性は、デバイスかエミュレータに公開版のアプリをインストールしてテストするだけで確認できます。アプリの表示が問題なく、正しく動作すれば、それで終了です。そのアプリには互換性があります。
アプリの互換性テストは重要です。なぜなら、リリースごとにプラットフォームに必要な変更を行い、プライバシーやセキュリティを改善したり、OS 全体のユーザー エクスペリエンスを向上させたりしているからです。これにより、アプリに影響が生じる可能性もあります。そのため、すべてのアプリの動作の変更点についてのドキュメントを確認してテストし、ユーザーに互換性アップデートを公開する必要があります。アプリで優れたユーザー エクスペリエンスを確保するために、このレベルの品質は基本的かつ不可欠です。
デバイスを Android 12 にアップデートしたユーザーは、最新バージョンの Android やお気に入りのアプリやゲームを試してみたくなるでしょう。アプリやゲームが正しく動作しないと、大きな問題になり、結果的にアンインストールにつながります。
利用できる新しい API や機能はたくさんありますが、まずは現在のアプリをテストし、互換性アップデートをリリースするところから始めましょう。
Android 12 でのアプリの互換性テストは、Android 12 Beta 4 を実行しているデバイスに Google Play や他のソースから公開版のアプリをインストールするだけで行うことができます。そしてアプリのすべてのフローを試し、機能や UI の問題を探します。すべてのアプリが対象となる Android 12 の動作の変更点を確認し、集中的にテストを行ってください。特に注意すべき変更点は、以下のとおりです。
アプリのライブラリや SDK の互換性テストも忘れずに行ってください。問題を見つけた場合は、最新バージョンの SDK にアップデートするか、デベロッパーに連絡してサポートを受けるようお願いします。
現在のアプリの互換性のあるバージョンを公開したら、アプリの targetSdkVersion をアップデートするプロセスを開始できます。Android 12 をターゲットとするアプリの動作の変更点を確認し、互換性フレームワークを使って問題をすばやく検知します。以下に、テストが必要な変更点の一部を記載します（targetSdkVersion が 31 以上のアプリに適用されます）。
SCHEDULE_EXACT_ALARM
android:exported
テストでは、制限されている非 SDK インターフェースが使用されていないかも確認し、存在する場合は同等のパブリック SDK に移行します。制限されている API については、こちらをご覧ください。
今回のベータ版リリースには、Android 12 の機能を試し、アプリをテストしてフィードバックを提供するために必要なすべてのものが含まれています。サポート対象となっている Pixel デバイスを登録するだけで、OTA(無線)でアップデートを入手できます。また、Android 12 に対応したアプリの開発を行うために、Android 12 SDK をセットアップしてください。
ASUS、OnePlus、Oppo、realme、シャープ、ZTE など、いくつかの主要メーカーのデバイスでも Android 12 Beta 4 を試すことができます。Android 12 Beta に対応しているデバイスとパートナーの全リストは、android.com/beta に掲載されています。さらに幅広くテストしたい場合は、Android GSI イメージで Android 12 Beta 4 をお試しください。デバイスをお持ちでない場合は、Android Emulator でテストできます。
Beta 4 は Android TV でも利用できるので、ADT-3 デベロッパー キットを使って、最新の TV 機能を確認したり、新しくなった Google TV エクスペリエンスでアプリをテストしたりできます。詳しくはこちらをご覧ください。(英語)
数週間後には、最終テスト用のリリース候補として、最後のベータ版をお届けする予定です。
Android 12 Betaの詳細については、Android 12 デベロッパー サイトをご覧ください。
この記事は Krish Vitaldevara による Android Developers Blog の記事 " Announcing Policy Updates To Bolster Privacy and Security " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは常に、Google Play での体験が、デベロッパーやユーザーにとって安全で信頼性の高いものであることを目指しています。本日は、ユーザーが自身でデータをコントロールでき、プライバシー、セキュリティを高めるための新しいポリシー更新情報についてお知らせします。
Google Play に新しく「セーフティセクション」が追加されます。このセクションに関する新しいポリシーを、データの定義などの追加情報と併せて発表しました。詳細はこちらをご覧ください。
Google は長期にわたり、ユーザーが広告 ID をコントロールできる方法を提供してきました。たとえば、ID はいつでもリセットでき、ID を使った広告のカスタマイズをオプトアウトできるようにしています。今年は、さらに多くの管理方法を追加します。
2021 年 6 月 2 日にデベロッパーの皆さんに先行してお知らせしたように、Google Play 開発者サービスの更新の一環として、2021 年後半に技術的な変更を行います。ユーザーがインタレストベース広告や広告のカスタマイズをオプトアウトすると、広告 ID が削除され、ゼロの文字列が返されます。なお、この Google Play 開発者サービスの変更は、段階的にロールアウトされる予定です。2021 年後半から Android 12 デバイスで実行されるアプリに反映され、2022 年初頭には Google Play をサポートするデバイスで実行されるすべてのアプリに展開されます。また、ターゲット API レベルを Android 12 にアップデートするアプリで広告 ID を使うには、マニフェスト ファイルで新しい Google Play 開発者サービスの権限 (英語) を宣言する必要があります。
さらに、ユーザーがオプトアウトを希望することをデベロッパーと広告/分析サービス プロバイダに通知する新機能のテストも行います。この機能によりデベロッパーは、ユーザーの選択を反映し、既存のポリシー制限に、広告 ID が、どのように使用されるか追加できるようになります。ユーザーが広告 ID を削除すると、デベロッパーは通知を受け取り、使えなくなった広告 ID を速やかに消去できます。
加えて、永続デバイス ID を個人データや機密性の高いユーザーデータ、またはリセット可能なデバイス ID にリンクすることを禁止します。このポリシーは、ユーザーがデバイス ID をリセットしたり、アプリをアンインストールしたりしたときの追加のプライバシー保護のためのレイヤーとなります。
そして最後に、アプリセット ID (英語) のデベロッパー プレビューを提供します。この機能は、分析や不正防止などの重要なユースケースに活用できます。アプリセット ID は一意の ID です。任意のデバイスでこの ID を利用することにより、組織が所有する複数のアプリ間で利用状況や操作を相互に関連付けることができます。アプリセット ID は、広告のパーソナライズや広告の測定に使うことはできません。また、デバイスでそのデベロッパーのアプリがすべてアンインストールされるか、13 か月間どのアプリも ID にアクセスしなかった場合、自動的にリセットされます。
分析や不正防止のためにアプリセット ID を導入するとともに、子ども向けのプライバシーをさらに強化するための変更も行います。アプリが主に子ども向けである場合、広告 ID などの ID を送信することはできません。アプリの対象が子どもと大人の両方である場合、子どもに向けて ID を送信しないようにする必要があります。
スムーズに移行できるように、今後数か月間で詳しい情報を提供する予定です。
プラットフォーム全体のプライバシーを実現する上で、セキュリティは欠かせない要素です。ユーザーのデータを安全に保つために、いくつかのポリシーの更新をお知らせします。
まずはじめに、デベロッパーの皆さんがアプリを積極的に保守を行うことによって、Google Play は安全なエコシステムであり続けることができます。そこで、1 年間利用されていないアカウントや放置されているアカウントを閉鎖します。これには、1 年間 Google Play Console にアプリをアップロードしなかったアカウントや、アクセスがなかったアカウントも含まれます。
積極的に成長しているアプリを開発しているデベロッパーの皆さんへのサポートは継続します。1000 以上のインストールがあるアプリや、直近 90 日間にアプリ内購入があるアプリのアカウントは例外とします。アカウントが閉鎖されたデベロッパーは、その後も新しいアカウントを作ることはできますが、古いアカウント、アプリ、データを再度アクティブ化することはできません。
次に、ユーザーにとって重要なのは、安全でユーザーが利用しやすいアプリやゲーム体験です。そこで、AccessibilityService API と IsAccessibilityTool (英語) の利用方法に関する新しい要件を追加します。多くの場合、ユーザー補助機能が備わった体験を構築するには、ユーザーのデータやデバイスの機能にアクセスすることが必要です。上記のツールは、それを実現するうえで役立ちます。現在、AccessibilityService API を利用するすべてのアプリは、Google Play Console でデータへのアクセスと目的について開示し、承認を得る必要があります。詳細はこちらをご覧ください。
2021 年 7 月にお知らせしたように、ビジネスサイズの大小に関わらず様々なデベロッパーの皆さんからのフィードバックを慎重に検討した結果、お支払いポリシーに準拠する期限を 2022 年 3 月 31 日まで 6 か月間延長するリクエストを行えるようにしています。
Google Play が誰にとっても信頼できるアプリとゲームの提供元であり続けるためご協力いただきますよう、お願いいたします。
この記事は Suzanne Frey による Android Developers Blog の記事 " Preparing for Google Play’s new safety section " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
本日は、Google Play に追加されるセーフティ セクションについて、詳しい情報をお伝えします。Google では、ユーザーがオンラインで安全に過ごせるようにするために、デフォルトで安全で、プライバシーを考慮した設計となっており、ユーザーがデータをコントロールできるプロダクトを提供することが必要だと考えています。今回新たに追加されるセーフティ セクションは、デベロッパーにアプリの全体的な安全性を簡単に明示できる方法を提供します。また、ユーザーがアプリをインストールする前に、プライバシーやセキュリティの慣習に関する詳しい情報を提示したり、アプリが収集するデータやその理由を説明したりできます。
セーフティ セクションの情報は、Google Play ストアのすべてのアプリで必須になります。デベロッパーの皆さんがこの措置に対して準備をする十分な期間を設けるため、この新機能のデータの種類の定義、ユーザージャーニー、ポリシー要件について詳しくお伝えします。
これらの画像は方向性を示すものであり、変更される場合があります。
ユーザーには、アプリのストア掲載情報ページに、新しいサマリー欄が表示されます。そこには、アプリが収集または共有するデータについてのデベロッパーによる説明のほか、安全性に関連する以下のような情報が表示されます。
サマリーをタップすると、以下のような詳細情報が表示されます。
これらの機能をデザインするうえで、デベロッパーの皆さんがデータを扱う状況や、アプリがデータを自動収集するのか収集は任意なのかについて、より詳しくユーザーに伝えたいと考えておられることが、わかりました。また、ユーザーは収集されるデータが他社と共有されているかどうかや、その理由について理解したいと思っていることも、わかりました。
Google は、デベロッパーの皆さんと連携し、デベロッパーとユーザーの双方にとって最適な体験を設計できるように努めていますので、今後、最終的なデザインは変更される可能性があります。
本日、新しいユーザーデータ ポリシーについて発表しました。このポリシーは、ユーザーの透明性を向上させ、データがどのように収集、保護、利用されるかについて、十分な情報に基づいてユーザーが選択できるようにすることを念頭に置いて設計されました。
これは、Google 製アプリも含め、Google Play で公開されているすべてのアプリに適用されます。
デベロッパーの皆さんが準備をするにあたり、十分な時間とリソースを提供したいと考えています。
スケジュール(日付は変更される可能性があります)
2021 年 10 月より、デベロッパーは Google Play Console 上で情報の申告を行い、審査を受けることができます。本件に関して、デベロッパーの皆さんが作業を行っている途中で質問が生じる可能性もありますので、お早めに準備を開始されることをお勧めします。そして、2022 年初頭に、すべてのユーザーが Google Play で新しいセーフティ セクションを利用できるようになります。
この準備に向けて、アプリの確認を行ったり、複数のチームと調整を行う関係で、さらに準備に時間が必要になるデベロッパーもいらっしゃると思います。そこで、新規・既存のアプリのこのセクションの掲載情報の承認を得る期限を 2022 年 4 月とします。セクションが承認されていない場合、新しいアプリの送信やアプリのアップデートは不承認となる可能性があります。
2022 年初頭に、Google Play のセーフティ セクションがユーザーに公開される時点で、アプリの情報が承認されていない場合、掲載情報がない旨が表示されます。
今後数か月間で、具体的な日付などのガイダンスを提供する予定です。この機能をともに構築し、Google Play が誰にとっても安全で、信頼できるアプリとゲームの提供元であり続けるため、ご協力いただきますよう、お願いします。
Reviewed by Konosuke Ogura - Trust & Safety - Play & Android, Global Content Operations Lead, Naoki Oyama - Developer Support Lead, Google Play, APAC and Tamao Imura - Developer Marketing Manager, Google Play
この記事は Amanda Alexander による Android Developers Blog の記事 " Android Studio Arctic Fox (2020.3.1) Stable " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Studio Arctic Fox が、安定版リリース チャンネルでダウンロードできるようになったことをお知らせします。この最新リリースでは、Android の新しいネイティブ UI 構築ツールキットである Jetpack Compose 1.0 を利用できます。さらに、Wear OS を含むデバイスにも注力し、新しい Background Task Manager などのデベロッパーの生産性を高める機能も搭載されています。皆さんのフィードバックをもとに開発されたこの新しい Android Studio 機能のスイートは、デベロッパー コミュニティがさまざまなデバイスで動作する質の高い最先端のアプリを迅速に作るために役立つことができれば幸いです。
注 : 昨年発表した通り、Android Studio のバージョン番号体系を Android Studio のベースになっている IntelliJ IDEA の年とバージョンに一致させ、そこに独自のパッチ番号を付加するように変更しました。今後はコードネーム（アルファベット順）を利用します。最初は Arctic Fox で、次は Bumblebee（現在カナリー版）です。Android Studio Arctic Fox（2020.3.1）では、Android Studio が IntelliJ プラットフォームのバージョン 2020.3 にアップデートされます。これには、デバッガ インタラクティブ ヒント、VCS のアップデート、いくつかの新しいコードエディタの強化など、ワークフローを高速化するたくさんの新機能が含まれています。詳細はこちらをご覧ください。（英語）
最新 UI をすばやくデザインできるように、Jetpack Compose 用の追加機能も搭載しています。Compose プレビューを使うと、Compose UI の複数のコンポーネントのプレビューを作成し、さまざまな要素（テーマ、画面、フォントサイズなど）にわたって変更の影響を即座に確認できます。デバイスへのデプロイ プレビュー機能では、Compose コードのスニペットを直接デバイスやエミュレータにデプロイし、小さなコードをすばやくテストできます。レイアウトを詳しく調べたい場合は、Layout Inspector に追加された Compose サポートを使って、レイアウトがどのようにレンダリングされるかを理解できます。さらに、リテラルのリアルタイム編集を追加しました。エミュレータや実機でアプリを動作させるときに、コンパイルを行うことなく、プレビューで Compose コードの変更を即座に確認できます。
サポート対象のデバイスを増やすため、新しい Wear OS ペア設定アシスタントを構築し、Wear OS エミュレータと物理スマートフォン、仮想スマートフォンとのペア設定を簡単に行えるようにしました。Wear OS の最新バージョンを使うには、Wear OS 3 システム イメージのデベロッパー プレビューをご利用ください。Wear OS エミュレータを実行すれば、心拍数センサー API のサポートが追加されていることにも気づくはずです。Google TV をターゲットにするアプリのために、最新の Google TV リモート コントロール機能を追加し、Google TV システム イメージをアップデートして最新の UI デザインを反映しました。さらに、Automotive OS で、運転に関するユースケースをシミュレーションするため、エミュレータで自動車センサーデータを利用できるようにして開発とテストのワークフローを完成させました。タブレットをターゲットにするアプリのために、すぐに横向きをサポートできるようにすべてのテンプレートを更新しました。開発のターゲットとなるデバイス画面の大小にかかわらず、新たな方法の導入とアプリの構築を継続するうえで役立つ新機能が含まれています。
最後に、デベロッパーの皆さんの生産性を向上させるために、作業の効率化に役立つ機能の追加についてご紹介します。たとえば、次期バージョンの Android アプリを構築する際のガイドとして、Android 12 向けの lint チェックを追加しました。コードのテストに役立ててもらうため、Layout Editor に Accessibility Scanner を追加し、レイアウトのユーザー補助に関する問題を簡単に見つけられるようにしました。また、新しいテスト マトリックスを使うと、複数のデバイスで並列実行されるテスト結果をリアルタイムに確認できます。さらに、Apple Silicon（arm64）ハードウェアのプレビュー サポートを追加し、幅広いテストをサポートできるようにエミュレータのコントロールを拡張しました。加えて、デバッグ用の新しい Background Task Inspector を使うと、アプリのバックグラウンド ワーカーを分析できます。
Android Studio Arctic Fox には、たくさんの機能強化が含まれています。すべての変更点のリストを確認したい方は、Android Studio Arctic Fox（2020.3.1）Beta リリースブログとリリースノートをご覧ください。以下では、主な変更点について紹介します。
Android Studio Arctic Fox の新機能
@Preview アノテーションを使うと、Compose コードのプレビューを生成して複数のコンポーネント（デバイス、テーマなど）をさまざまな構成で表示できます。Compose プレビューを活用すれば、コードで Composable のメンタル マッピングを簡単に作成できます。
Compose プレビュー
すべて Compose で書かれたアプリでも、Compose とビューを併用したアプリでも、Layout Inspector を使えばレイアウトの詳細を確認したり、トラブルシューティングを行ったりできます。たとえば、各 Composable に渡されたパラメータや修飾子を確認できます。アプリを開発する際に、ライブ アップデートを有効にしてデバイスからデータをストリーミングすることもできます。
Compose Layout Inspector
リテラル（文字列、数値、ブール値など）をインラインで編集すると、コンパイルしなおすことなく、変更の結果を画面（プレビュー、エミュレータ、実機）ですぐに確認できます。
リテラルのライブ編集 : 文字列を編集するとプレビューに即時反映
新しい Wear OS ペア設定アシスタントは、順を追ってペア設定プロセスを案内してくれるので、Wear OS エミュレータと仮想または物理スマートフォンのペア設定が簡単になります。なお、この機能は、Wear OS 2 コンパニオンとのペア設定をサポートします。Wear OS 3 は近日中にサポートされる予定です。詳細はこちらをご覧ください。
Wear OS エミュレータ ペア設定アシスタント ダイアログ
スマートフォン + スマートウォッチ エミュレータのペア設定が成功した状態
API レベル 26 以上を実行しているデバイスで WorkManager ライブラリ 2.5.0 以上を使っている場合、新しい Background Task Inspector を使ってアプリのバックグラウンド ワーカーを視覚化、監視、デバッグできます。メニューバーから [View] > [Tool Windows] > [App Inspection] を選択してアクセスできます。詳細はこちらをご覧ください。
Background Task Inspector
まとめると、Android Studio Arctic Fox（2020.3.1）安定版には、以下の機能強化と新機能が含まれています。
詳細は、Android Studio のリリースノート、Android Gradle プラグインのリリースノート、Android Emulator のリリースノートをご覧ください。
最新バージョンの Android Studio Arctic Fox はダウンロード ページ（英語）から、Apple Silicon プレビュー ビルドはこちら（英語）からダウンロードできます。Android Studio の以前のリリースをお使いの方は、最新バージョンの Android Studio にアップデートするだけで利用できます。Android Studio の安定バージョンを保持する必要がある場合、Android Studio Arctic Fox の安定リリース バージョンとカナリー リリース バージョンを同時に実行することができます。詳細はこちらをご覧ください。
気に入った点、問題点、新機能の提案などのフィードバックをお寄せください。バグや問題が見つかった場合は、バグを報告してください。Android Studio 開発チームの Twitter と Medium もぜひフォローしてください。
この記事は Anna-Chiara Bellini, Nick Butcher による Android Developers Blog の記事 " Jetpack Compose is now 1.0: announcing Android’s modern toolkit for building native UI " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 7 月 28 日（日本時間 7 月 29 日) Jetpack Compose のバージョン 1.0 をリリースしました。Android の最新ネイティブ UI ツールキットである Jetpack Compose を使うと、優れたアプリを短時間で構築できます。このリリースは安定版で、本番環境で利用できます。Compose は、この 2 年間、Android コミュニティのフィードバックや貢献を受けつつ、オープンに開発が行われてきました。1.0 に到達した現時点で、既に Google Play ストアの 2000 以上のアプリで Compose が使われています。実は、Play ストアアプリ自体にも Compose が使われています。それだけではありません。たくさんのトップ アプリ デベロッパーと協力し、フィードバックやサポートを受けることで、1.0 リリースはさらに強固なものになっています。たとえば、Square は Compose を使うことで「宣言型 UI フレームワークの構築に関するさまざまな問題を解決することではなく、Square 独自の部分や UI インフラストラクチャに集中できる」と教えてくれました。Monzo は、Compose を使うと「質の高い画面を短時間で構築できる」と述べています。また、Twitter は「とても気に入っています！❤️」と見事に一言で言い表しています。
Compose は、ネイティブ Android アプリを短時間で簡単に作成できるように設計されています。完全に宣言的なアプローチが採用されているので、UI を記述しさえすれば、あとは Compose が対応してくれます。アプリの状態が変わると、UI が自動的に更新されるので、UI の構築がはるかにシンプルかつ高速になります。直感的な Kotlin API を使うと、美しいアプリを はるかに 少ないコードで実現できます。また、すべての既存の Android コードにネイティブでアクセスできるので、自分のペースで導入することもできます。強力なレイアウト API とコード駆動型 UI により、タブレットや折りたたみ式デバイスなど、異なるフォーム ファクタのサポートも簡単です。Compose のサポートは、Wear OS や ホーム画面 ウィジェットなども追加される予定です。
今回の 1.0 リリースは本番環境で利用でき、以下の主要機能が提供されています。
完全な宣言型アプローチを採用している Jetpack Compose によって、UI の開発方法は大きく変わります。新しいワークフローと異なる考え方をサポートするため、Compose 向けに設計された新しいツールを提供します。また、いくつかの既存のツールに Compose のサポートを追加しています。
Android Studio Arctic Fox で利用できる新しい Compose プレビューでは、異なる状態、ライトテーマやダークテーマ、異なるフォント スケーリングのコンポーザブルをすべて同時に確認できます。アプリ全体をデバイスにデプロイする必要はないので、コンポーネントの開発が簡単になります。リテラルのライブ編集機能によって機能強化されているため、プロジェクトを再コンパイルせずにアップデートを確認できます。
作業中の画面まで移動せずにデバイスで UI のパーツをテストしたいと思っていた方なら、新しいデプロイ プレビューを気に入ってくれるはずです。Composable のプレビューを作成するだけで、デバイスにデプロイしてすばやく反復できます。
Layout Inspector に Composable サポートが追加されるため、Compose と既存のビューを確実に混在させることができます。
Android Studio Arctic Fox での Compose サポートの詳細については、こちらをご覧ください。
新しいフレームワークを採用するには、評価が必要です。新しい UI ツールキットのように広範囲にわたるものでは、特にそれが重要になります。皆さんにとって今が適切なタイミングかどうかを情報に基づいて判断できるように、パブリック ロードマップ (英語) を公開して今後の Jetpack Compose の開発計画をお知らせします。
Compose を活用していただくために、皆さんや皆さんのチームが利用できる幅広いリソースを準備しました。
学ぶべきことはたくさんあります。Jetpack Compose Pathway (英語) では、主要な コードラボ、動画、ドキュメントを順番に体験できます。
Jetpack Compose は大きな飛躍であり、すばらしい UI を短時間で簡単に作れるものだと確信しています。これを使って皆さんが作るものを見ることが楽しみでなりません。Compose が 1.0 の安定版になった今こそ、実際に使うべきときです。直接コードを触るのが最善の方法です。ぜひ Compose を使ってみてください！
この記事は Dave Burke による Android Developers Blog の記事 " Android 12 Beta 3 and final APIs " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは、毎月 Android 12 の公式版リリースに近づけるための Beta 提供をを行っています。Android 12 には、革新的な機能や、ユーザーに適応する (英語) 新しい UI、パフォーマンスの向上、プライバシーの強化、セキュリティ上のメリットなどが含まれています。多くの皆さんが、Android 12 Beta プログラムを通じて既に Android 12 の開発やテストを行っています。これまでフィードバックを提供してくださった皆さん、どうもありがとうございました。
引き続き公式版のリリースを微調整する作業を継続していますが、先日 2021 年 7 月 14 日 (現地時間）にAndroid 12 Beta 3 をリリースしました。ぜひお試しください。Beta 3 には、スクロール スクリーンショット、プライバシー インジケーター API、自動回転の強化などのアップデートとともに、確定版の Android 12 API と公式 SDK も含まれています。以上の機能をもって、次回の Beta 4 での Platform Stability を待たずに、アプリのテストとアップデートを開始することができます。ぜひご自身のアプリやゲームのご準備をお願いいたします。
Beta 3 は、既に対象となる Pixel デバイスで利用でき、こちらから登録 (英語) すると OTA (無線) アップデートも行えます。Beta プログラムに登録済みの方は、自動的にアップデートを受け取ります。パートナーのデバイスメーカーである、シャープや TCL などの、一部のデバイスでも Android 12 Beta 3 を試すことができます。詳しくは android.com/beta をご覧ください。使用を開始する方法について詳しくは、Android 12 デベロッパー サイトにアクセスしてください。
Beta 3 には、機能、ユーザー エクスペリエンス、パフォーマンスを改善する様々なアップデートが含まれています。ここでは、いくつかのポイントを紹介します。
スクロール スクリーンショット - スクロールするコンテンツを簡単にキャプチャして共有できるように、スクロール スクリーンショットを追加します。Beta 3 以降では、スクロール可能なコンテンツのスクリーンショットをキャプチャする場合、[Capture more] ボタンが表示され、それを押すことでスクリーンショットを全コンテンツに拡張できます。その後、切り取る範囲を調整することもできます。
設定アプリでのスクロール スクリーンショットのキャプチャ例
スクロール スクリーンショットは、ほとんどのアプリでそのまま動作します。標準のビューベースの UI を使っているアプリでは、何の変更も必要ありません。ビューベースの UI を使わないアプリや UI ツールキット、または高度にカスタマイズされた UI でスクロール スクリーンショットをサポートするために、新しい ScrollCapture API (英語) を導入しています。この API を使うと、システムはアプリにスクロール キャプチャ リクエストを通知するとともに、UI を描画する Surface を提供します。スクロール スクリーンショットに関する反復作業はまだ続いています。Beta 4 では、スクロールする ListView など、デフォルトのサポートが改善される予定です。また、Web コンテンツなどサポート対象のコンテンツを増やすための作業も行っています。引き続き、皆さんのフィードバックをお待ちしています。
オンデバイス検索 - Beta 3 では、新しい高パフォーマンス オンデバイス検索エンジンである AppSearch がプラットフォームでサポートされます。AppSearch (英語) を使うと、アプリが構造化データをインデックスに登録したり、組み込みの全文検索機能を使って検索したりできます。非常に効率的なインデックスの登録や検索、多言語サポート、関連度ランキングなどのネイティブ機能を使うこともできます。
AppSearch には、ローカル インデックスとセントラル インデックスという 2 つの仕組みを搭載しています。ローカル インデックスはアプリで利用でき、新しい AppSearch Jetpack ライブラリを通して下位互換性も提供されます。セントラル インデックスは、Android 12（およびそれ以降のリリース）のシステム全体で維持されます。セントラル インデックスを利用すると、オプトアウトしない限り、システム UI の表層にアプリのデータが表示されます。さらに、他のアプリと安全にデータを共有し、自分のアプリのデータだけでなく他のアプリのデータも検索できるようになります。詳しくはこちらをご覧ください。（英語）
WindowInsets のプライバシー インジケーター API - Beta 2 では、アプリがデバイスのカメラまたはマイクを使っているときに、ステータスバーにプライバシー インジケーターが表示されるようになりました。アプリが没入モードのときにインジケーターが表示されると、コントロールやコンテンツが隠れてしまう可能性があるので、アプリはインジケーターを描画できる場所を把握し、有用なコンテンツが隠れないように必要な調整を行う必要があります。Beta 3 では、WindowInsets (英語) に新しくプライバシー インジケーター API (英語) を追加します。これを使うと、インジケーターの最大領域と画面上での相対的位置を取得できます。現在の画面の向きや言語設定も考慮されます。詳しくはこちらをご覧ください。
カメラとマイクの切り替えの企業設定 - Beta 2 では、新しい切り替え機能も導入し、すべてのアプリでユーザーが即座にデバイスのマイクやカメラをオフにできるようにしました。フルマネージド デバイスに必要な制限を設定できる企業の管理者は、この機能にアクセスできるようになります。詳しくはこちらをご覧ください。(英語)
CDM でペア設定され、フォアグラウンド サービスを開始するアプリの新しいパーミッション - システムの透過性を提供しつつ、コア機能を担うコンパニオン アプリのサポートを向上させるため、Companion Device Manager（CDM）とペア設定されたアプリは、新しい通常のパーミッションを宣言することで、バックグラウンドからフォアグラウンド サービスを起動できます。詳しくはこちらをご覧ください。(英語)
自動回転の向上と高速化 - 画面を回転させるタイミングを正確に認識できるように、前面カメラによる顔検出を使って Android の自動回転機能を強化しました。この機能は、ソファやベッドで横になりながらデバイスを使う場合などに特に便利です。デベロッパーにとっては、ユーザーが設定でオプトインした場合、自動回転の動作のユーザー エクスペリエンスが向上することになります。この自動回転機能の強化は、最近発表された Private Compute Core (英語) の機能です。そのため、画像が保存されたり、デバイス外に送信されたりすることはありません。Beta 3 では、この機能は Pixel 4 以降の Pixel デバイスで利用できます。
すべてのデバイスで画面の回転をできる限り高速化するため、アニメーションと再描画を最適化し、ML を利用したジェスチャー検知アルゴリズムを追加しました。その結果、ベースとなる自動回転機能の遅延が 25% 減少しました。顔検出による機能強化は、これらの改善が土台となっています。ぜひ改善された自動回転機能をお試しいただき、感想をお聞かせください。
ゲームに向けた Android 12 - Game Mode API (英語) を使うと、プレーヤーがゲームのパフォーマンス プロファイル（長時間通勤用に電池寿命を延ばす、パフォーマンス モードで最高のフレームレートを実現するなど）を選択する操作に応答できます。この API は、近日中に公開されるゲーム ダッシュボードと連携します。ダッシュボードでは、ゲームプレイ中に重要なユーティリティにすばやくアクセスできるオーバーレイ エクスペリエンスが提供されます。ゲーム ダッシュボードは、一部のデバイスで今年中に利用できるようになる予定です。
Android 12 での Touchgrind BMX の Play as you download
それまでの間は、インストール時にバックグラウンドでゲームアセットをフェッチできるようにする Play as you download (英語) を使って、プレーヤーをすばやくゲームプレイに導くことができます。
Android 12 のすべての新機能について知りたい方は、Android 12 デベロッパー Web サイトをご覧ください。
この数週間、Android 12 API を確定する作業を行ってきました。そして Beta 3 で、公式の API レベル 31 SDK と併せて確定版 API をリリースします。Beta 4 では完全な プラットフォームの安定版に到達する予定です。この段階では、API サーフェスに加えて、アプリ向けのすべてのシステム動作と非 SDK インターフェースの制限も確定します。
Android 12 API でアプリをコンパイルする場合は、今回のリリースを使って環境をアップデートし、確定版の SDK と最新ツールでアプリを再コンパイルすることをお勧めします。
Pixel などの対応デバイスで Android 12 Beta を利用するアーリー アダプターやデベロッパーが増えてきた今が、アプリを Android 12 Beta 3 に対応する絶好のタイミングです。
Beta 3 でアプリの互換性テストを行うには、Android 12 Beta を実行しているデバイスかエミュレータに、Google Play や他のソースで公開されているバージョンをインストールします。そしてアプリのすべてのフローを試し、機能や UI の問題を探します。変更によってアプリが影響を受ける領域を集中的にテストするため、動作の変更点を確認してください。この段階では、アプリの targetSdkVersion を変更する必要はありません。問題が解決できたら、Android 12 Beta のユーザー向けにできる限り早くアップデートを公開することをお勧めします。
前述のとおり、Android 12 は次のリリースとなる Beta 4 で Platform Stability に到達します。Platform Stability では、アプリに面するすべての動作、SDK/NDK API、非 SDK 制限が確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリのリリースをしてください。デベロッパー向けの Android 12 のタイムラインの詳細は、こちらをご覧ください。
今回の Andorid 12 Beta 3 リリースには、Android 12 の最新機能を試し、アプリの動作をテストしてフィードバックを提供するために必要なすべてのものが含まれています。サポート対象となっている Pixel デバイスを登録するだけで、OTA（無線）でアップデートを入手できます。また、Android 12 に対応したアプリの開発を行うために、Android 12 SDK をセットアップしてください。
Android 12 Beta 3 は、シャープや TCL などの一部の主要メーカー パートナーのデバイスでも利用できます。Android 12 Beta に対応しているデバイス パートナーの全リストは、android.com/beta に掲載されています。さらに幅広くテストしたい場合は、Android GSI イメージで Android 12 Beta をお試しください。デバイスをお持ちでない場合は、Android Emulator でテストできます。
Beta 3 は Android TV でも利用できるので、ADT-3 デベロッパーキットを使って、新しくなった Google TV エクスペリエンスで最新の TV 機能を確認したり、アプリをテストしたりできます。詳しくはこちらをご覧ください。(英語)
Android 12 Beta の詳細については、Android 12 デベロッパー Web サイトをご覧ください。
2021 年 7 月 12 日(米国時間) に、Android Game Development Kit（AGDK）をリリースしました。これはさまざまなツールとライブラリの集まりで、高品質の Android ゲームを開発、最適化、配信する際に役立ちます。
AGDK の機能は、次の 3 つの信条に従っています。
この初回リリースでは、デベロッパー コミュニティから多くのフィードバックが寄せられた 3 つの主要領域に注力しています。具体的には、統合ワークフロー、C/C++ ゲーム ライブラリ、そしてパフォーマンスの最適化です。
一般的には、ツールを切り替える回数が少ないほど、効率が上がります。そこで AGDK では、皆さんが主に使う IDE で Android ゲーム開発を高速化できる新しいツールを提供します。皆さまが使い慣れている既存のワークフローのどの部分とも両立できるようにしつつ、Google が独自の価値を追加して Android 固有の問題を解消できるワークフローに注力したいと考えています。
C/C++ 開発用のゲーム ライブラリを使うと、Java Native Interface（JNI）を使う頻度を減らし、C で開発を始めることができます。ほとんどのゲームやゲームエンジンは C++ で書かれていますが、ほとんどの Android 開発では Java プログラミング言語を使用する必要があります。Java Native Interface でこの 2 つの言語を連携させるには労力が必要で、それがバグやパフォーマンス低下の原因となる場合があります。AGDK では、Java プログラミング言語と JNI の利用を最低限にとどめる C ゲーム ライブラリが提供されるので、ゲームエンジンの構築やカスタマイズに役立ちます。つまり、ゲームの開発、デバッグ、メンテナンスが容易になります。
私たちは、皆さんが一番不満を感じている部分に集中的に取り組んでいます。最初のうちは、アクティビティや入力のベースとなるクラスを構築することで対処しますが、長期的には、C ライブラリをさらに追加し、さまざまなゲームエンジンで一般的に使われる機能を提供することを計画しています。既存のフレーム ペーシング ライブラリと高パフォーマンス オーディオ ライブラリをこの作業に組み込み、さらに次の 3 つの新機能を追加します。
これらのライブラリの詳細は、Google for Games Developer Summit 2021 の C/C++ ライブラリのセッション (日本語字幕あり）をご覧ください。
できる限り簡単に統合作業を行えるように、すべてのライブラリは、Maven 依存関係、コンパイル済み Zip ファイル、ソースコードとして取得できるようになっています。
ここでの目標は、リリース前に安定性やパフォーマンスの問題を見つけられるようにすること、リリース後に監視して問題が起きたときに把握できるようにすることです。まずは、フレームレート、読み込み時間、メモリなどの特に重要な指標から始め、今後も新しい指標を追加する予定です。
g.co/android/AGDK (英語) にアクセスすると、Android ゲーム開発の最新リソースを確認したり、AGDK をダウンロードすることができます。Google for Games Developer Summit のすべてのセッションの情報は、モバイル セッション トラック(日本語字幕あり) から確認できます。日本で開催される振り返りイベントにも、ぜひご参加ください。
2021 年 7 月 12 日から 13 日（日本時間 7 月 13 日から 14 日）にゲームに特化したデベロッパー向けイベント、 「Google for Games Developer Summit 2021」 をオンラインで開催しました。
これにあわせて、Google for Games Developer Summit 2021 で発表されたコンテンツのうち、日本のデベロッパー様へ特にお届けしたい話題をご紹介する「Google for Games Developer Summit 2021 Recap 」を 8 月 25 日 16:00 より開催します。
金 清司 Google Play Partnerships ゲーム部門 日本統括部長
松内 良介 デベロッパー リレーションズ デベロッパー アドボケイト
※内容は変更される場合がありますので、最新情報はウェブサイトでご確認ください。
新しい情報は、引き続き、ウェブサイトならびに本ブログでもお知らせします。 Twitter : #GoogleforGames
Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Purnima Kochikar による Android Developers Blog の記事 "Allowing developers to apply for more time to comply with Play Payments Policy" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは日々デベロッパーの皆さんと連携しながら、Google Play があらゆる人にとって安全、安心でシームレスな体験を提供できるよう、そして、デベロッパーの皆さんが持続可能なビジネスを構築できるように努めています。昨年 9 月に、Google Play の課金システムの使用が、いつ必須になるかということをデベロッパーの皆さんに示すため、お支払いに関するポリシーの明確化を行いました。大多数のデベロッパーの皆さんはその当時からすでにこのポリシーを遵守していましたが、課金システムを統合するために技術的な作業が必要なデベロッパーに対しては、必要なアップデートを完了するため 1 年間（2021 年 9 月 30 日まで）の猶予期間を設けました。
この記事は Greg Hartrell による Android Developers Blog の記事 "Updates from the Google for Games Developer Summit" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年は、Android と Google Play が新たなステージに到達し、多くの人が自宅で安全に、更に多くのゲームを楽しむようになりました。私たちは、Google Play をユーザーにとってよりよい場所にし続けることで、ゲーム デベロッパーが世界中の様々なユーザーとつながることができる、より豊富な機会を提供してきました。その結果、世界中で Android の月間アクティブ端末数は 30 億台、Play の月間アクティブ ユーザー数は 25 億人に達し、合計 1400 億回のインストールが行われています。
Google はあらゆる人のための開発を支援しています。つまり、大規模なゲームスタジオから、世界中で楽しい画期的なゲームを開発している小規模なインディー ショップまで、すべてのデベロッパーが適切なタイミングでゲーマーにアプローチできるお手伝いをしています。
Game Developer Summit では、ゲームビジネスのライフサイクル全体に関連する幅広いツールやソリューションの最新情報を発表しました。具体的には、ゲーム開発をより容易にする新ツール、ゲームを更に多くのマルチスクリーン上で実行することを可能にする、成長中のエコシステムに関する最新情報、Google Play で市場開拓を成功させる新たなチャンスなどについてお知らせしました。
ここでは、イベントでお話しした内容と、今日から実践できることついて、もう少し詳しくお伝えします。
Google for Games Developer Summit のすべてのセッションの情報は、モバイル セッション トラック（各セッション動画には日本語字幕が付きます）から確認できます。また、Android ゲーム開発の最新リソースを入手できる g.co/android/games をブックマークしておきましょう。
Reviewed by Chongsa Kim - Head of Japan Games Business Development, Yuichi Araki - Developer Relations Team, Hidenori Fujii - Google Play Developer Marketing APAC
この記事は Dom Elliott による Android Developers Blog の記事 "The future of Android App Bundles is here" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2018 年 5 月に Android App Bundle をローンチしてから、デベロッパー コミュニティがこの新基準を広く採用し、リリースの効率化や高度な公開機能によるメリットを活用しているのを見てきました。現在では、100 万以上のアプリが実際に App Bundle を使っています。そこには、Adobe、Duolingo、Gameloft、Netflix、redBus、Riafy、Twitter など、Google Play のトップ 1,000 のアプリやゲームの大半が含まれています。
このメリットをより多くのユーザーに提供し、すべてのデベロッパーにとっても有益な、最先端の Android のアプリ公開形式に注力するため、2021 年 8 月より、Google Play で新しいアプリやゲームを公開する際に Android App Bundle の使用が必須となります。これにより、標準の公開形式が APK から App Bundle になります。
まだ App Bundle に切り替えていない方のために、皆さんが見逃しているメリットについて説明します。
リリースの種類
変更前
2021 年 8 月に必須となる
項目
Google Play 上の新規アプリ
APK
Android App Bundle（AAB）
拡張ファイル（OBB）
Play Asset Delivery または
Play Feature Delivery
既存アプリのアップデート
変更なし
新規 Instant
エクスペリエンス
Instant app ZIP
Instant 対応 Android App Bundle（AAB）
Instant
エクスペリエンスの
アップデート
再度のご案内となりますが、App Bundle の要件は新規アプリに適用されます。現在のところ、既存アプリや managed Google Play ユーザーを対象に公開されている限定公開アプリは対象外です。最後になりましたが、App Bundle の普及に貢献してくださっているたくさんのデベロッパーの皆さんに感謝いたします。今後、さらなる改善と新機能をお届けできることを楽しみにしております。以下では今回の移行に際し、よくお寄せいただく質問への回答を紹介します。
- - -
Android App Bundle に関するよくある質問と回答
APK と比べ、App Bundle を使う場合はどのくらいの作業が必要になりますか？
ほとんどのアプリでは、わずかな作業だけで APK の代わりに AAB をビルドできます。ほとんどの場合、ビルド時に別のオプションを選び、いつもどおりテストするだけです。App Bundle はオープンソースのフォーマットで、Android Studio、Gradle、Bazel、Buck、Cocos Creator、Unity、Unreal Engine、その他のエンジンなど、主要なビルドツールでサポートされています。Play Core Native や Play Core Java & Kotlin SDK でも、任意のコーディング環境を利用して、オプションの高度な App Bundle 機能を簡単に利用できます。
App Bundle で拡張ファイル（OBB）がサポートされないのはなぜですか？ゲームで Play Asset Delivery を使う必要があるのはなぜですか？
APK でユーザーに追加リソースを配信するには、別のファイル（OBB）が必要です。しかしながら、OBB は署名されておらず、アプリの外部ストレージに保存されるため、あまり安全ではありません。しかし、 Play Asset Delivery（PAD）を使用することで、サイズが 150 MB を超えるゲームでも、OBB ではなくゲーム全体を 1 つの App Bundle として Google Play Store で公開できるようになります。公開プロセスがスムーズになり、柔軟な配信モードが利用できることに加え、PAD には以前の拡張ファイルを上回るメリットがあります。アセットの差分パッチが大型アプリ向けに最適化されるので、アップデートに必要なデバイスのストレージが OBB よりも大幅に少なくなります。そのため、fast-follow を使うことで、インストール率やストアのコンバージョン率が上がります。さらに、最大 80% のデバイスで ASTC がサポートされているので、テクスチャ圧縮形式のターゲット指定を使ってサポート対象のデバイスに ASTC を配信できます。これにより、利用可能なハードウェアやデバイスのストレージを効率的に利用しつつ、幅広い Android デバイスをターゲットにすることができます。
App Bundle を使う場合、今後も複数の配信チャンネルやアプリストアで公開できますか？
可能です。これを実現する方法はいくつかあります。すべての場所で同じアプリ署名鍵を使うことも、チャンネルによってアプリ署名鍵を使い分けることもできます。Google Play 用の一意なアプリ署名鍵を使うこともできます。また、ローカルですべての配信チャンネル用のアーティファクトをビルドして署名することも、Google Play から配信用 APK をダウンロードして別のチャンネルで使うこともできます。Google Play Console の App Bundle エクスプローラまたは Play Developer API のいずれかを使用して Google Play からダウンロードした配信用 APK は、Play アプリ署名鍵で署名されます。
新しいアプリをリリースしようとしています。アプリ署名鍵を自分で決めることはできますか？
可能です。このオプションは Google Play Console で利用できます。新しいアプリを作成するときには、Google が使うアプリ署名鍵の提供方法を選択できます。アプリ署名鍵のコピーは、ローカルで保持できます。たとえば、Play バージョンと同じ鍵を使って署名し、他のチャンネルで配信する署名済みのバージョンを生成できます。近日中に、Play Console でのアプリの初回リリースが少しばかり簡単になる予定です。具体的には、初めてオープン トラックに公開する前であれば、操作を誤った場合でもアプリ署名鍵を変更できるようになります。
Google Play でアプリを配信する場合、アプリが意図したとおりにユーザーに配信されていることを確認するにはどうすればよいですか？
いつでも、Play Console の App Bundle エクスプローラか、Play Developer API を通して、Play ストアからアーティファクトをダウンロードして検証できます。さらに、新しいオプション機能である App Bundle のコードの透過性機能を使うと、デバイスで実行されるコードが、デベロッパーがビルドして署名したオリジナルのコードと一致するかどうかを検証できます。
既に Google Play でアプリを公開しています。既存のアプリ署名鍵のコピーを提供せずに Play アプリ署名を使うことはできますか？
現在のところ、Play アプリ署名を使うには、既存のアプリ署名鍵のコピーを提供する必要があります。既存のユーザーに配信する際に、Google Play でアップデートに署名するため、Google Play がコピーを保持する必要があるためです。これはほとんどのデベロッパーにとって適した方法で、100 万以上のアプリが Play アプリ署名を実際に利用しています。近日中に、鍵のアップグレードを行って Play アプリ署名をオプトインする追加オプションを既存アプリ向けに追加する予定です。このオプションを選択すると、すべての新規インストールとそのアップデートの際に、Play アプリ署名で新しい一意の鍵が使われます。ただし、これを動作させるには、App Bundle をアップロードする際に、古い鍵で署名した以前の APK もアップロードする必要があります。これが必要なのは、Google Play が既存ユーザーへのアップデート配信を継続できるようにするためです。
アプリ署名鍵は変更できますか？
可能です。アプリによっては、Play Console で新規インストール用のアプリ署名鍵のアップグレードをリクエストできます。Google Play では、新規インストールとアプリのアップデートの署名に新しい鍵が使われます。一方、鍵のアップグレード前にアプリをインストールしたユーザーへのアップデートでは、以前のアプリ署名鍵が使われます。近日中に、Play アプリ署名鍵のアップグレードにも APK 署名スキーム v3 の鍵ローテーションのサポートを追加する予定です。これにより、鍵のアップグレードが現実的なオプションとなるアプリが増え、アップグレードした鍵で署名されたアプリがさらに多くのユーザーに届くようになります。
Reviewed by Hidenori Fujii - Head of APAC Developer Marketing, P&E
