Firebase を活用しているマッチングアプリ「タップル」の事例が、昨年公開した Android Developers サイトに加え、今日、新たに Firebase の Web サイトに掲載されました。

タップルは 2018 年にリリースした新しい定期購入プラン「プレミアム プラン」とランディング ページを最適化するため、Firebase の複数のソリューションを活用して 7 日間の A/B テストをしました。

Firebase Remote Config を使用することで、アプリの新バージョンをリリースすることなく、定期購入のプロンプトを動的に制御・変更することができ、Firebase A/B Testing では、最もパフォーマンスが良い有料会員サービスの推奨タイミングを把握。また、Firebase Crashlytics を使用してアプリの安定性を管理し、テスト中に何か問題が発生した場合には Remote Config を使用して迅速かつ簡単に機能をロールバックすることができました。

Firebase には、アプリの開発や最適化に役立つさまざまな機能が含まれています。公開済みのアプリでも、タップルのようにサービスを止めずに A/B テストを実施してその結果を評価できます。まだ Firebase をお使いになったことがない方は、ぜひこちらからお試しください。


Posted by Taro Sotome - Japan Apps Business Development and Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems

この記事は Krish Vitaldevara による Android Developers Blog の記事 "Tips for getting your app approved for background location access" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

私たちは、ユーザーのプライバシーを守るため、データアクセスにおけるユーザーコントロールと透明性を向上させる努力を重ねています。ユーザーからは一貫して、位置情報データに対する制御を強化して欲しいという声が寄せられています。そこで今年は、いくつかのプライバシーの改善策についてお知らせしました。たとえば、Google Play の位置情報アクセス許可ポリシーを改定し、Android 11 で位置情報のアクセス許可制御を強化しました。 

バックグラウンドでの位置情報への不必要なアクセスを避けるため、改定したポリシーでは、アプリのコア機能に不可欠で、ユーザーに明らかなメリットを提供する場合に限り、アクセスが許可されます。バックグラウンド位置情報をリクエストするアプリの多くは、実際にはその情報を必要としないことがわかっています。この機能を削除するか、フォアグラウンドに変更すれば、アプリの電池効率向上に繋がりますし、位置情報を共有したくないユーザーから低評価を受けてアプリの評価が低くなることも回避できます。

バックグラウンド位置情報データを使っているアプリを Google Play に公開し続ける、または新規に公開するためには、必要情報をフォームに入力して審査を受け、2021 年 1 月 18 日までに承認を得る必要があります。ただし、2020 年 4 月 16 日より前に初公開されたアプリの手続きの期限は、2021 年 3 月 29 日となっています。 

アプリの審査を円滑に進めるためのヒント

• アプリの複数の機能でバックグラウンド位置情報を使っている場合は、ユーザーに最もメリットを提供できる機能を 1 つ選び、（フォアグラウンドでなく）バックグラウンド位置情報が必要な理由と、その使用方法を詳しく記述してください。詳しくはこちらをご確認ください。
  
  
• ユーザーがアプリ内でどのように位置情報へのアクセスを許可し、位置情報を使用した機能を有効化して、その機能を利用するのかがわかるような短い動画を含める必要があります。動画でこれが説明されていない場合や、動画へのリンクにアクセスできない場合、リクエストは承認されません。動画は YouTube か Google Drive にアップロードすることをお勧めします。
  
  
• アプリ内で明確な開示を行い、どのデータがどのように使用されるのかをユーザーに説明することを忘れないようにしましょう。詳しくはこちらの動画（英語）をご覧ください。
  
  
• プライバシー ポリシーが明確に表示され、位置情報データの使用方法が詳しく書かれていることをご確認ください。詳しくはこちらのサポートページをご覧ください。

参考情報

詳しい内容をご説明している動画（英語）と Google Play Academy の無料のトレーニング コース（英語）を作成しました。アプリで必要なアップデートを行う際にぜひご確認ください。プライバシーに関するベスト プラクティスと技術情報もご覧ください。コードでバックグラウンド位置情報を使っている可能性がある部分を特定する方法を確認できます。

Google Play をユーザーのプライバシーを尊重するアプリとプラットフォームを構築するため、ご理解とご協力をよろしくお願いします。

Reviewed by Konosuke Ogura -  Trust & Safety - Play & Android, Global Policy & Operations Lead and Hidenori Fujii - Google Play Developer Marketing APAC

Android と Google Play は多くの皆さまに支えられ、成長を遂げることができました。これからも日本のデベロッパーの皆さまが、Android や Google Play に関する情報を日本語で、そしてさらに簡単に必要な情報にアクセスできるよう、Android Developer Japan Blog （日本語）を 本日 2020 年 11 月 2 日からスタートしました。

Android と Google Play の情報をより探しやすく

特定の製品情報を探しやすくするために、2020 年 11 月以降、Android と Google Play の情報は Android Developers Japan Blog をメインのブログとして情報掲載を開始します。Android と Google Play の情報をお探しの方は、Android Developers Japan Blog を今後ご覧ください。

Android と Google Play に関する日本のデベロッパー様向けの情報のお届け

日本で開催される Android と Google Play 関連のイベントやキャンペーンなどの日本のデベロッパー様向けの情報を随時発信していきます。

Android と Google Play の機能を活用できる情報を充実

製品情報、新規機能やポリシーの変更などだけではなく、Android と Google Play をより活用するための事例や分析方法、マーケティングの情報なども順次掲載していきます。

Android Developers Japan Blog をぜひご覧ください。

Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems

この記事は Steve Suppe による Android Developers Blog の記事 "Optimize your app publishing process with new Google Play Console features" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

アプリやゲームの公開は、アプリのライフサイクルの中でも特に重要な瞬間です。本番リリースを安定させ、テストリリースをすばやく公開し、マーケティングに関してのメッセージに適切に掲載するなど、すべてをスムーズに行う必要があります。そのためには、 アプリのステータスが見えることが重要です。Google Play でアプリの審査がいつ行われ、いつ承認され、いつ公開できる状況になるのかを把握できれば、リリース スケジュールを立てやすくなります。

新しい Google Play Console の 2 つの新機能で、それを可能にしました。[公開の概要] ページでは、アプリの公開が完了するまでの流れを把握しやすくなりました。また、管理対象の公開を利用すると、Google Play でアプリのアップデートを公開するタイミングを細かく制御できます。11 月 2 日に新しい Play Console が全ユーザーに適用されると、これらの機能がリリースのタイミング管理の推奨方法になります。この記事では、アプリの公開管理機能を詳しくご説明します。

公開の概要

新しい [公開の概要] ページには、リリースやストアの掲載情報などに対する最近の変更がすべて表示されます。これには、現在審査中の変更や、Google Play が処理中の変更も含まれます。大規模なチームに所属している方は、すべての変更を 1 か所で管理して同時に公開できるようになります。

公開の概要は、デベロッパーのアクティビティ ログとは異なり、Google Play での表示上の変更や、アプリの審査に関わる、国・地域やアプリのコンテンツ等の変更しか表示されません。

[審査中の変更] セクションでは、まだ公開されていない変更をすばやく確認できる

変更は、変更の種類やリリース トラック別に整理されているので、一目で簡単に把握できます。

管理対象の公開

旧 Play Console の時間指定公開機能をよくご存知の方も多いでしょう。新しい Play Console では、「時間指定公開」が「管理対象の公開」に変わりました。これにより、公開の操作がさらにわかりやすく、思いどおりに動作するようになります。

管理対象の公開を有効にすると、審査で変更が承認されて処理が完了した後に自動的に公開されるのではなく、[確認して公開] 後にのみ公開されるようになります。公開を確定すると、数分以内にアップデートが Google Play に公開されます。これにより、リリース予定日よりもかなり早く変更を送信でき、公開日に対する制御を失わずに確認や変更の時間がとれるようになります。

どの変更が審査、承認されたかを確認する

管理対象の公開がオンになっている場合、[公開の概要] ページに 2 つのセクションが表示されます。1 つは承認されて公開の準備が整っている変更、もう1つはまだ審査中の変更です。

加えて、多くの方から寄せられたいくつかの改善要望にも対応しています。

•  一部の変更がまだ審査中であっても、承認済みの変更のみを公開できるようになっています。これまでの時間指定公開では、すべての変更が承認されるまで、どの変更も公開できませんでした。
  
  
• 管理対象の公開は、審査中の変更や公開準備が整った変更がある場合も含め、いつでもオンまたはオフにできます。管理対象の公開を使うために審査が終わるのを待つ必要はなくなります。
  
  
• 時間指定公開は [公開] をクリックするとオフになり、使用するたびに再度オンにする必要があります。管理対象の公開は、デベロッパーが手動でオフにするまでオンのままになります。

