サイバーエージェントは、コンバージョン率向上に向け、ユーザー評価の重要性に着目し、『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 に継続的に関心を寄せていただき、ありがとうございます。皆さんと共同で、ユーザーのためにすばらしいカメラ体験を作成できることが楽しみです。
この記事は Nimrod Levy による Android Developers - Medium の記事 " Go Global at Ramadan " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
世界中のデベロッパーはラマダンの間、この聖なる月を祝う多くの国で、人々のアクティビティが増加することを知っています。これは、ゲームのエンゲージメントを高め、収益化を加速し、大きな成功につなげるための絶好の機会です。
ラマダンは、イスラム暦の 9 番目の月です。世界中のイスラム教徒は、この月を断食、祈り、内省、そしてコミュニティとの関わりを深める月としています。イスラム暦は太陰暦なので、西暦でのラマダンの日付は毎年変わります。2022 年のラマダンは、4 月 2 日から始まり、5 月 1 日に終わります。ラマダンの終わりである 5 月 2 日はイード・アル＝フィトルと呼ばれ、19 か国で祝日となっています。
World Population Review (英語) によると、2021 年のイスラム教徒の人口は約 19 億人でした。つまり、世界の人口の約 24% がラマダンを祝っています。ほとんどのイスラム教徒は、中東か東南アジアに住んでいます。たとえばインドネシアは世界最大のイスラム教国で、全イスラム教徒の 13% が住んでいます。
ラマダンの期間中は、魂を清め、自制心と統制心を鍛えるため、夜明けから日没まで飲食を控えます。また、家にとどまって仕事を減らすので、自由な時間が増えることが多くなります。この行動によって、たくさんの国でデジタル アクティビティが増えることになります。そして多くの場合、その中心はゲームです。たとえば eMarketer によると、インドネシア人の 44% は、ラマダン最初の週のデジタル アクティビティにオンライン ゲームを選んでいます。
この市場もまた巨大です。Newzoo によると、2021 年時点で、アジアや中東のイスラム教国（インドネシア、マレーシア、パキスタン、バングラデシュ、サウジアラビア、トルコ、アラブ首長国連邦、エジプト）には約 3 億人のモバイル プレーヤーがおり、43 億 2,000 万ドルのモバイル収益を生んでいます。
Google Play では、中東、アフリカ、東南アジアでゲームに支出した人は前年比 20% 増加しています。ラマダンの効果（2021 年）に目を向ければ、ラマダン前の 31 日間と比べて、ラマダン中のゲームの実績は次のようになっています。
過去 2 年間の地区別のラマダンの効果にも注目してみました。2020 年の方が大きく増加しているのは、COVID-19 によるロックダウンの影響だと考えられます。
インドネシア、マレーシア、バングラデシュ、パキスタンのラマダン期間中の実績は次のようになっています。
トルコ、サウジアラビア、アラブ首長国連邦、カタールのラマダン期間中の実績は次のようになっています。
つまり、ラマダンの期間中にイスラム世界のプレーヤーとエンゲージする方法を探すことで、大きな成果を得られる可能性があるのです。
ラマダンの期間中にプレーヤーのエンゲージメントを最適化する取り組みは、基礎を正しく理解するところから始まります。次に、プレーヤーに特典を与える方法を探し、皆さんが提供するものをプレーヤーに知ってもらうためのプロモーションをします。
ラマダン中の実績を上げる前に、プレーヤーが確実にゲームを見つけ、すべての機能を利用できるようにする必要があります。具体的には、次のようにします。
ラマダンの期間中にプレーヤーのエンゲージメントを高める最高の方法は、この月に特典を与えることです。以下に例を示します。
ラマダンの間に何か特別なことをする場合は、ユーザーにそれを知ってもらうようにします。そのため、ゲーム内プロモーションに加えて、以下を行うことを検討します。
ヒント : こういった活動においては、プレーヤーがラマダンの期間中に断食していることを意識してください。食べものや飲みものを見せることは避ける必要があります。
Tamatem Inc. (英語) は、エンゲージメントと収入を高めるため、2020 年のラマダンに合わせて Fashion Queen (アラビア語) の環境やプロモーションを調整し、ゲームのアイコン、Play Store のプレビュー、読み込み画面、BGM、衣装、周囲の装飾をラマダンを祝うものに変更しました。さらに、この月には、ラマダンをテーマにした限定の衣装やイベントを含めた LiveOps をしました。
こういった取り組みによって、ラマダン期間中のユーザー当たりの平均セッション時間が 20%、サブスクリプションによる収益が 12% 増加しました。
「ラマダンは 1 年で最も期待できる季節です。この月の LiveOps プロモーションやオファーでは、通常 50% の収益増加と、ユーザー エンゲージメントの増加を期待できます。私たちは、この特別な月に最高のエクスペリエンスを提供できるように、何か月も前から計画を立てています」と Tamatem のプロダクト マネージャーである Dina Rashdan 氏は語っています。
2020 年、LilithGames が「Rise of Kingdoms (英語) 」で作成した特別なラマダンのギフトバンドルは、プレーヤーの間で好評でした。
2020 年の成功を受け、2021 年には、Stars and Moons というラマダンをテーマにしたパッケージを作成しました。このテーマパックには、Islam Theme Frame、Tome of Knowledge、Dazzling Starlight Sculpture などのアイテムが含まれていました。パッケージの名前とアイテムは、ラマダンを連想するものです。たとえば、三日月と星はイスラムの重要なシンボルで、新月の三日月はラマダン期間中の断食の始まりと終わりを表します。
「ラマダンは、私たちの重要な季節のオファーの 1 つです。2020 年のラマダンをテーマにした IAP パッケージでは、東南アジアで 7 日間の平均課金額が 40% 増加しました。」LilithGames のオペレーション チームはそう述べています。
Moonton は、「モバイル·レジェンド: Bang Bang (英語) 」に登場する多くのゲーム内素材をローカライズし、ラマダン期間中にゲームと中東のコミュニティとのつながりを強めました。更新したゲームの要素は、以下のようなものです。
2021 年にこのような変更をした結果、初回ダウンロードが 15%、日々のアクティブ ユーザー数が 6% 増加しました。
「プレーヤーがゲーム内文化要素に満足することで、ロイヤルティが高まってより楽しんでもらえるようになります。その結果、長期にわたって健全に「モバイル·レジェンド: Bang Bang」を楽しんでもらえるようになります。」— Moonton オペレーション チーム
MENA LiveOps にとって、この聖なるラマダンの月は 1 年で最も重要なイベントのため、Babil Games は入念に準備を進めます。同社のゲーム「Nida Harb 3: Alliance War (アラビア語) 」では次のような計画に至りました。
こういった取り組みの結果、2021 年のラマダン期間中に、IAP による収益が 48%、日々のアクティブ ユーザー数が 6% 増加しました。
「私たちは常に、MENA のプレーヤーにローカライズされた最高のコンテンツを提供することに集中しています。聖なる月にふさわしいすばらしいテーマやカラーパレットによって、ラマダンは私達がステップアップするチャンスを与えてくれます。」Babil Games の統括マネージャー、Hisham Haddad 氏
ラマダンは、イスラム世界でゲームを大きく成功させる絶好の機会です。このガイドのベスト プラクティスに従えば、ユーザーを増やし、エンゲージメントを高めることができるはずです。
さらに詳しく知りたい方は、ゲームを成功に導く一般的な方法を紹介した投稿、中東と北アフリカでアプリやゲームを成功させる (英語) をご覧ください。
この記事は 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 でお伝えしますので、ご注目ください。
.png)
.png)
.png)
.png)
.png)