管理対象の公開がオンになっているかどうかは、左側のナビゲーション メニューで確認できる

近日中に、左側のナビゲーションの [公開の概要] の隣に管理対象の公開アイコンが表示されるようになります。これにより、Play Console のどこからでも管理対象の公開がオンかどうかを確認できます。

新しい Play Console の公開機能について詳しく知りたい方は、Play Academy のこちらのコース（英語）をご覧ください。まだ新しい Play Console を試していない方は、play.google.com/console にアクセスして、ぜひ管理対象の公開をお試しください。

Reviewed by Naoki Oyama - Partner Development Associate, Mai Kato - Product Excellence Lead, Google Play and Hidenori Fujii - Google Play Developer Marketing, APAC

この記事は Tom Grinsted による Android Developers Blog の記事 "All developers will get the new Google Play Console on November 2, 2020" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2020 年 6 月に新しい Google Play Console のベータ版の発表と、新機能のご紹介をいたしました。それ以後、多くのデベロッパーの皆さんに Play Console ベータ版 をお試しいただいています。現在、30 万人以上の方々に新しい Play Console ご利用いただき、たくさんのフィードバックを頂戴しながら正式版の開発を進めてきました。

そしていよいよ、Google Play Console がベータ版を卒業します。従来の Play Console は、2020 年 11 月 2 日以降は利用できなくなります。この日以降、お使いのPlay Console のアカウントにログインすると自動的に新しい Play Console が表示されます。

 

まだ試していない方は、今すぐ新しいバージョンに切り替えることをお勧めします。play.google.com/console にアクセスしてみてください。

 

新しい Play Console はレスポンシブ デザインになっているので、どんな端末でも利用できます。新しいナビゲーションが導入され、重要な機能を簡単に探して理解することができます。また、リリース ステータス、ユーザー獲得パフォーマンス、ポリシー変更に関するガイダンスについて深く理解できる機能も追加しています。

 

• ナビゲーションのリリースに関するエリアを改善しました。本番環境を一番上に表示し、テストトラックはすべてまとめました。内部アプリ共有は設定に移動しました。
  
  
• 各種ブラウザでのスピードやパフォーマンスを向上させました。
  
  
• 受信トレイを新たに導入しました。役立つ情報やポリシーのアップデート、お勧めの機能など、一人一人に合わせたメッセージが表示される場所です。
  
  
• 新しい公開の概要ページでは、レビューの変化を確認できます。管理対象の公開を使うと、承認済みの変更を実際にいつ公開するかを決め、リリースを管理できます。
  
  
• ユーザー獲得レポートは完全に再構築され、実績の時間変化がわかりやすくなっています。それに伴い、いくつかのコホートベースの指標を廃止したため、新しいコンソールでは利用できなくなります。このデータの履歴を保持したい方は、11 月 2 日までに古い Play Console からダウンロードしてください。詳細はこちら
  
  
• 検索を使って必要なページや機能を簡単に探せるようになっています。
  
  
• 既にお知らせしたとおり、すべての Play Console ユーザーで 2 段階認証が必須になります。詳細はこちら

 

新しい Play Console の詳細:

• こちらのブログ記事で新機能の概要をご確認ください。
  
  
• こちらの動画では、特に大きな変更点について詳しくご紹介しています。
  
  
• Google Play Academy のコース（英語）では、新しいコンソールに関する専門知識を得ることができます。
  
  
• 新しい Play Console 紹介ページでは、重要な機能の詳細を確認し、役立つ情報にアクセスできます。

 

いつもフィードバックにご協力いただきましてありがとうございます。新しい Play Console があなたのビジネスのお役に立つことを願っています。

Reviewed by Hidenori Fujii- Google Play Developer Marketing, APAC

この記事は Dom Elliott、Yafit Becher による Android Developers Blog の記事 "Recent Android App Bundle improvements and timeline for new apps on Google Play" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android App Bundle が Google Play でアプリやゲームを公開する際の実質的な標準となってから、2 年あまりが経ちました。現在の実環境では、60 万以上のアプリやゲームで App Bundle が使われており、Google Play のすべてのリリースの 40% 以上を占めています。App Bundle は、Google Play のトップ デベロッパーの 50% が使用しています。たとえば Adobe の場合、App Bundle を使って Adobe Acrobat Reader のサイズを 20% 削減しました。

最近リリースした Play Asset Delivery（PAD）は、App Bundle による大きなメリットをゲームにもたらします。PAD を利用すると、配信コストとゲームのサイズを減らしつつ、ユーザー エクスペリエンスを向上させることができます。Gameloft は、PAD を使ってユーザーの維持率を高め、以前のアセット配信システムの使用時に比べて新規プレイヤーが 10% 増加しました。App Bundle を使うために必要な Play App Signing に関するよくある質問や App Bundle のテスト方法に関するガイダンスを公開しています。本記事では、App Bundle の開発、テスト、公開に関する最近行われた改善について説明します。

Google Play での機能配信

App Bundle を使うと、カスタマイズ可能な各種配信オプションを備えた動的機能モジュールによってアプリ開発をモジュール化できます。モジュール化したアプリを構築する際には、動的機能モジュールやベース モジュールのリソースの縮小もできるようになっています。この機能は長く待ち望まれてきたもので、アプリのサイズを大幅に削減できる可能性があります。この機能は、現在 Canary 版となっている Android Studio 4.2 以降で試験運用版フラグ android.experimental.enableNewResourceShrinker=true を指定すると利用できます。

デフォルトでは、App Bundle が配布用 APK に変換される際にインストール時モジュールが自動的に組み込まれます（bundletool 1.0.0 以降）。つまり、各端末に配布する APK の数を減らしつつ、開発時にアプリをモジュールに分割できます。これにより、アプリのダウンロードやインストールにかかる時間が短くなります。インストール時モジュールには「削除可能フラグ」を設定することもできます。その場合、組み込みが行われなくなるので、モジュールの使用後に端末からアンインストールできるようになります。大きなモジュールが不要になった場合は、削除するとよいでしょう。アプリのサイズを減らすことで、アンインストールされる可能性が低くなります。

Android Studio 4.0 では、機能間の依存性が安定版になっています。そのため、動的機能モジュールが他の機能モジュールに依存するように指定できます。この関係を定義できることで、アプリで追加機能を解放するために必要なモジュールが存在することを保証でき、その結果リクエストが少なくなり、アプリのモジュール化が簡単になります。

アプリの配信のテストで実際のユーザーと同じ操作を行ってみることが不可欠です。内部アプリ共有を使うと、テストビルドを Play にアップロードし、アプリをダウンロードできる共有可能なリンクを生成できます。このリンクからアプリをダウンロードすると、アプリを Play にリリースしたときにユーザーに提供されるものと同じバイナリを取得できます。

Play Asset Delivery

Play Asset Delivery は、App Bundle のフォーマットを拡張し、Google Play で公開する単一アーティファクトのバイナリと合わせて最大 2 GB のゲームアセットを格納できるようにします。PAD を使うと、150 MB 以上のゲームは以前の拡張ファイル（OBB）ではなく、ゲームのバイナリと同じように Google Play の機能を使ってアセットを最新に保つようになります。さらに、圧縮や差分パッチの対応、ダウンロード サイズの最小化、アップデートの高速化も行われます。

1 つのベース モジュール、2 つの動的機能モジュール、2 つのアセットパックのある Android App Bundle の内容

アセットをユーザーに配信するタイミングに応じて、3 つの配信モードから選択できます。install-time は、最初のゲームのインストールとともに配信します。on-demand は、リクエストされたときにのみ配信します。fast-follow は、ユーザーがアプリを開く操作とは関係なく、ゲームのインストールが完了した直後に追加ダウンロードが行われます。fast-follow を使うと、最初のインタラクションまでの時間を短縮しつつ、アセットをできる限り早くユーザーに配信できます。

今後数か月のうちに、テクスチャ圧縮フォーマットのターゲット指定をリリースする予定です。これを使うと、複数のテクスチャ圧縮フォーマットのアセットを含めておき、リクエストする端末がサポートする最も高度なフォーマットを自動選択して配信できるようになります。

詳細については、Game Developer Summit のこちらのセッションをご覧ください。また、Unity、Unreal Engine、Gradle、ネイティブ、Java のサポート オプションについては、ドキュメントをご覧ください。

Google Play による高品質の配信

Google Play は、無数の種類の端末を使う世界中の Android ユーザーに、毎月数十億のアプリやゲーム、アップデート、動的機能モジュールを配信しています。私たちは、ユーザー エクスペリエンスが複雑にならないようにしつつ、皆さんのコンテンツをできる限りシームレスかつ効率的にユーザーに配信するため、多くの時間と労力を費やしています。

たとえば最近では、Google Play で利用しているダウンロード サービスをアップグレードしました。この変更だけで、App Bundle によるアプリのインストールが平均 6% 高速化され、世界のインストール成功率が 1% 上昇しました。その結果、毎週のインストール数は数百万回増加しました。

また、動的機能モジュールの配信に関する複数の改善をロールアウトしています。たとえば、アプリが VISIBLE 以上の場合にモジュールのインストールを許可する、ストレージ不足エラーのしきい値となる空き領域を下げる、大きな動的機能を Wi-Fi でダウンロードする際のユーザーの確認を省略するなどです。これだけで、モジュールの遅延ダウンロードの成功率が 12% 上昇しました。動的機能を使うアプリでは、自動的にこの変更によるメリットが得られます。

2021 年下半期の新規アプリ要件

引き続き、Google Play で App Bundle を APK よりも優れた公開フォーマットにするための作業に取り組んでいます。たとえば、新しい App Bundle Explorer を使うと、すべての App Bundle を 1 か所で管理できます。Play が配信用に生成する APK そのものや、別の配信チャンネルで使用できる署名されたユニバーサル APK（サポート対象の端末に必要なすべてのコードやリソースを含む 1 つのインストール可能 APK）をダウンロードして確認することもできます。

App Bundle がアプリやゲームのエコシステムに広く普及することを大変嬉しく思っており、今後もその改善を続けてゆきます。Android 11 のイベントでお知らせしましたが、今後の改善に向けた労力を集中させるため、2021 年の下半期には、Google Play で新しいアプリやゲームを公開する際に Android App Bundle の使用が必須になる予定です。同じタイミングで、以前の APK 拡張ファイル（OBB）のサポートを終了し、Play Asset Delivery が、150 MB 以上のゲームを公開する際の標準オプションになります。また、インスタント対応にはインスタント対応 App Bundle による公開を必須とし、以前の Instant App の ZIP フォーマットのサポートを終了する予定です。

既に Android App Bundle に切り替えてくださっている皆さま、また、フィードバックを共有してくださった皆さま、ありがとうございます。皆さまのご意見は、App Bundle の将来を形作り、あらゆる人に向けたテクノロジーを改善するために役立ちます。ぜひ今後も感想をお知らせください。

Reviewed by Yuichi Araki - Developer Relations Team

この記事は Scott Lin による Android Developers Blog の記事 "Leverage the In-App Review API for your Google Play reviews" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Play の評価とレビューは、多くのデベロッパーにとって重要なユーザーとの接点です。Google Play には、毎日無数のレビューが登録されます。評価とレビューはユーザーが何を好み、どのような改善を求めているのかを知る貴重な知見であり、ユーザーは評価やレビューを参考にして、どのアプリやゲームが自分の好みに合うかを判断します。

ここ 2 年以上にわたって、ユーザーがレビューを登録しやすくし、デベロッパーがレビューを確認して返信しやすくなるように、Google Play にさまざまな機能をリリースしてきました。たとえば、ユーザーは Google Play のホームページからレビューを登録できるようになっています。また、My Apps & Games にレビューのページを追加したことで、ユーザーは 1 か所からレビューの登録や管理を行えるようになっています。

しかし、デベロッパーからのリクエストが特に多かったのは、ユーザーがアプリの詳細ページに戻ることなく、アプリ内からレビューを登録できるようにする機能でした。そこで2020年 8 月 5 日（日本時間 2020 年 8 月 6 日）新しいアプリ内レビュー API をリリースしました。

適切なタイミングでレビューを依頼する

デベロッパーがこの API を使うと、ユーザーにレビューを書いてもらうプロンプトをアプリ内に表示するタイミングを選択できます。ユーザーにプロンプトを表示する最適なタイミングは、有用なフィードバックを細かく残せるほどアプリを十分利用したときです。しかし、画面のアクションがレビューフローで置き換わってしまうため、タスクの途中や集中する必要があるときにユーザーの邪魔にならないようにしてください。

ユーザーはアプリ内で評価やレビューを登録できる

アプリがベータ版の場合、アプリ内レビュー API はパブリック レビューとプライベート レビューの両方をサポートします。

レビュー API は Play Core Library の一部です。このライブラリは、Java/Kotlin、C++、Unity 向けに配布されています。軽量の API が提供されており、ユーザーがアプリを離れることなく、レビューをリクエストしてレビューフローを起動することができます。
組み込みには、主に 4 つの手順が必要です。

1. レビューを依頼する条件と最適な場所を定義する
2. API にレビューフローをリクエストする
3. 適切なタイミングでレビューを起動する
4. レビューの完了後、フローを継続する

ユーザーがレビューを登録したかどうかにかかわらず、アプリはユーザーフローを変更することなく、継続する必要があります。アプリ内レビュー API は、ユーザーにとってシームレスな操作となるように設計されています。

実際のアプリ内レビュー API の動作は、新しく公開されたサンプルで確認できます。このサンプルは、アプリ内アップデート、オンデマンド機能モジュールのインストールなどの他の Play Core API とともに、Play Core Kotlin 拡張機能（KTX）ライブラリを通してこの API を呼び出しています。

より良いフィードバックを得る

この API を使うことで、ユーザーはアプリについての貴重なフィードバックを今までより簡単に共有できるようになります。ここでは、アーリー アクセス プログラムに参加した一部のパートナーの声をご紹介します。

「新しいアプリ内レビュー API を使うための変更は、短時間で簡単に組み込むことができました。変更をリリースすると、ほぼ即座に肯定的な評価やレビューが増えました」

- Calm、エンジニアリング マネージャー、Chris Scoville 氏

「アプリ内レビュー API を使うと、お客様はアプリを離れることなく評価を登録できます。API の実装後、スター 5 個の評価が 4 倍になりました」

- Tokopedia、テクニカル アーキテクト、Nathaniel Khuana 氏

「 アプリ内レビューを実装してわずか 1 週間後に、これまでで最高の評価を得ることができました」

- Traveloka、アソシエイト プロダクト マネージャー、Welly Chandra 氏







最も役に立つフィードバックは公平で率直な意見なので、この API は自己完結するように設計しました。API の呼び出し以外の追加のプロンプトは必要ありません。また、ユーザーがレビューを登録しないことを選んだ場合は、過度にプロンプトが表示されないように制限を設けています。

デベロッパーの皆さんには、アプリ内レビュー API の組み込みを検討することをおすすめします。熱心なユーザーが残してくれるようなフィードバックを得られるでしょう。また、そのようなレビューが投稿されたら、Google Play Console に備わっている評価やレビューに関する多くのツールを使って、レビューを分析したり、ユーザの懸念に直接回答したりすることができます。

Reviewed by Yuichi Araki - Developer Relations Team

この記事は Ben Weiss による Android Developers - Medium の記事 "Developer Tools on Play Console" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


開発とテストのワークフローをサポート

ヘッダー作成者: Virginia Poltrack

本記事では、Google Play Console を使ってアプリのバージョンをテスターやデベロッパーとすばやく安全に共有する方法について説明します。
また、過去のリリースへのアクセス、デバッグ可能なビルドをアップロードできる内部アプリ共有など、改善された機能についても紹介します。

まずは背景情報から

テスターへの APK の配信は、メールへの添付やファイル ストレージ サーバーへのアップロードを通じて、簡単に行うことができます。そうすると、テスターは APK をダウンロードしてスマートフォンにインストールできます。これは、ファイルを入手できるすべての人にも同じことが言えます。

そこで登場したのが、Android App Bundle（AAB）です。AAB は、Android 用のアプリ公開形式です。分割された APK を使って、必要なリソースのみを簡単にユーザーに提供でき、デベロッパーによる追加の作業も必要ありません。AAB はアプリの公開形式です。つまり、Google Play はエンドユーザーの端末に配信する一連の APK を生成します。そのため、エンドユーザーがインストールする厳密なアーティファクトをテストするのが難しくなります。ダイナミック配信やアプリ内アップデートなどの高度な機能を考慮する場合は、特にこれがあてはまります。

大規模なチームや複数の利害関係者、外部テスターと一緒に作業をしている方なら、インストール可能なアーティファクトを直接共有する方法を探していることでしょう。デベロッパー ツールをインストールしてコマンドを実行してもらうのは、現実的な方法ではないかもしれません。また、bundletool を使って Android App Bundle を APK に変換し、端末にインストールすることができたとしても、アプリ内アップデートやオンデマンド配信の実装はテストできません。

しかし、悩むことはありません。Play Console を使えば実現できます。

限定されたテスターによるアプリのテスト

Google Play Console は、限定されたユーザーとアプリを共有する複数の方法を提供しています。アクセスを制限するには、URL をオプトインする、特定のメーリング リストに参加する、Google Play ユーザー アカウントに関連付けられたメールアドレスを使って個別に設定する、のいずれかの方法を使います。

テストトラック

一般ユーザーではアクセスできない複数のトラックを使用することができます。つまり、誰がどの開発段階でアプリにアクセスできるかを厳密に決めることができます。各トラックの特に重要な違いを説明します。
内部テストトラック

• アプリ 1 つにつき、テスター 100 名まで
• 幅広いチームでリリース候補をテストする場合に最適
• 即座に利用可能

クローズド トラック

• 個々のユーザーまたはグループ全体を招待
• 一般公開前の組織規模でのテストに最適
• 公開前レビューが必要

オープン トラック

• 一般ユーザーが直接オプトイン可能
• 本番公開前の大規模なユーザーのグループによるテストに最適
• 公開前レビューが必要

上記のトラックに関する一般的な補足事項

上記のいずれかのトラックを経て本番環境に移行できるのは、1 つのバージョンのみです。

テストトラックで公開するアーティファクトには、Play Console でテスト プログラムをオプトインしたユーザーがアクセスできます。

各トラックには、1 つの Android App Bundle または 1 つの APK をアップロードできます。

内部アプリ共有の詳細

上記のトラックと合わせて、Play Console は特別なデベロッパー ツールである内部アプリ共有を提供しています。

内部アプリ共有の最も重要な特徴は、ここに APK または AAB をアップロードしても、Play Console で公開しているリリースには何の影響も与えないことです。つまり、内部アプリ共有をテストトラックや本番環境に直接移行することはできません。

また、デバッグ可能なアプリを内部アプリ共有にアップロードすることもできます。つまり、Play Console からインストールできるようになるビルドにデバッガーをアタッチすることができます。

さらに、新しいバージョンをアップロードするためにバージョン コードをインクリメントする必要はありません。そのため、開発用にバージョン コードを空けておいたり、バージョン コードが枯渇することを心配する必要はなくなります。アップロードしたアプリごとに異なるリンクを共有することで、お互いに干渉し合うことなく、独立して複数のバージョンをテストすることができます。

開発チームからアップロード担当者を認定することもできます。内部アプリ共有のみへのアクセスを許可することができ、Play Console の他の部分へのアクセス権を与える必要はありません。

ダウンロード可能者を認定するには、Play Developer Console の [Development tools] > [Internal app sharing] にアクセスします。リンクを共有するために、オプトインした人のメールアドレス一覧を使ってユーザーをホワイトリストに登録することができます。これにより、リンクを知っているすべての人がテストビルドを端末にダウンロードできるようになります。

注: 現在、端末上の複数アカウントに関する制限があることは承知しています。
これを回避するには、すべてのアカウントが内部アプリ共有にアクセスできるようにするか、メールアドレス一覧にないテスターも Play Console でダウンロードできるようにします。

内部アプリ共有で高度な機能をテストする

内部アプリ共有を使うと、実際の環境で本物のユーザーと同じ状態でダイナミック機能モジュールのオンデマンド インストールをテストすることができます。デバッグ可能なバージョンをアップロードすると、Android Studio でデバッガーをアタッチし、正しいコードが実行されているかどうかを確認することまでできます。

また、古いバージョンのコードを内部アプリ共有にアップロードすれば、アプリ内アップデートのテストも可能です。これを行うには、次のフローに従います。

1. 異なる versionCode 属性を持つ 2 つのバージョンを内部アプリ共有にアップロードします。
2. 内部アプリ共有 URL から、バージョンが低い方のアプリをインストールします。
3. バージョンが高い方のアプリのリンクを開きますが、ここではインストールは行いません。
4. 再度インストールしたバージョンを開きます。
5. アップデートが可能な旨が表示されます。

ただ、古いバージョンのアプリに簡単にアクセスでき、それをすぐに他のユーザーと共有できたらいいのにとは思いませんか？（ネタバレですね...）

過去のリリース機能の導入

過去のリリース機能を使うと、すばやく確実にアプリの古いバージョンにアクセスできます。
内部アプリ共有にアクセスできるユーザーは、本番トラックにアップロードされたすべてのバージョンにアクセスすることもできます。そのために知っておく必要がある情報は、リリースのバージョン コードとパッケージ名だけです。

この情報さえあれば、次の URL スキームからアプリの過去のバージョンをインストールできます。

https://play.google.com/apps/test/<package name>/<version code>

ただし、Bundle Explorer で認定テスターを管理する画面でも、バージョン コードとリンクを確認できます。[Internal app sharing] セクションには、特定のバージョンをインストールするために必要なすべての情報が表示されています。すべてを設定すると、この URL を使って過去の AAB や APK リリースをインストールできるようになります。

Play Console の過去のリリース機能

参考資料と次のステップ

さまざまな公開トラックや内部バージョンの共有に関するドキュメントをお読みください。
Wojtek Kaliciński がローカルでオンデマンド モジュールを開発およびテストする方法の概要を説明します。
また、テスト バージョンを簡単にアップロードできるように CI を設定する方法についての Marcel Pintó の投稿もご覧ください。
さらに、Android App Bundle が実現するその他の機能について、Google I/O と Android Dev Summit 2019 の 2 つの録画セッションで学習できます。

これで皆さんは、新しいバンドルをテストトラックにアップロードしたり、内部アプリ共有を使ったり、Google Play Console から直接過去のバージョンにアクセスしたりできるようになりました。

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Android Developer Advocate である Wojtek Kalicińskiによる CodeProject.com の記事 "How to Fix App Quality Issues with Android Vitals (Part 2)"を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

第 2 回: クラッシュや不要な wake lock の問題を修正して Play ストアでのパフォーマンスを改善する

Google Play Console の [Android Vitals] セクションを活用してアプリの品質の問題を修正し、成功を収めているデベロッパーがますます増えています。Google では、Android Vitals に関する最初の記事以降も改善を続け、新しい指標や機能を提供してきました。本稿ではまず新機能の概要を紹介し、続いて、停止した wake lock とクラッシュの問題を修正する方法を説明します。

Android Vitals の新機能

Google I/O 2018 で Android Vital の新機能を発表しました。今回の改善には、2 つのパフォーマンス領域の追加、既存の指標の情報に対する機能強化、Android Vitals で予期しない変化が生じた場合の通知方法が含まれています。

カテゴリのベンチマーク

アプリの指標の測定結果が「良好な」（低い）レベルとみなされるか、「不適切な」（高い）レベルとみなされるかは、Play ストアでそのアプリがどのカテゴリに含まれるかによって大きく左右されます。たとえば、「ボード」カテゴリのゲームアプリにおけるスタートアップの遅延の平均は、「レース」カテゴリのゲームアプリよりも低くなります。そのため、Android Vitals ではカテゴリのベンチマークが表示されるようになりました。これによりデベロッパーは、自分のアプリのパフォーマンスを同じカテゴリ内の他のアプリと比較できます。

異常の検出

アプリの動作の急激な変化は好ましいことではありません。そのような状況に迅速に対応できるよう、Android Vitals では、指標の急激な変化を検出すると Play Console のメッセージとメールを通じてデベロッパーに通知します。通知を受けたデベロッパーは Android Vitals にアクセスして状況を確認し、原因に対処できます。

権限の拒否

アプリによる権限リクエストを拒否したユーザーの割合が表示されます。拒否される割合が高い場合は、アプリのデザインを見直し、許可を求める理由の伝え方を改善するなどして、権限を許可してもらえるようになるかを確認することができます。

アプリのスタートアップ時間

優れた機能や素晴らしいゲームプレイ体験を提供していても、アプリの起動に時間がかかりすぎると、ユーザーはアプリを使わなくなります。新しく追加されたこのパフォーマンス領域には、アプリのスタートアップ時間に問題があるかどうかをデベロッパーが把握できるよう、対象のアプリやゲームについて、コールド スタートアップ（アプリが最近使用されておらず、メモリ内にキャッシュされていない場合）、ウォーム スタートアップ（アプリはメモリ内にあるが、アクティビティの再作成が必要な場合）、ホット スタートアップ（アプリとアクティビティがメモリ内にあり、ユーザーがそのアプリに切り替えた場合）の 3 種類のスタートアップ時間が表示されます。


Android Vitals でスタートアップに関する問題が見つかったら、Android Studio 3.2 の Android プロファイラ ツール（アプリスタート時の CPU プロファイリング、Systrace など）を利用して、スタートアップの遅延に関する問題を調べます。

主な指標

高品質のアプリを提供するためにはすべての指標が重要ですが、特に優先すべき指標として、過度の wakeup、ANR、停止したバックグラウンドでの wake lock、クラッシュの 4 つを挙げることができます。過度の wakeup と ANR については、第 1 回の記事で取り上げました。そこで、今回は wake lock とクラッシュについて見ていきます。

Wake locks

従来、Android でのバックグラウンド作業の実行は、必要に応じたバックグラウンド サービスの作成に依存していました。こうしたバックグラウンド サービスは必要な期間実行され続けたため、フリーランニング サービスと呼ばれることもありました。こうしたバックグラウンド サービスの実行中は、端末の CPU と通信がオフにならないようにするために wake lock が使用されていました。


このような形での wake lock の使用は最適ではありません。アプリによって頻繁にサービスのスケジュールが設定され、結果的にサービスが長時間実行されてメモリなどのリソースが占有されることがあります。このようにしてリソースを使用すると、CPU と通信の使用が増えるほか、端末がスリープ状態にならなくなることから、端末のパフォーマンス低下と電池の消耗を引き起こすことがよくあります。


Android Vitals では、アプリの PowerManager クラスを通じて取得した部分的な wake lock の詳細を、[停止した wake lock] ページと [停止した wake lock（バックグラウンド）] ページで提供しています。部分的な wake lock では CPU は動作しますが、画面やキーボードのバックライトをオフにすることができます。


レポートには、停止した wake lock の影響を受けたバッテリー セッション（端末の完全充電から次の完全充電までの期間）の割合が表示されます。この情報には、過去 30 日間とその前の 30 日間に影響を受けたセッションの割合、アプリの指標を Google Play のインストール数上位 1,000 のアプリと比較したベンチマーク、影響を受けたセッションの推移を示したグラフのほか、アプリのバージョン、Android OS のバージョン、端末などの条件に基づく内訳（スクリーンショットには表示されていません）が含まれています。

このベンチマークにおいて、自分のアプリが、停止した wake lock の影響を受けたセッションの指標で下位 25% に該当する場合は、アプリの改善を検討してください。

第 1 回の記事でもお伝えしたように、Android 5.0 での JobScheduler の導入以降、アラームとフリーランニング サービスの使用を取りやめることをおすすめしています。Android Oreo 以降、アプリはバックグラウンドでサービスを開始できなくなったため（例外が発生します）、アラームとフリーランニング サービスの使用の取りやめは必須となります。同様に、アプリでの wake lock の使用についても、ほとんどの使用例で適切な代替手段があるため、取りやめることを検討してください。wake lock を使用する代わりに、アプリで以下の方法を採用することをおすすめします。

• バックグラウンドでのジョブの実行が必要な場合は、JobScheduler か WorkManager API を使用する。こうした機能を使用すると、ジョブが実行されている間だけ、そのジョブの wake lock が保持されます。

• 決められた時間に、または定期的にバックグラウンド タスクを実行する必要があるときは、AlarmManager ブロードキャストをスケジュールする。AlarmManager は、BroadcastReceiver.onReceive() メソッドが実行されている間だけ、wake lock を保持します。

• ユーザーがアプリのアクティビティを見ている間も画面をオンにしておきたいウィンドウがある場合は、該当するウィンドウに FLAG_KEEP_SCREEN_ON を追加する。たとえば、電子書籍を読んでいるときなどが該当します。これにより、アクティビティが表示されなくなったときに、システムによって wake lock が解放されます。

自分で wake lock を管理する必要がある場合（実行時間の長いフォアグラウンド サービスを使用して音声トラックを再生する場合など）は、必ず以下のルールに準拠してください。

• 非推奨の種類の wake lock は使用せず、PARTIAL_WAKE_LOCK を使用してください。

• wake lock を取得するときはタイムアウトを指定してください。そうすることで、アプリが wake lock を解放しない場合でも、タイムアウト時間が経過するとシステムによって wake lock が解放されます。

• wake lock には、com.myapp: my wake lock のように静的でわかりやすいタグを付けてください。それにより、Android Vitals の wake lock のレポートがわかりやすくなります。カウンタやその他の動的なデータをタグに追加しないでください。適切でわかりやすいタグを付けることで、類似する wake lock が Android Vitals によってまとめられ（組み合わされ）て、個別の wake lock の動作を正確に把握できるようになります。

• wake lock は不要になったら解放してください。wake lock は、エラーの発生によっても不要となることがあります。エラー処理にあたっては、安全性を重視してコードを記述し、呼び出しを try { … } finally { wakeLock.release(); } のブロックでラップすることをおすすめします。

クラッシュ

Android Vitals ではクラッシュの概要と詳細の両方を確認できます。[クラッシュ発生率] ページと [マルチ クラッシュ率] ページでは、クラッシュ データと使用状況データを組み合わせて正規化された指標が表示されます。

この概要情報に加えて、[ANR とクラッシュ] ページにリアルタイムのクラッシュの詳細が表示されます。

停止したバックグラウンドでの wake lock と同様に、クラッシュ率を比較するための主な指標として「不正な動作のしきい値」があります。アプリのクラッシュ率が不正な動作のしきい値を超えている場合、クラッシュへの対処を優先することをおすすめします。


コードが例外を引き起こしてアプリをクラッシュさせる理由は数多くあります。そのため、本稿でそのすべてを説明して解決策を提示することは困難ですが、クラッシュを防止するのに役立つ一般的なアドバイスをいくつかご紹介します。


Android Vitals を利用して、頻発しているクラッシュに関する情報と、そのクラッシュの影響を受けているユーザー数を確認できます。Android Vitals の大きな利点は、発生したクラッシュを、第三者のクラッシュ レポート SDK が初期化されるよりも前に捕捉できることです。

クラッシュの再現、デバッグ、修正のために詳細な情報が必要な場合は、Firebase Crashlytics の利用をご検討ください。このツールを使うと、クラッシュ時にアプリ内で何が起きているかを詳しく把握できます。Firebase Crashlytics では Firebase Analytics との統合によってこの機能を実現しており、デベロッパーはカスタムのログ記録を追加してクラッシュ レポートに含めることができます。


クラッシュを引き起こす一般的な原因の多くは、以下の方法で回避できます。

• 一般的な処理を自力でゼロから記述しない
• Kotlin に移行する
• 公開 API を使用する

一般的なコードパターンを自力でゼロから記述しない

クラッシュを引き起こす可能性がまずない高品質のライブラリが提供されていて、簡単に再利用できる場合、一般的なタスクを自力でコーディングしてミスを犯すリスクを取る必要はありません。

Android Jetpack には、ほとんどの Android アプリの基盤として利用できるライブラリが数多く用意されています。Android Jetpack は、アクティビティのライフサイクルの管理、ナビゲーション、バックグラウンド ジョブの実行、データベースの操作、外部ソースからのデータの読み込みなど、数多くの一般的なタスクに利用できます。Google の開発したライブラリ以外にも、デベロッパーがアプリの開発に利用できる、実績ある優れたオープンソース ライブラリが数多く公開されています。

Java から Kotlin への移行を検討する

Google は昨年の I/O において、Android での Kotlin のサポートを発表しました。現在も引き続き、Kotlin のサポートの改善に取り組んでいます。クラッシュにつながるおそれのある一般的なコーディングのミスを少しでも防ぐことで、デベロッパーの生産性を高めることが最終目標です。


Kotlin の大きな利点の 1 つは、null 許容性についての情報が言語の型システムに組み込まれていることです。null セーフの呼び出しとコンパイル時の null チェックにより、コードが実行時に NullPointerException を引き起こすことを防止できます。まだお試しでなければ、Kotlin を使ってみることをおすすめします。アプリには Kotlin を徐々に追加していくことができます。Kotlin は Java との高い相互運用性を備えているため、Java のコードを全面的に置き換える必要はありません。

公開されている Android API を使用する

公開されている Android API とは、Android デベロッパー サイトにドキュメントが掲載されているクラスと public メソッドを指します。こうした API は、認定済みのあらゆる Android 搭載端末での利用と動作が保証されています。リフレクションを使ってアクセス可能な private メソッドや hidden メソッドは、クラッシュを引き起こす大きな原因となるおそれがあります。こうしたメソッドには、端末で利用できるかどうかの保証がなく、また、Android のアップデートのたびに変更や中断が生じることが多いという問題があります。そのため、テスト用としてはともかく、Play ストアで公開するアプリへの使用は避けることをおすすめします。


private メソッドや hidden メソッドには上記のような問題があるため、Android P デベロッパー プレビューおよび今後の Android のすべてのエディションでは、このようなドキュメント化されていない非公開 API へのアクセスが制限されます。アプリでのこうした API の利用を直ちに停止することで、互換性を維持できます。詳しくは、プレビュー サイトで非 SDK インターフェースの制限についての記事をご覧ください。

おわりに

Android Vitals を活用して高品質のアプリを開発し、より多くのユーザーを引き付けて定着させることで、活気のあるビジネスを構築できます。全 2 回にわたる記事で、過度の wakeup、ANR、停止したバックグラウンドでの wake lock、クラッシュという 4 つの主な指標についての重要な情報をお伝えしました。また、最近 Android Vitals に追加された機能もご紹介しました。

この記事で紹介したおすすめの方法や詳細情報を活用することで、デベロッパーの皆様が Android Vitals に表示されるアプリの指標を的確に理解して、アプリの品質向上に役立てられるよう願っています。

詳細については、Google I/O 2018 でジョエル ニューマン、ファーガス ハーレイ、筆者の 3 名が共同で実施したセッション「Android Vitals: パフォーマンスの問題を解決してアプリの評価を高める」の動画をご覧ください。また、Medium に掲載されている、Google Play の Android アプリおよびゲームに関するおすすめの方法についてもご参照ください。

ご意見をお聞かせください

Android Vitals や新機能についてご意見がございましたら、#AskPlayDev を付けてツイートしていただければ、@GooglePlayDev から返信いたします。このアカウントでは定期的にニュースや Google Play で成功するためのヒントを紹介しています。

Reviewed by Iku Igarashi - Google Play Business Development Manager

この記事は Android Developer Advocate である Wojtek Kaliciński による CodeProject.com の記事 "How to fix app quality issues with Android vitals and improve performance on the Play Store (Part 1)" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

「アプリケーション応答なし」イベントと「過度の wakeup」という安定性に関する主要な 2 つの問題を詳しく分析して、アプリの機能と品質を向上します。

はじめに

この記事は CodeProject のスポンサー向けの「Product Showcase」セクションに掲載されているものです。同セクションの記事は、デベロッパーにとって役立つ有用な製品やサービスに関する情報の提供を目的としています。

アプリのデベロッパーにとって、ユーザーの満足度が高いことに勝る成功の指標はありません。この目標を達成する最善の方法は、ユーザーが利用したくなる優れたアプリを提供することです。「優れた」アプリとは一体何を指すのかというと、機能とアプリの品質の 2 つに要約されます。前者は最終的にデベロッパーの創造力とビジネスモデルの選択に左右されるのに対し、後者は客観的に測定して改善することが可能です。

昨年 Google が実施した社内調査によると、Play ストアの 1 つ星レビューの 40% 以上で指摘されていたのは「アプリの安定性」の問題でした。一方で、品質やパフォーマンスの良いアプリは高く評価されて好意的なレビューが付けられ、その結果 Google Play でのランキングが向上し、インストール数の上昇につながっています。それだけではなく、ユーザーはこうした高品質のアプリに、より多くの時間とお金を費やす傾向にあります。そのため、アプリの安定性に関する問題の解決が、アプリの成功に大きな影響を及ぼします。

客観的な品質の指標を提供し、アプリの安定性に関する問題をデベロッパーが簡単に特定して対応できるよう、Google では Play Console に [Android Vitals] セクションを新たに追加しました。このセクションでは、アプリのパフォーマンスと安定性に関する問題を確認できます。コードに新たな測定ツールやライブラリを追加する必要はありません。アプリがさまざまな端末上で実行されている間、Android Vitals はアプリのパフォーマンスに関する匿名の指標データを収集して、幅広い規模の情報をデベロッパーに提供します。同じような規模の情報を他の方法で収集することは難しく、たとえハードウェア ラボでテストを実施したとしても困難です。

Android Vitals がデベロッパーに通知できる問題には、クラッシュ、アプリケーション応答なし（ANR）、レンダリング時間などがあります。こうした問題はいずれも、ユーザーの利便性とアプリに対するイメージに直接影響します。さらに、ユーザーが特定のアプリと直接結び付けない可能性のある、アプリの不正な動作のカテゴリが 1 つ存在します。電池の消耗が予想以上に早い場合がそれに該当します。

この記事では、次の 2 つの問題について詳しく見ていきます。

• 過度の wakeup : 電池寿命に影響を与え、すぐに端末を充電できない場合はユーザーの端末の利用を妨げることがあります。この種の動作は、ユーザーがアプリをすぐにアンインストールする原因となる可能性があります。
• アプリケーション応答なし（ANR）イベント : こうしたイベントは、アプリの UI がフリーズしたときに記録されます。フリーズの発生時にアプリがフォアグラウンドで動作していれば、ユーザーに対して、アプリを閉じるか、アプリから応答があるまで待つかを尋ねるダイアログが表示されます。ユーザーの視点からは、この動作はアプリがクラッシュしたのと同じです。アプリがすぐにアンインストールされるとは限りませんが、ANR が続くと、ユーザーが別のアプリを探す可能性は高くなります。

過度の wakeup

まず、wakeup とはどのようなもので、どのような場合に「過度」になるのでしょうか。

電池寿命を延ばすために、Android 搭載端末では画面がオフになると、メイン CPU コアをオフにしてディープ スリープモードに入ります。ユーザーが端末を復帰させない以上、端末をできるだけ長くスリープモードにしておくことが望ましい状態です。ただし、アラームが鳴ったときや新しいチャット メッセージが届いたときのように、CPU を復帰させてユーザーに通知することが重要なイベントもあります。

こうした通知は wakeup アラームで処理できますが、後で説明するとおり、この方法は使用しないでください。wakeup は、ユーザーの注意を重要なイベントに引き付ける良い手段のように思われますが、wakeup の回数が多すぎると電池寿命に影響を与えます。

Android Vitals では過度の wakeup がどのように表示されるか

アプリの wakeup 回数が多すぎるかどうかは、Android Vitals で簡単に確認できます。アプリの動作について収集した匿名の指標データを使用して、端末がフル充電されてからの 1 時間あたりの wakeup が 10 回を超えるユーザーの割合が表示されます。赤いアイコンが表示されていないか確認することが重要です。このアイコンは、アプリが不正な動作のしきい値を超えていることを示します。このしきい値は、対象のアプリが Google Play で動作に問題のある一連のアプリの中に含まれており、動作を改善する必要があることを表します。

wakeup アラームの代替手段

一定時間の経過後や特定の時刻に端末を復帰させる主な方法として、AlarmManager API を使用して RTC_WAKEUP フラグや ELAPSED_REALTIME_WAKEUP フラグでアラームをスケジュールする方法があります。この機能はなるべく使用せず、他のスケジューリング方法や通知方法ではうまく機能しない場合にのみ使用することが重要です。wakeup アラームの使用を検討している場合は、以下の点を考慮してください。

• ネットワークからデータを受信した際に情報を表示する必要がある場合は、Firebase Cloud Messaging などの実装によるプッシュ メッセージの使用を検討します。この方法を使うと、新しいデータがないか定期的にポーリングするのではなく、必要な場合にのみアプリが復帰するようになります。
• プッシュ メッセージを使うことができず、定期的なポーリングを行う場合は、JobScheduler か Firebase JobDispatcher（アカウント データの場合は SyncManager も含む）の使用を検討します。こうした API は AlarmManager よりもはるかに上位の API であり、スマートなジョブ スケジューリングに役立つ以下のような利点があります。

• 一括処理: システムを何度も復帰させてジョブを実行するのではなく、複数のジョブを一括処理することで、端末をより長時間スリープ状態にしておくことができます。
• 条件に応じた動作: ネットワークが利用可能かどうかや電池の充電状態などの条件を指定して、その条件を満たす場合にのみジョブを実行するようにできます。条件を使用すると、不必要な端末の復帰とアプリの実行を防止できます。
• 持続性と自動復帰: ジョブに持続性を持たせる（再起動時も含む）とともに、失敗時に自動的に再試行できます。
• Doze への対応: Doze モードやアプリ スタンバイによって課された制約がない場合にのみ、ジョブが実行されます。

プッシュ メッセージングやジョブ スケジューリングの使用が不適切な場合のみ、AlarmManager を使用して wakeup アラームをスケジュールする必要があります。言い換えれば、wakeup アラームが必要となるのは、ネットワークやその他の条件に関わらず、特定の時刻にアラームを鳴らす場合のみです。

Android Vitals で過度の wakeup が表示された場合の対処方法

過度の wakeup に対処するには、アプリ内で wakeup アラームをスケジュールしている場所を特定し、アラームのトリガーされる頻度を減らします。

アプリで wakeup アラームをスケジューリングしている場所を特定するには、Android Studio で AlarmManager クラスを開き、[RTC_WAKEUP] または[ELAPSED_REALTIME_WAKEUP] を右クリックして [使用箇所を検索] を選択します。これにより、プロジェクト内での該当するフラグの使用箇所がすべて表示されます。それぞれの使用箇所で、よりスマートなジョブ スケジューリングの方法に変更できないか確認します。

また、[使用箇所を検索] のオプションでスコープを [プロジェクトとライブラリ] に設定して、依存関係で AlarmManager API を使用しているかどうかも確認できます。使用している場合は、別のライブラリの使用を検討するか、作成者に問題を報告する必要があります。

wakeup アラームを使用しなければならない場合、アラームに以下のような適切なタグを付けることで、Play Console に有用な分析データが表示されます。

• アラームのタグ名に、パッケージ名、クラス名、メソッド名のいずれかを含めます。これはソース内でアラームが設定された場所の特定に役立ちます。
• アラーム名には Class#getName() を使用しないでください。Proguard によって難読化される可能性があります。代わりに、ハードコーディングされた文字列を使用します。
• アラームのタグには、カウンタやその他の固有の ID を追加しないでください。システムによってタグが削除され、有用なデータとして集約できなくなる可能性があります。

アプリケーション応答なし

次に、アプリケーション応答なし（ANR）と、この問題がどのようにユーザーに影響するかを見てみましょう。

ユーザーの視点では、ANR は、自分がアプリを操作しようとしているのにインターフェースがフリーズしている状態です。インターフェースがフリーズしたまま数秒経過した後、このまま待つか、アプリを強制終了するかを尋ねるダイアログが表示されます。

アプリ開発の視点では、ANR は、アプリがディスク I/O やネットワーク I/O といった長時間の処理によってメインスレッドをブロックしている場合に発生します。メインスレッド（UI スレッドとも呼ばれます）は、ユーザー イベントへの応答と、画面の描画内容の更新（1 秒間に 60 回）を担っています。そのため、メインスレッドの動作を遅延させる可能性のある処理はすべて、バックグラウンド スレッドに移すことが重要です。

Android Vitals では ANR がどのように表示されるか

Android Vitals では、アプリの ANR イベントについて収集された匿名の指標データを使用して、ANR に関する詳細がいくつかのレベルで表示されます。メインの画面にはアプリの ANR アクティビティの概要が表示されます。1 回以上 ANR が発生した 1 日のセッションの割合が、過去 30 日間とその前の 30 日間についてそれぞれ個別のレポートで表示されます。不正な動作のしきい値も併せて表示されます。

詳細ビュー（[ANR 発生率] ページ）には、ANR 発生率の推移の詳細と、アプリのバージョン、アクティビティ名、ANR の種類、Android のバージョン別の ANR の詳細が表示されます。このデータは、APK バージョン コード、サポートされている端末、OS バージョン、期間で絞り込むことができます。

[ANR とクラッシュ] セクションではさらに詳細なデータを確認できます。

ANR が起こる一般的な原因

前述のとおり、ANR はアプリのプロセスがメインスレッドをブロックした場合に発生します。こうしたブロックはさまざまな理由で発生しますが、一般的な原因は次のとおりです。

• メインスレッドでディスクやネットワークの I/O を実行している。これは ANR が発生する最も一般的な原因です。ほとんどのデベロッパーは、ディスクやネットワークに対するデータの読み取りや書き込みはメインスレッドで実行すべきでないと理解していますが、時として、その誘惑に駆られます。通常の条件下でディスクから数バイトのデータを読み込んでも ANR の原因になるおそれはまずありませんが、それでも、こうした処理はおすすめしません。ユーザーの端末のフラッシュ メモリが低速な場合や、他の複数のアプリによる読み取りや書き込みが同時に発生し、端末が高負荷状態で、その間自分のアプリの「簡単な」読み取り処理がキュー内で待機しなければならない場合は、どうなるでしょうか。メインスレッドでは I/O を実行しないでください。

• メインスレッドで長時間の計算を実行している。メモリ内での計算処理について考えてみましょう。RAM は長いアクセス時間に悩まされることはなく、小さな処理であればまず問題ありません。しかし、ループ内で複雑な計算処理やサイズの大きいデータセットの処理を開始すると、メインスレッドをブロックするおそれがあります。ピクセル数が多い大きな画像をサイズ変更したり、大量の HTML テキストを解析したうえで TextView に表示したりすることを検討してください。通常、アプリではこうした処理をバックグラウンドで実行することをおすすめします。

• メインスレッドから別のプロセスに対する同期 binder 呼び出しを実行している。ディスクやネットワークの操作と同様に、プロセスの境界をまたいだブロッキング呼び出しを行うと、プログラムの実行は、自分のアプリでは制御できない別のプロセスに渡されます。そのプロセスがビジー状態である場合や、アプリのリクエストに応答するためにディスクやネットワークへのアクセスが必要な場合は、どうなるでしょうか。さらに、別のプロセスにデータを渡す場合はデータのバイト配列化や復元が必要となるため、その処理にも時間が必要です。プロセス間呼び出しはバックグラウンド スレッドから行うことをおすすめします。

• 同期を使用している。高負荷の処理をバックグラウンド スレッドに移した場合でも、メインスレッドと通信して計算処理の進行状況や結果を表示する必要があります。マルチスレッド プログラミングは簡単ではないうえ、通常、ロックのために同期を使用する場合、実行がブロックされないようにするのは困難です。最悪の場合、スレッド同士が互いに処理の完了を待ち続けるデッドロックとなるおそれもあります。自分で同期を設計することは避けるようおすすめします。Handler などの特定目的向けソリューションを利用して、不変のデータをバックグラウンド スレッドからメイン スレッドに渡してください。

ANR の原因を特定する方法

ANR の原因の特定は容易ではありません。URL クラスを例に説明します。2 つの URL が同じかどうかを判別するメソッド URL#equals がブロックの原因となる可能性はあるでしょうか。SharedPreferences についてはどうでしょうか。バックグラウンドで getSharedPreferences から値を読み込む必要がある場合、メインスレッドで getSharedPreferences を呼び出せるでしょうか。いずれの場合も、処理が長時間のブロックの原因となる可能性があります。

幸い、StrictMode によって、ANR を見つけることができます。デバッグ用ビルドでこのツールを使用して、メインスレッドでの予期しないディスク アクセスやネットワーク アクセスを捕捉します。アプリの起動時に StrictMode#setThreadPolicy を使用して、ディスクとネットワークに対する I/O や、アプリで StrictMode#noteSlowCall を通じてトリガーする低速のカスタム呼び出しなど、検出する対象を指定します。また、ブロッキング呼び出しを検出した場合の StrictMode からの通知方法についても、アプリをクラッシュさせる、ログに記録する、ダイアログを表示する、の中から選択できます。詳しくは、ThreadPolicy.Builder クラスをご覧ください。

メインスレッドでのブロックの原因となる呼び出しを排除したら、必ず StrictMode をオフにしてから、Play ストアでアプリを公開してください。

過度の wakeup や ANR を排除すると、アプリの品質と利便性が改善されて、高い評価や好意的なレビューの獲得につながり、インストールが増加します。Android Vitals をチェックすることで、対応の必要な問題の有無を素早く簡単に確認できます。コード内のこうした問題を特定して解決する作業は必ずしも簡単ではありませんが、さまざまなツールや手法を活用してこの作業を効率的に進めることができます。

Android Vitals の活用方法はこれ以外にもあり、そうした機能についてさらに次回の記事でご紹介します。

Android Vitals についてご意見がございましたら、#AskPlayDev を付けてツイートしていただければ、@GooglePlayDev から返信いたします。このアカウントでは定期的にニュースや Google Play で成功するためのヒントを紹介しています。

ライセンス

本記事、関連するソースコードおよびファイルは The Code Project Open License（CPOL）により使用許諾されています。



Reviewed by Iku Igarashi - Google Play Business Development Manager

Google Play では、ユーザーに楽しんでもらうための新しい体験の提供、および、デベロッパー プラットフォームに対して継続的な投資を行なっています。 このような取り組みの一環として、本日、Google Play Points という新しいプログラムを開始します。本プログラムは、Google Play をご利用いただいている日本のユーザー向けに感謝の気持ちを込めて開発されたものであり、本日より、数日かけて日本の Google Play ユーザーが利用できるようになります。

Google Play Points に参加したユーザーは、アプリやゲーム、音楽、映画や電子書籍をはじめとする Google Play におけるすべてのお支払いや、対象アプリのインストールなどでポイントを貯めることができます。ポイントは、Google Play クレジットに交換できる他、特定のゲームクーポンや、パズル＆ドラゴンズの魔法石やモンスターストライクのオーブといったゲーム内アイテムなどに交換することができます。
お支払い方法の設定が済んでいる Google Play ユーザーであれば、1 クリックで簡単に Google Play Points へ参加できます。参加費用はかかりません。

本プログラムにデベロッパーとして参加するのは非常に簡単です。皆様が Google Play で公開しているアプリやゲームが Google Play アプリ内課金を既に利用していれば、Google Play Points に参加しているユーザーはそのアプリやゲームでポイントを貯めることができます。
ユーザーはポイントを Google Play クレジットに交換して、アプリやゲームのお支払いに使うことができます。

さらに今回、 SEGA Games、SQUARE ENIX、GungHo、XFLAG、NetEase などを含む様々なデベロッパー様のご協力のもと、Google Play Points のメンバーに対して特別なポイント交換アイテムを提供できることとなりました。これからも Google Play Points プログラムが進むにつれ、より多くのデベロッパー様とパートナーシップを育んでいきたいと考えています。

Google Play Points が幅広いユーザーに利用され、さらには、皆様のアプリやゲームにおけるユーザーとの新たなエンゲージメントが構築されていくことを期待しています。

Posted by Paul Feng, Google Play プロダクト マネージャー

この記事は Google Play プロダクト マネージャー、Larry Yang、Angela Ying による Android Developers Blog の記事 "Grow and optimize your subscriptions with new Google Play features" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Play の定期購入は引き続き大幅に拡大しており、定期購入者は前年比で 80% 以上増加しています。I/O 2018 では、定期購入の障壁を下げるためのいくつかのユーザー エクスペリエンスの改善や、自在なビジネス運営を実現できるツール群について発表しました。

定期購入者にとってさらに管理しやすく

定期購入によってたくさんの価値がもたらされます。しかし、私たちが行った調査から、キャンセルできずに定期購入から「抜け出せなくなる」ことに対する恐怖や、どのくらいの額を使っているかわからなくなるという不安が、ユーザーにとってアプリの定期購入を躊躇させる要因になっていることがわかりました。この恐怖に対処するため、ユーザーが  Google Play の定期購入を一元的に管理できる新しい定期購入センターを先日リリースしました。

ユーザーは、この定期購入センターから以下のことができます。

• すべての定期購入の詳細やステータスを見る
• バックアップとなる支払い方法の設定を含む、支払い方法を管理および更新する
• 定期購入を更新する
• キャンセルした定期購入を再開する
• 定期購入をキャンセルする

さらに、キャンセル理由をデベロッパーにフィードバックするため、ユーザーが定期購入をキャンセルした際に、キャンセル時アンケートが表示されるようになりました。今のところ、キャンセル時アンケートのデータは、サーバーサイド API に対してクエリを実行することで確認できます。

新しいサブスクリプション センターには、空の状態で [Get Started] リンクが表示されるので、ユーザーはローカライズされた選りすぐりの定期購入アプリを見つけることができます。

定期購入センターのリリースに合わせて、新しいディープリンクもリリースしています。これを使うと、ユーザーはアプリ、メール、ウェブから直接定期購入の管理画面を開くことができます。これを実装するには、パッケージ名と SKU を使ってディープリンクを作成し、ボタンやリンクとしてアプリの好きな場所に追加します。詳細については、Android のデベロッパー向けウェブサイトをご覧ください。

デベロッパーのできることが増加

ユーザーのエクスペリエンス向上に加えて、デベロッパーの皆さんのビジネス運営の柔軟性向上に役立つ新しいツール群もリリースしています。特に多くのリクエストが寄せられている機能に、価格の変更があります。近日中に、Google Play Console で簡単な操作をするだけで、価格の変更を受け入れるかどうかをユーザーに尋ねることができるようになります。まったく新しい SKU を設定する必要はありません。ユーザーには、Google Play からメール、プッシュ通知、アプリ内メッセージングで変更が通知されます。ユーザーが更新日までに同意しない場合、定期購入がキャンセルされます。この機能の早期アクセス プログラムへの参加を希望する方は、こちらからお申し込みください。

その他にも、定期購入関連のビジネス運営に役立つ次の機能が I/O でリリースされました。

• ユーザーの有効期限を変えずに定期購入をアップグレードする
• Play Console から一部払い戻しを行う
• 最新のものだけでなく、特定の定期購入の更新の払い戻しを行う
• サーバーサイド API で注文 ID を使用する
• Google Play Developer API と合わせて Refund API を使用する

これは、今年既に発表された、テスト用の更新間隔の短縮と柔軟なお試し価格の設定に続く改善です。

これらすべての機能を簡単に実装するには、I/Oで バージョン 1.1 がリリースされた Google Play Billing Library を使います。この課金ライブラリは、AIDL ファイルの上位にあたる抽象化レイヤーです。ビルド依存関係ファイルをアップデートして次にアプリをコンパイルするタイミングで、API のアップデートが自動的に取得されます。価格の変更と、有効期限を変えないアップグレードおよびダウングレードは、この課金ライブラリでのみ利用できます。この点は、今後のリリースでも変わらない予定です。

すべての人にメリットを

すばらしいユーザー エクスペリエンスを構築することが、高品質の定期購入者ベースを作ることにつながると、私たちは強く信じています。この目的のため、ビジネスの運営を改善するツールやインサイトを提供いたします。それを活用すれば、ビジネスやお客様にとって最適なことを実現する柔軟性を手にすることができるでしょう。

Reviewed by Hak Matsuda - Developer Relations Team

この記事はプラットフォームおよびエコシステム、デベロッパー マーケティング、Patricia Correaによる Android Developers Blog の記事 "#IMakeApps - Celebrating app makers worldwide" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android のデベロッパー エコシステムを作り上げているのは、さまざまなバックグラウンドや関心、夢を持った並外れた人々です。私たちのコミュニティを作り上げている人々を祝福するために、本日（*原文公開当時）から数か月にわたって、世界中のデベロッパー、創設者、プロダクト マネージャー、デザイナーなど、さまざまな人々と会い、抱いている情熱について語ってもらうとともに、コンピュータから離れているときの活動について伺いたいと考えています。

Polarsteps の共同創立者であり冒険家の Niek Bokkers（オランダ）、Quiltuduko をデザインしたアーティストの Faith Ringgold（米国）、Be My Eyes を開発した椅子修復家の Hans Jorgen Wiberg（デンマーク）のストーリーをご覧ください。ストーリーとアプリの詳細については、g.co/play/imakeapps でご覧いただけます。

ストーリーをお寄せください

皆さんのストーリーもお聞かせください。ソーシャル メディア チャンネルでハッシュタグ #IMakeApps を使って、開発中のアプリやゲーム、開発中に果たしている役割、そして仕事を離れているときの皆さんを最もよく表している画像を共有してください。Google のチャンネルで、定期的に人気のあるストーリーをいくつか選択して共有する予定です。

また、近日中に公開予定の #IMakeApps の映画に登場したい方は、こちらの自己推薦フォームに自己紹介とアプリやゲームの詳細を記入してください。

Twitter、YouTube、LinkedIn でフォローして、#IMakeApps のストーリーに関する最新情報をご確認ください。


Reviewed by Takuo Suzuki - Developer Relations Team