この記事は Fred Chung による Android Developers Blog の記事 " Privacy Sandbox Developer Preview 3: Support for conversion measurement, custom audiences, and ad selection " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android のプライバシー サンドボックスは、ユーザーのプライバシーを保護しながら、アプリの効果的でパーソナライズされた広告エクスペリエンスを実現する新しいソリューションを開発することを目的としています。私たちは、最初のデベロッパー プレビュー (英語) 以降も、Google は、プロジェクトの進捗に関する最新情報をお伝えするとともに、デベロッパー プレビューのタイムライン、トピックの分類、SDK のバージョン管理など、あらゆることについて業界と連携を続けています。皆さんのフィードバックに感謝しています。
2022 年 6 月 22 日に、デベロッパー プレビュー 3 をリリースしました。これには、コンバージョン測定やリマーケティングのユースケースに対応する API やデベロッパー リソースが含まれています。以前リリースした SDK ランタイムや Topics API のプレビューに加え、今回初めて Android 版のプライバシー サンドボックスのすべての主要 API のテストと影響の評価を開始することができます。
これらの API により、広告のクリック イベントやビューイベントがコンバージョン（新しいゲームのダウンロードなど）につながるタイミングを測定できます。これらの API は、アプリとウェブを横断するアトリビューションの主要なユースケースをサポートし、クロスパーティのユーザー識別子への依存を排除することで、ユーザーのプライバシーを向上させます。
今回のリリースには、アトリビューション レポート ワークフローの主要部分に関するクライアント側とサーバー側のセットアップとインタラクションを理解するのに役立つ、デベロッパー ガイドとサンプルアプリが含まれています。
テストをしやすくするため、今回のリリースには報告期間を上書きできる ADB コマンドが含まれています。Android クライアント API の詳細については、API リファレンスをご覧ください。
これらの API は Android 版 FLEDGE の一部で、サードパーティのデータ共有なしで、過去のアプリのエンゲージメントに基づいてカスタマイズされた広告をユーザーに提供するためのビルディングブロックを提供します。以下のことを実現できます。
詳細については、Custom Audience API と Ad Selection API (英語) リファレンス ページや、 リリースノートをご覧ください。
初めてデベロッパー プレビューを試してみる方は、SDK ランタイムと Topics API のデベロッパー ガイドに記載されているサポート対象となる機能もご確認ください。
Android 版のプライバシー サンドボックスの主要テクノロジーを復習したい方には、こちらの概要の動画を視聴し、設計案を確認することをお勧めします。
（日本語字幕は YouTube の自動翻訳機能で日本語を選択してください）
2022 年 6 月 22 日のデベロッパー プレビュー リリースには、機能の早期テストを開始し、フィードバックを共有 (英語) するために必要なリソースが含まれています。開発を始めるには、エミュレータまたはサポート対象の Pixel デバイスで SDK とシステム イメージをセットアップする手順をご確認ください。
Android 版プライバシー サンドボックス デベロッパー プレビューの詳細については、デベロッパー サイトをご覧ください。ニュースレターに登録 (英語)すると、定期的に最新情報を受け取ることができます。
この記事は Sachiyo Sugimoto による Android Developers Blog の記事 " Developer-Powered CTS (CTS-D) " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android の強みは多様なデバイスからなるエコシステムにあります。世界中の数十億のユーザーが、市場に出回っている 2 万 4,000 種類以上のデバイスを使っています。Android では、デバイスが一貫性のある安定したアプリ環境を提供し続けることができるように、初期リリースのころから Android 互換性プログラムを推進しています。
このプログラムで重要な位置を占めるのが、互換性テストスイート (CTS) です。CTS は 200 万件以上のテストケースのコレクションで、デベロッパーのアプリがさまざまなデバイスで確実に動作し、ユーザーに一貫したアプリ体験を提供できるようにするために、Android デバイスの実装をチェックします。
デバイス メーカーは、開発プロセス全体で自社デバイスに対して CTS を実行し、早い段階でバグを見つけて修正しています。このスイートは、長年にわたって拡張が重ねられ、新しいテストケースが追加されています。現在の CTS には 200 万件を超えるテストが含まれていますが、その数はまだ増え続けています。Android が進化するにつれて網羅すべき新しい領域が増えており、まだ十分にカバーできていない部分もあるため、それを埋めるテストを追加する作業が続いています。
ほとんどの CTS テストは Android エンジニアが記述していますが、アプリ デベロッパーには実際のデバイスの互換性問題に対して独自の視点があることも事実です。そこで、アプリ デベロッパーからの優れた提案を活用して CTS を拡張するため、デベロッパーの皆さんが作成して実行できる CTS-D という新しいテストスイートを追加します。
CTS-D は、アプリ デベロッパーの皆さんに開発に加わっていただく斬新な CTS モジュールであり、アプリ デベロッパーが現場で目にしている問題点に重点を置いたものです。デベロッパーはテストケースを作成して CTS-D に提供することで、そういった問題を見つけやすくすることができます。また、自分で CTS-D スイートを実行して互換性を検証することもできます。長期的には、Android デベロッパー コミュニティと密接に連携して CTS-D スイートを拡張していく予定です。
すでに多くの皆さんが独自のテストを作成し、さまざまなデバイスで互換性の検証をしていることは承知しています。そこで、皆さんと連携してそのテストを AOSP に組み込みたいと考えています。コミュニティからの提供を受けた最初のテストスイートは、こちらの CTS-D の初回コミットから確認できます。
つまり、CTS-D を通してこういったテストを広く利用できるようにすることで、デバイス メーカーやアプリ デベロッパーが問題を効率的に特定して共有できるようにします。
CTS-D はオープンソースで、AOSP で公開されています。そのため、すべてのアプリ デベロッパーが CTS-D を検証ツールとして使うことができます。CTS-D によって、アプリ デベロッパー、デバイス メーカー、Google 間とのそれぞれのコミュニケーションのオーバーヘッドを最小限にとどめ、問題を効率的に解決できるようになります。
あるデバイスが CTS-D テストに合格しなかった場合は、こちらの Issue Tracker テンプレートを使って問題を報告してください。報告されたデバイスで問題を検証した後、その解決に向けてパートナーと連携して作業を進めます。デバイス メーカーの皆さんにも、CTS-D を使って問題を見つけ、対策することを強くおすすめします。
CTS-D について何かアイデアをお持ちの方は、テストコードを AOSP に提供する前に、こちらの Issue Tracker テンプレートを使ってテスト提案をお送りください。Android チームが皆さんの提案を確認し、テストの適格性を検証します。現在、私たちの一番の関心は、電源管理領域のテストケースを追加することにあります。
CTS と同じく、新しい CTS-D のテストケースも適格性要件を満たす必要があり、実行できるのは以下の内容のみに限られます。
CTS-D についてもっと詳しく知りたい方は、こちらのチュートリアルをご覧ください。CTS-D に貢献する方法や、CTS-D の使い方を説明しています。なお、新しい CTS-D テストケースの審査には時間がかかる可能性がありますので、ご了承ください。皆さんが CTS-D を試してくださることを期待しています。Android の体験向上のために、ぜひご協力ください。
この記事は Oscar Rodriguez による Android Developers Blog の記事 " Boost the security of your app with the nonce field of the Play Integrity API " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
先日リリースされた Play Integrity API を使って、リスクや不正行為の可能性からゲームやアプリを保護する手段を講じるデベロッパーが増えています。
Play Integrity API は、アプリの整合性、デバイスの整合性、ライセンス情報に関する便利なシグナルに加えて、シンプルでありながら非常に便利な「ノンス」と呼ばれる機能を備えています。これを正しく使うと、Play Integrity API が提供する既存の保護をさらに強化できるほか、中間者 (PITM) 改ざん攻撃やリプレイ攻撃といった特定の種類の攻撃を軽減できます。
このブログ投稿では、ノンスとは何か、どのような仕組みで動作するのか、どのように使えばアプリの保護を強化できるのかについて、詳しく説明したいと思います。
暗号学やセキュリティ エンジニアリングにおいて、ノンス (number once) とは安全な通信の中で一度だけ使われる数を指します。ノンスは、認証、暗号化、ハッシュなど、さまざまなことに応用できます。
Play Integrity API でのノンスは、Base64 でエンコードされた暗号バイナリ blob です。API の整合性チェックを呼び出す前にこれを設定すると、API の署名付きレスポンスでその値がそのまま返されます。ノンスの作成方法、検証方法によって、Play Integrity API が提供する既存の保護をさらに強化したり、中間者 (PITM) 改ざん攻撃やリプレイ攻撃などの特定の種類の攻撃を軽減したりできます。
Play Integrity API が行うのは、署名付きレスポンスで実際のノンスデータをそのまま返すことだけです。そのため、有効な Base64 でさえあれば、どんな値でも設定できます。ただし、ノンスは、レスポンスをデジタル署名するために Google のサーバーに送られます。そのため、ノンスにはユーザー名、電話番号、メールアドレスなどの個人を識別できる情報 (PII) を一切設定しないことが非常に重要です。
アプリに Play Integrity API を設定したら、setNonce() メソッドを使ってノンスを設定します。または、Kotlin 版、Java 版、Unity 版、およびネイティブ版の API でも、同等の方法が提供されています。
setNonce()
Kotlin:
val nonce: String = ... // Create an instance of a manager.val integrityManager = IntegrityManagerFactory.create(applicationContext) // Request the integrity token by providing a nonce.val integrityTokenResponse: Task<IntegrityTokenResponse> = integrityManager.requestIntegrityToken( IntegrityTokenRequest.builder() .setNonce(nonce) // Set the nonce .build())
val nonce: String = ...
// Create an instance of a manager.
val integrityManager =
IntegrityManagerFactory.create(applicationContext)
// Request the integrity token by providing a nonce.
val integrityTokenResponse: Task<IntegrityTokenResponse> =
integrityManager.requestIntegrityToken(
IntegrityTokenRequest.builder()
.setNonce(nonce) // Set the nonce
.build())
Java:
String nonce = ... // Create an instance of a manager.IntegrityManager integrityManager = IntegrityManagerFactory.create(getApplicationContext()); // Request the integrity token by providing a nonce.Task<IntegrityTokenResponse> integrityTokenResponse = integrityManager .requestIntegrityToken( IntegrityTokenRequest.builder() .setNonce(nonce) // Set the nonce .build());
String nonce = ...
IntegrityManager integrityManager =
IntegrityManagerFactory.create(getApplicationContext());
Task<IntegrityTokenResponse> integrityTokenResponse =
integrityManager
.requestIntegrityToken(
.build());
Unity:
string nonce = ... // Create an instance of a manager.var integrityManager = new IntegrityManager(); // Request the integrity token by providing a nonce.var tokenRequest = new IntegrityTokenRequest(nonce);var requestIntegrityTokenOperation = integrityManager.RequestIntegrityToken(tokenRequest);
string nonce = ...
var integrityManager = new IntegrityManager();
var tokenRequest = new IntegrityTokenRequest(nonce);
var requestIntegrityTokenOperation =
integrityManager.RequestIntegrityToken(tokenRequest);
ネイティブ :
/// Create an IntegrityTokenRequest object.const char* nonce = ...IntegrityTokenRequest* request;IntegrityTokenRequest_create(&request);IntegrityTokenRequest_setNonce(request, nonce); // Set the nonceIntegrityTokenResponse* response;IntegrityErrorCode error_code = IntegrityManager_requestIntegrityToken(request, &response);
/// Create an IntegrityTokenRequest object.
const char* nonce = ...
IntegrityTokenRequest* request;
IntegrityTokenRequest_create(&request);
IntegrityTokenRequest_setNonce(request, nonce); // Set the nonce
IntegrityTokenResponse* response;
IntegrityErrorCode error_code =
IntegrityManager_requestIntegrityToken(request, &response);
Play Integrity API のレスポンスは、JSON Web Token (JWT) (英語) 形式で返されます。このペイロードは、次の形式の平文 JSON テキストです。
{ requestDetails: { ... } appIntegrity: { ... } deviceIntegrity: { ... } accountDetails: { ... }}
{
requestDetails: { ... }
appIntegrity: { ... }
deviceIntegrity: { ... }
accountDetails: { ... }
}
ノンスは requestDetails 構造に含まれており、次のような形式になっています。
requestDetails: { requestPackageName: "...", nonce: "...", timestampMillis: ...}
requestDetails: {
requestPackageName: "...",
nonce: "...",
timestampMillis: ...
nonce フィールドの値は、以前に API に渡した値と厳密に一致する必要があります。さらに、ノンスは Play Integrity API の暗号学的に署名されたレスポンスに含まれているため、レスポンスを受け取った後に値を改変することはできません。この特性を活用することで、ノンスを使ってアプリの保護を強化することができます。
悪意のあるユーザーが、オンライン ゲームでプレーヤーのスコアをゲームサーバーに報告する不正行為のシナリオについて考えてみましょう。この場合、デバイスは侵害されていませんが、プロキシ サーバーや VPN を使うと、ユーザーはゲームとサーバーとの間でネットワークに流れるデータを参照したり改変したりできます。そのため、悪意のあるユーザーは、実際のスコアはかなり低いにもかかわらず、高いスコアを報告できることになります。
この場合、Play Integrity API を呼び出すだけでは、アプリを保護することはできません。デバイスは侵害されておらず、アプリも正当なものなので、Play Integrity API が行うすべてのチェックに合格します。
しかし、Play Integrity API のノンスを使えば、操作の値をノンスにエンコードすることにより、ゲームのスコア報告という価値の高いアクションを保護できます。この実装は次のようになります。
この手順を示したのが次の図です。
保護すべき元のメッセージが署名結果と合わせて送信され、サーバーとクライアントの両方でノンスの計算にまったく同じメカニズムを使っている限り、メッセージが改ざんされていないことを示す強力な保証となります。
なお、このシナリオのセキュリティ モデルは、攻撃がデバイスやアプリではなく、ネットワーク上で行われることを前提としています。そのため、Play Integrity API が提供するデバイスとアプリの整合性シグナルも合わせて検証することが特に重要です。
別のシナリオについて考えてみましょう。ここでも、悪意のあるユーザーが Play Integrity API で保護されたクライアント サーバー アプリと不正な行為を行おうと、侵害したデバイスをサーバーが検出できないような形で使う場合です。
まず、攻撃者は正当なデバイスでアプリを使い、Play Integrity API で署名付きレスポンスを収集します。次に、侵害したデバイスでアプリを使い、Play Integrity API の呼び出しを傍受して、整合性チェックをする代わりに以前に記録した署名付きレスポンスを返します。
署名付きレスポンスは改ざんされているわけではないので、デジタル署名は問題なく見えます。そのため、アプリサーバーは正当なデバイスと通信していると誤解する可能性があります。これを リプレイ攻撃と呼びます。
このような攻撃に対する防御の第一線となるのは、署名付きレスポンスの timestampMillis フィールドを検証することです。このフィールドにはレスポンスが作成された時間を表すタイムスタンプが含まれており、たとえデジタル署名が正当であることが検証されても、古くて疑わしいレスポンスを検出する際に役立ちます。
timestampMillis
ただし、Play Integrity API のノンスを使ってレスポンスごとに一意な値を割り当て、レスポンスが以前に設定した一意な値と一致することを検証することもできます。この実装は次のようになります。
この実装があれば、サーバーがアプリに Play Integrity API の呼び出しを要求するたびに、毎回異なるグローバルに一意な値が使われることになります。そのため、攻撃者がこの値を予測できない限り、ノンスが期待される値と一致しないので、以前のレスポンスを再利用することはできなくなります。
上記の 2 つのメカニズムはまったく異なるメカニズムで動作しますが、アプリで両方の保護が同時に必要になる場合は、1 回の Play Integrity API 呼び出しで両方を組み合わせることができます。たとえば、両方の保護の結果を大きな Base64 ノンスに追加します。両方のアプローチを組み合わせた実装は、次のようになります。
ここで紹介したのは、ノンスを使って悪意のあるユーザーに対してアプリの保護を強化する方法です。アプリでプライベートなデータを扱っている場合や、アプリが不正使用に対して脆弱な場合は、Play Integrity API を使って脅威を軽減する措置を検討することをお勧めします。
Play Integrity API の詳細を知りたい方やこの API を使ってみたい方は、g.co/play/integrityapi のドキュメントをご覧ください。
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は Android Team による Android Developers Blog の記事 " eBay gets a 4.7 Google Play rating with tablet optimizations " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
eBay は、全世界で何百万人ものセラー (購入者) とバイヤー (販売者) が利用している巨大なオンライン マーケットプレイスです。売り上げを伸ばすには最適なユーザー エクスペリエンスが鍵となります。eBay のアーキテクチャ チームの Android エンジニアたちは、eBay アプリをタブレットや折りたたみ式デバイスなどの大画面デバイス向けにさらに最適化できる余地があることに気づきました。さまざまなデバイスでシームレスなエクスペリエンスを提供するために、一刻も早く対応する必要があることは明らかでした。その努力のかいあって、eBay アプリは Google Play でたちまち星 5 つ中の 4.7 を獲得しました。
チームがユーザー統計を分析したところ、 Android の大画面デバイスで eBay アプリにアクセスしているタブレット ユーザーが驚くほど多いことがわかりました。うれしいことにこの新しいデータは、タブレットを使っている eBay ユーザーが、スマートフォンで同アプリを使っているユーザーよりもアプリの利用時間が長めな傾向にあることを示していました。
「大画面デバイスへの対応は、デベロッパーが時間をかけて取り組む価値があります。これは、当社のパブリック フィードバック チャンネルではっきり示されています」と eBay のモバイル アーキテクチャ チームの Android エンジニアである Matthew Mossman 氏は話しています。大画面デバイス向けにアプリを最適化することで、eBay のデベロッパーはユーザー エクスペリエンスの質を高め、ユーザーの満足度は大きく向上しました。
eBay アプリには非常にたくさんの情報が詰め込まれているため、セラーやバイヤーの人気を維持するには、公開されているアイテムの全容や詳しい説明をユーザーに示すことが重要でした。eBay の Android エンジニアたちは、タブレットの広い画面領域を活用することでユーザーのブラウズや検索のエクスペリエンスを向上できると考え、リスト / 詳細パターン (英語) を使って UX フローを改善しました。
Mossman 氏は、Android の強力なリソース修飾子メカニズムを使い、さまざまなデバイスに最適なレイアウトを設定しました。そして eBay のスマートフォン アプリのユーザー インターフェース コンポーネントのライブラリを更新し、ノートパソコンやタブレットでも利用できるようにしました。また、eBay のアーキテクチャ チームと機能チームは、業界の Android 標準化ガイドラインを採用して、アプリのカスタマイズ プロセスを一致させました。それにより、改善をこれまで以上に迅速にユーザーに提供できるようになりました。
Mossman 氏とデベロッパー チームは、タブレット ユーザー向けに eBay アプリを改善した後、Google Play で好意的なレビューが急増し、その結果 eBay Android アプリの評価も星 5 つ中 4.7 に上昇することができました。また、マテリアル デザイン コンポーネント (英語) やダークテーマのサポートなど、直感的で目を引く機能をアプリに組み込むと、ユーザーの満足度が大きく向上すると、デベロッパー チームは結論付けました。
さらに、eBay のトラストチームと検索チームも、営業活動を通じてユーザー エンゲージメントが向上したことを確認しています。特定のデバイスへの対応を強化するためにアプリ バンドルと動的機能を有効化すると、コミュニティ サポート ネットワークでのエンゲージメントが 20% 上昇しました。これは、タブレット ユーザーが新たな関心を寄せていることを表しています。
引用カード :「私たちはデザインとエンジニアリングのレベルに注力し、タブレット固有のエクスペリエンスもサポートしました。その結果うれしいことに、Google Play で星 4.7 個の評価を獲得することができました」– eBay アーキテクチャ チームの Android エンジニア、Matthew Mossman 氏
今後のリリースでは、eBay の Android アプリにも最近導入された UI 構築ツールキット、Jetpack Compose の豊富な機能を十分に活用できるようにする予定です。Firebase (英語) の指標とレポートも、eBay アプリの拡大とユーザーのメリットにつながる改善の機会をピンポイントで特定することに役立ちました。
eBay は大画面デバイス向けの最適化を計画したことで、デバイス固有のエクスペリエンスに注力することが、ユーザーとデベロッパー双方のメリットにつながることを実証しました。
Android や Chrome OS デバイス向けに大画面ならではのエクスペリエンスを構築するときはこちらの説明をご覧ください。
Google Play l インディー ゲーム フェスティバル 2022 に多数ご応募いただきありがとうございました。厳正なる審査により以下の 20 作品が選出されました。入賞されたみなさま、おめでとうございます！
この中から、2022 年 9 月 3 日に開催するファイナル イベントでトップタイトルが決定します。
この機会に、トップ 20 作品をダウンロードして、あなたのお気に入りのゲームを見つけてみてください。各ゲームの感想や応援コメントを投稿される際はハッシュタグ #indiegamesfestivaljp をご活用ください。ファイナル イベントへの参加には、こちらからニュースレターにご登録ください。
皆さんのご参加をお待ちしております。
Posted by Tamao Imura - Developer Marketing Manager, Google Play
この記事は Android Developers Blog の記事 "3 things to know about Form Factors at Google I/O'22" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
現在、Android は 5 億台近くの自動車、テレビ、スマートウォッチ、ノートパソコンで動作しています。そのため、アプリがデバイスを超えてシームレスに動作することが今まで以上に重要になっています。今年の I/O では、フォーム ファクタに改めて注目し、Wear OS や大画面向けの重要なアップデートについて発表しました。ここでは、新機能の要点をお伝えするため、Google I/O で発表されたフォーム ファクタについて知っておくべき 3 つのことを紹介します。
I/O では、Compose for Wear OS のベータ版リリース (英語) を発表しました。Compose for Wear OS は、Wear OS でひときわ優れたユーザー エクスペリエンスを構築できる最新の宣言型 UI ツールキットで、Jetpack Compose の基礎と理念を共有しつつ、UI 開発をシンプルにして加速します。さらに、スマートウォッチ向けに最適化されたコンポーネントを含むマテリアル カタログを提供します。
Compose for Wear OS は、オープンソース コミュニティの協力のもと、そのフィードバックを受けながら開発しています。デベロッパー プレビュー以降も、ナビゲーション、Lazy リストのスケーリング、入力とジェスチャーのサポートなど、たくさんのコンポーネントの追加や改善をしました。現在の Compose for Wear OS は、まもなく公開される 1.0 リリースに向けて機能が完成しており、API は安定版になっています。そのため、本番環境に対応できる美しいアプリの開発を始めることができます。
さらに、つい先日、ヘルスコネクトをリリースしました。ヘルスコネクトを使うと、ユーザーは健康とフィットネスのデータをスマートフォンに安全に保存できるほか、お気に入りの健康とフィットネスのアプリに接続して保存したデータを共有することもできます。Samsung Health、Google Fit、Fitbit など、多くの健康とフィットネスの人気アプリがヘルスコネクトを利用しています。ヘルスコネクトは、健康データを Android スマートフォンに保存して共有するための共通の API セットです。デベロッパーは、オンデバイスのデータストアのデータを読み書きできます。スキーマと API の動作は標準化されているので、簡単にデータを利用できます。ユーザーの健康データのプライバシーがいかに重要であるかは承知していますので、パーミッションとプライバシー管理を一元化し、明確でシンプルな方法でデータを管理できるようにしています。
Google は、ハードウェアの革新、オペレーティング システムの最適化、アプリ エコシステムへの注力を通して、大画面に全力投球しています。今年最初の 4 半期には、アクティブな大画面ユーザーが 2 億 7,000 万人に達しており、タブレット、折りたたみ式、Chrome OS に最適化する絶好の機会を迎えています。
前回の I/O の後に、大画面向けに Android 12 を改善するフィーチャー ドロップ、Android 12L をリリースしました。Android 13 にはそのすべての機能が含まれているほか、さらに改善が追加されています。Android 12L と 13 では、タスクバー、マルチタスク、キーボードとマウスのサポート、アプリの互換性モードなど、大画面向けのたくさんの最適化が行われています。さらに、ガイド、テスト、ツールにもすばらしいアップデートがあります。大画面向けにアプリを最適化してテストする作業を感覚だけで行わなくてもいいように、一連の大画面品質ガイドラインと、さまざまなマテリアル デザインの正規レイアウトを作成しました。Jetpack ライブラリはこのガイドを実装しており、ドラッグ＆ドロップなどの一般的な大画面開発タスクが組み込まれています。
ハードウェアの革新は、今年以降の Google の大画面への注力の土台となります。I/O では、2023 年に発売予定の Google Pixel タブレットについてお知らせしました。また、パートナーもすばらしいデバイスを作っており、Samsung、Lenovo、OPPO などの企業からタブレットや Chromebook、折りたたみ式デバイスが販売されています。
ハードウェアとオペレーティング システムの驚くべき革新とともに、これまで以上に多くのアプリが大画面向けに最適化されています。Facebook、TikTok、HBO Max、Zoom (動画/英語) などのアプリは、大画面ですばらしい見栄えを実現しています。Google は大画面のチャンスを認識しています。YouTube (動画/英語) 、Google マップ、Google フォト、Chrome など、多くの人気アプリで大画面向けの最適化がロールアウトされており、今後もさらに増える予定です。
こういったアプリやその他のアプリは Google Play ストアで公開されていますが、その Google Play ストアでもこれまでで最大級の効果があるアップデートがあります。具体的には、ユーザーが Google Play ストアで大画面に最適化された最高のアプリを見つけられるように、大画面に注目した新しい記事コンテンツを導入したり、大画面アプリのレビューと評価を分けたりしました。また、Google Play をアップデートして、タブレット、Chromebook、折りたたみ式デバイスでの見栄えを向上させています。
大画面と Wear OS のアプリをさらに改善できるように、徹底解説コンテンツを作成しました。アプリをさまざまな種類の入力、画面サイズ、デバイスに対応する方法について説明します。
異なるフォーム ファクタ向けに開発やテストする際の生産性を上げることができるように、Android Studio Dolphin ベータ版と Electric Eel Canary には、Wear OS と大画面向けの新機能を追加しています。詳しくはこちらをご覧ください。
これから始めようと思っている方のために、皆さんをサポートするすばらしい I/O のコンテンツを紹介します。
この記事は Amanda Alexander による Android Developers Blog の記事 " Google I/O 2022: What’s new in Jetpack " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Jetpack は、最新の Android 開発の重要な柱とも言えるものです。これは 100 以上のライブラリ、各種ツール、ガイドをまとめたスイートで、デベロッパーはベスト プラクティスに従ったり、ボイラープレート コードを減らしたり、Android のあらゆるバージョンやデバイスで一貫して動作するコードを書いたりしやすくなるため、アプリ独自の機能の構築に専念できるようになります。
Jetpack は Google Play のほとんどのアプリのアーキテクチャに使用されており、現在、上位 1,000 アプリの 90% 以上で使用されています。
こちらは、I/O での「Jetpack の新機能」 (動画/英語) の拡大版として、Jetpack の最新アップデートのハイライトを紹介したものです。
以下では、次の 3 つの主要な Jetpack アップデートについて取り上げます。
最後に、いくつかの重要な機能更新を紹介します。
アプリ アーキテクチャ ライブラリとコンポーネントを使うと、堅牢で、テストや保守がしやすいアプリを構築できます。
Room は、SQLite の抽象化レイヤを提供する、推奨のデータ永続性レイヤです。プラットフォームのユーザビリティと安全性を高めることができます。
Room 2.4 では、Kotlin Symbol Processing (KSP) のサポートが安定版になりました。当社の Kotlin コードのベンチマークでは、KSP の処理速度は KAPT の 2 倍に向上しています。Room 2.4 には enum と RxJava3 の組み込みサポートも追加され、Kotlin 1.6 に完全対応しています。
Room 2.5 には、Kotlin への完全な書き換えの最初の部分が含まれます。これにより、Java プログラミング言語で書かれた旧バージョンとのバイナリ互換性も確保しながら、今後の Kotlin 関連の機能向上の基盤を提供します。また、room-paging アーティファクトを利用した Paging 3.0 の組み込みサポートにより、Room クエリで PagingSource オブジェクトを返せるようになります。さらに、マルチマップ（ネストしたマップや配列）型戻り値を使用するリレーショナル クエリ メソッドがサポートされるので、デベロッパーは追加のデータ構造を定義せずに、JOIN クエリを実行できるようになります。
@Query("SELECT * FROM Artist JOIN Song ON Artist.artistName = Song.songArtistName")fun getArtistToSongs(): Map<Artist, List<Song>>
@Query("SELECT * FROM Artist
JOIN Song ON Artist.artistName =
Song.songArtistName")
fun getArtistToSongs(): Map<Artist, List<Song>>
AutoMigrations のアップデートによってデータベースの移行がシンプルになり、新たなアノテーションとプロパティのサポートも追加されます。@Database アノテーションの新しい AutoMigration プロパティを使うと、移行元や移行先のバージョンを宣言できます。また、Room でテーブルや列の変更に関する追加情報が必要な場合も、@AutoMigration アノテーションを使用して入力を指定できます。
Database( version = MyDb.LATEST_VERSION, autoMigrations = { @AutoMigration(from = 1, to = 2, spec = MyDb.MyMigration.class), @AutoMigration(from = 2, to = 3) })public abstract class MyDb extends RoomDatabase { ...
Database(
version = MyDb.LATEST_VERSION,
autoMigrations = {
@AutoMigration(from = 1, to = 2,
spec = MyDb.MyMigration.class),
@AutoMigration(from = 2, to = 3)
)
public abstract class MyDb
extends RoomDatabase {
...
DataStore ライブラリは、SharedPreferences の問題に対処する堅牢なデータ ストレージ ソリューションです。これは、さまざまな SharedPreferences のユースケースを置き換えることができる強力な仕組みです。使い方を詳しく知りたい方は、最新の Android 開発スキル : DataStore (英語) の動画シリーズと記事をご覧ください。アプリでこのライブラリを使用できるかどうかを確認する方法、依存関係の注入と合わせて使用する方法、SharedPreferences から Proto DataStore への移行などに関するガイドを提供しています。
Paging ライブラリを使うと、データの小さなチャンクを読み込んで表示することで、ネットワークやシステム リソースの消費を抑えることができます。アプリのデータは、RecyclerView や Compose の Lazy リストで、少しずつ段階的に読み込むことができます。
Paging 3.1 は Rx と Guava 統合の安定したサポートを提供します。Paging は Kotlin コルーチンをネイティブに使用していますが、これらの統合はその Java による代替機能を提供します。このバージョンでは、無効なデータや古いデータを表す新しい戻り値の型、LoadResult.Invalid が追加され、無効化の競合状態の処理が向上しました。また、新しい onPagesPresented API と addOnPagesUpdatedListener API によって、no-op 読み込みや空ページに対する操作の処理も向上しました。
Paging 3 についての詳細は、新しくシンプルになった、Android デベロッパー サイトの Paging の基本 Codelab をご覧ください。リストを表示するアプリに Paging ライブラリを組み込む方法を確認できます。
Navigation ライブラリは、アプリ内のさまざまなコンテンツ間を移動するためのフレームワークです。
今回、新しい navigation-compose (英語) アーティファクトによって、Navigation コンポーネントが Jetpack Compose に統合され、アプリでコンポーズ可能な関数を遷移先として使用できるようになりました。
また、複数バックスタック機能が改善され、状態を記憶しやすくなりました。NavigationUI で、ポップされた遷移先の状態の保存と復元が自動的に行われるようになったので、デベロッパーはコードを変更せずに複数のバックスタックをサポートできます。
navigation-fragment アーティファクトにより大画面サポートが拡張され、構築済みの 2 ペイン レイアウト実装が AbstractListDetailFragment で提供されます。このフラグメントは SlidingPaneLayout を使用して、一覧ペイン（サブクラスにより管理される）と詳細ペイン（NavHostFragment を使用）を管理します。
すべての Navigation アーティファクトは Kotlin で書き換えられ、ジェネリクスを使用するクラス（NavType のサブクラスなど）の null 可能性に関する改善が行われています。
最新の Android 開発のベスト プラクティスを取り上げたさまざまな動画と記事で、主要なアーキテクチャ ライブラリの詳しい使い方を説明しています。最新の Android 開発スキル : アーキテクチャ (動画/英語) シリーズをご覧ください。
パフォーマンス ライブラリを使用すると、パフォーマンスの高いアプリを構築したり、高パフォーマンスを維持するための最適化方法を特定したりして、エンドユーザーのエクスペリエンスを向上できます。
特にインストール直後にアプリを使用するときなど、アプリのスピードはユーザー エクスペリエンスに大きく影響します。そのような初回エクスペリエンスを向上するために、ベースライン プロファイルを作成しました。ベースライン プロファイルを使うと、アプリやライブラリが Android ランタイムにコードパスの使用方法に関するメタデータを提供します。ランタイムは、それを使って Ahead-Of-Time コンパイルの優先順位を判断します。このプロファイル データはライブラリ全体で集計され、baseline.prof ファイルとしてアプリの APK に保存されます。そしてインストール時に、アプリとその静的にリンクされたライブラリ コードの一部を事前コンパイルするために使用されます。これによってアプリの読み込みが速くなり、ユーザーがアプリを初めて利用する際のフレーム ドロップを減らすことができます。
Google ではベースライン プロファイルをすでに活用しています。ベースライン プロファイルを採用することで、Google Play ストアアプリの検索結果ページの最初のレンダリング時間は 40% 短縮しました。ベースライン プロファイルは Fragment や Compose などの一般的なライブラリにも追加されており、エンドユーザーのエクスペリエンスが向上しています。独自のベースライン プロファイルを作成するには、Macrobenchmark ライブラリを使用する必要があります。
Macrobenchmark ライブラリは、Jetpack のベンチマーク対象をより複雑なユースケース（アプリの起動、RecyclerView のスクロールやアニメーションの実行といった組み込み UI 操作など）に拡大することで、デベロッパーがアプリのパフォーマンスを深く理解できるようにします。Macrobenchmark は、ベースライン プロファイルの生成に使うこともできます。
Macrobenchmark がアップデートされ、テストのスピードが向上し、新たな試験運用版機能が加わりました。また、TraceSectionMetric を使用したトレースベースのカスタム時間測定もサポートされ、デベロッパーが特定のコード セクションをベンチマーク測定できるようになりました。さらに、AudioUnderrunMetric によるオーディオ バッファ アンダーランの検出が可能になり、オーディオのジャンクを分析しやすくなりました。
BaselineProfileRule は、ランタイム最適化に役立つプロファイルを生成します。BaselineProfileRule は他のマクロ ベンチマークと同じように機能し、デベロッパーはユーザー アクションをラムダ式のコードで表します。以下は、コンパイラが事前に最適化すべき重要なユーザー アクションが、コールド スタート（ランチャーからアプリのランディング アクティビティを開く）である場合の例です。
@ExperimentalBaselineProfilesApi@RunWith(AndroidJUnit4::class)class BaselineProfileGenerator { @get:Rule val baselineProfileRule = BaselineProfileRule() @Test fun startup() = baselineProfileRule.collectBaselineProfile( packageName = "com.example.app" ) { pressHome() // This block defines the app's critical user journey. Here we are // interested in optimizing for app startup, but you can also navigate // and scroll through your most important UI. startActivityAndWait() }}
@ExperimentalBaselineProfilesApi
@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
@get:Rule
val baselineProfileRule = BaselineProfileRule()
@Test
fun startup() = baselineProfileRule.collectBaselineProfile(
packageName = "com.example.app"
) {
pressHome()
// This block defines the app's critical user journey. Here we are
// interested in optimizing for app startup, but you can also navigate
// and scroll through your most important UI.
startActivityAndWait()
Macrobenchmark でのベースライン プロファイルの生成と使用に関する詳細と完全なガイドについては、Android デベロッパー サイトのガイドをご覧ください。
新しい JankStats ライブラリを使うと、アプリの UI のパフォーマンス上の問題の追跡や分析をすることができます。これには、一般に「ジャンク」と呼ばれる、レンダリング フレームのドロップに関するレポートが含まれます。JankStats は、FrameMetrics などの既存の Android プラットフォームを利用していますが、API レベル 16 以降で使用できるようになっています。
このライブラリは、プラットフォームに組み込まれている機能以外に、新たな機能も提供しています。フレーム ドロップの原因の特定に役立つヒューリスティック、レポートに UI の状態を含めることによる追加コンテキストの提供、分析用データのアップロードに使用できるレポート コールバックなどです。
この 3 つの JankStats の主要機能について説明します。
Tracing ライブラリは、トレース イベントをシステム バッファに書き込み、アプリのパフォーマンス プロファイリングができるようにします。Tracing 1.1 は、API レベル 14 以降のデバッグ不可ビルドのプロファイリングをサポートしています。これは、API レベル 29 で追加された <profileable> マニフェスト タグに似ています。
UI ライブラリにいくつかの変更が加えられ、大画面の互換性、折りたたみ、絵文字のサポートが向上しました。
ネイティブ UI を作成するための Android の最新ツールキット、Jetpack Compose の 1.2 ベータ版がリリースされました。ダウンロード可能なフォント、lazy layout、ネストされたスクロールの相互運用性など、いくつかの機能が追加され、より高度なユースケースをサポートするようになります。詳しくは、ブログ投稿 Jetpack Compose の新機能をご覧ください。
新しい WindowManager ライブラリは、デベロッパーがアプリをマルチウィンドウ環境や新しいデバイスのフォーム ファクタに対応させる際に役立ちます。このライブラリは、API レベル 14 以降でサポートされる共通 API サーフェスを提供します。
最初のリリースは、折りたたみ式デバイスのユースケースが対象で、コンテンツの表示方法に影響する物理特性の照会などが含まれています。
Jetpack の SlidingPaneLayout コンポーネントがアップデートされ、WindowManager のスマート レイアウト API を使用できるようになりました。ヒンジをまたぐ場合など、オクルージョン領域にコンテンツが配置されないようにすることができます。
新しい DragAndDrop ライブラリも、新しいフォーム ファクタとウィンドウ モードの対応に役立ちます。デベロッパーは、アプリ内外からのデータのドラッグ＆ドロップを受け入れることができます。DrapAndDrop には一貫したドロップ ターゲット アフォーダンスが含まれ、API レベル 24 以降がサポートされます。
AppCompat ライブラリを使うと、旧 API バージョンのプラットフォームで新しい API にアクセスできます。これにはダークモードなどの UI 機能のバックポートも含まれます。
AppCompat 1.4 には、Emoji2 ライブラリが統合されています。API レベル 14 以降の AppCompat でサポートされるすべてのテキストベース ビューで、新しい絵文字がデフォルトでサポートされます。
カスタム ロケール選択が API レベル 14 以降でサポートされるようになりました。アプリを再起動しても失われないロケール設定の手動永続化と、サービス メタデータ フラグによる自動永続化をサポートしています。この機能は、同期的にロケールを読み込み、必要に応じて実行中のアクティビティを再作成することをライブラリに指示します。API レベル 33 以降では、プラットフォームが永続化を管理します。これによってオーバーヘッドが増加することはありません。
Annotation ライブラリは、ツールや他のデベロッパーがアプリのコードを理解するために役立つメタデータを公開します。@NonNull のような一般的なアノテーションが提供されます。こういったアノテーションを lint チェックと組み合わせて使用することで、コードの正確性とユーザビリティを向上できます。
アノテーションは現在 Kotlin に移行中で、Kotlin を使用するデベロッパーには、より適切なアノテーション ターゲット（@file など）が表示されるようになります。
要望の多かったいくつかのアノテーションが、対応する lint チェックと共に追加されています。これには、メソッドや関数のオーバーライドに関するアノテーションや、@DeprecatedSinceApi アノテーションが含まれます。@DeprecatedSinceApi は、@RequiresApi を補うもので、特定の API レベル以上で使用を推奨しないことを示すアノテーションです。
現在、GitHub で 100 以上のプロジェクトを公開しています。以下のモジュールは、標準の GitHub ベースのワークフローを通じてデベロッパーの皆さんからのサポートを受け付けています。
Pull リクエストの処理方法と Jetpack ライブラリの開発について詳しくはウェブサイトをご覧ください。
以上は、過去数か月間に行われた Jetpack のすべての変更に関する概要です。各ライブラリの詳細については、AndroidX のリリースノートをご覧ください。API ピッカーを使用して簡単にライブラリを検索することもできます。また、その他のハイライトについては、Google I/O トーク (動画/英語) を視聴してください。
Java は Oracle および / またはその関連会社の商標または登録商標です。
この記事は Purnima Kochikar による Android Developers Blog の記事 "Celebrating 10 years of Google Play. Together. " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google Play 10 年のお祝いを、皆さんと共に
今週、私たちは Google Play の 10 年を祝っています。この 10 年間にわたり、デベロッパーの皆さんの創造性と、Google のグローバルなプラットフォームへの投資との相乗効果で、活気に満ちたアプリのエコシステムが生み出されました。190 か国以上の 25 億人のユーザーが毎月 Google Play を利用して皆さんのアプリやゲームを楽しみ、 Google Play は、これまでにデベロッパーの皆さんに $1,200 億ドルを超える収益 をもたらしました。この素晴らしい節目を誇りに思うとともに、皆さんのパートナーシップに感謝申し上げます。
これまでの歩みを振り返って
私は、Google Play の立ち上げからわずか数か月後の 2012 年にチームに参加しました。当時、Android のアクティブユーザー数が 1 億人から 4 億人に (英語) 増加したばかりでした。Android は、モバイル コンピューティングを全世界のあらゆる人々に広めるという大胆な目標を掲げた新参者でした。プラットフォームの機能、ツール、デザイン ガイドライン、商業的な能力など、ほとんどの面で競合プラットフォームに大きく遅れをとっていたため、当然ながら皆さんも成功の可能性には懐疑的でした。しかし、私たちは、公平でオープンなエコシステムが持つ大きな可能性を信じ、何より重要な点として、デベロッパーの皆さんの無限の可能性を信じて、前進してきました。私たちは、皆さんの成功へのコミットメントを原動力として、これからも歩み続けます。
当時、わずか 6 人だったパートナーシップ チームは、モバイル経済のもたらすチャンスをとらえ課題を克服するために、最善のサポートをするにはどうすればよいかを考えていました。しかしながら、とても多くの不確定要素がありました。世界中のユーザーにとって手の届く価格のデバイスで、デベロッパーの皆さんが思い描くアプリを提供できるだろうか？モバイル機器のデータ通信料は高額でデバイスの性能も低い中、人々はスマートフォンの小さな画面で動画を見るだろうか？モバイルゲームに満足して課金し、安心して利用してもらえるだろうか？雑誌や新聞などの紙媒体と同様に、アプリ内コンテンツを定期購読してもらえるだろうか？などの要素です。
私たちは、あらゆるステップで皆さんと共に課題に取り組み、時間をかけて皆さんのニーズを把握し、上質なアプリやゲームを開発できるよう支援してきました。また、β テストや段階的なロールアウトの機能、ユーザーレビューに返信できる機能などを通して、世界に広がる Google のユーザー コミュニティと共に、皆さんのアプリやゲームを進化させられるお手伝いをさせていただきました。
そうした初期の頃の、最も懐かしい思い出は、モバイル端末の利便性を活かす斬新な方法を考案して、私たちに刺激を与えてくれた各企業との協働です。これらの協働は、このテクノロジーの可能性について、改めて気づかせてくれました。Smule の事例は、Google Play 初期のサクセス ストーリーの 1 つです。この 10 年間、Smule の成長と繁栄を見ることができ、とても嬉しいです。
(日本語字幕は YouTube の自動翻訳機能で日本語を選択してください)
皆さんのアプリが人気を博し、持続可能なグローバル ビジネスへの転換を目指す中、Google はコマース プラットフォームへの投資を強化し、皆さんのビジネスの成長やマネジメントを支援しました。世界中の最も一般的で効果的な支払い方法を追加することで、アプリやゲームに対する支払いをスムーズに行えるようにしました。70 か国でサポートされている 300 以上の現地の支払方法へのアクセスなど、現地の支払方法の発見と統合に関する複雑さを解消しました。また、プレミアムから無料プレイや定期購入のビジネス モデルに至るまで、皆さんのビジネスニーズを予測しサポートするためにプラットフォームを進化させ、現在 Google Play は、 170 以上の市場でユーザーの安全かつシームレスな取引を支援しています。
インストールから Vitals まで、アプリやゲームのライフサイクル全体について、Google Play Console を通じて業界をリードするインサイトを提供し、ビジネスを効率的に管理できるよう支援しました。Smart Launcher の創業者である Vincenzo Colucci 氏が、Google Play のおかげで、彼が住みたい場所（南イタリアのマンフレドニアで、愛する人と一緒に）で、好きなこと（世界中の人々に影響を与えるアプリの開発）ができるようになったと述べたとき、私のチーム全員が涙したことを覚えています。彼の会社も、つい先日 10 周年を迎えたばかりです。
これまでのあらゆる段階で、皆さんは Google へさらに多くのことを求め、より広い視野で考えるよう促してくれました。これを受けて、プロダクトチームとエンジニアリング チームは、皆さんの素晴らしい開発をサポートするためのツールや機能を構築しました。皆さんからのフィードバックは、このプラットフォームでの成功をサポートするための新機能、リソース、プログラムのリリースに活かされています。皆さんのご協力のもとで、私たちは進化し続けています：
また、数社のパートナーとの協働を通じて、エコシステム全体に利益をもたらす新機能を開発してきました。たとえば、2015 年には Supercell と協力して不正行為の防止を支援し、Voided Purchases API をリリースしました。これにより、不正行為や還付金詐欺への対策を業界全体で改善することができました。同様に、ガンホー・オンライン・エンターテイメント株式会社 や NCSOFT などの日本や韓国のパートナーは、Rovio の初期の Angry Birds のような有料ダウンロードゲームをサポートするプラットフォームから、ライブサービスとしてのゲームを展開できる LiveOps プラットフォームへの成長を支援してくれました。メディア パートナーは、アカウントの一時停止や猶予期間などの機能を含む定期購入のプラットフォームを進化させるために、私たちを支援してくれました。興味深いのは、世界がロックダウン状態になった際に、私たちはこれらの機能を利用して、スポーツアプリのパートナーが定期購入ユーザーを維持するために役立てました。
10 年にわたるパートナーシップの中で、このような例は数え切れないほどありますが、ここでは過去 10 年の中で最も印象に残ったローンチを 10 件、ご紹介します。
※こちらのタイムラインはグローバルでのローンチ日を反映しています。日本でのローンチ日は異なる場合がございますので、ご了承ください。
皆さんのビジネスが成熟するにつれ、最も忠実なユーザーを維持して再びエンゲージできるよう、Google Play Points などのプロダクト機能の開発に投資してきました。このプログラムは 28 か国で 1 億人を超える会員を獲得し、2022 年後半にはさらなる拡大が予定されていることを大変誇りに思っています。また、プロダクト ロードマップやグローバル展開の計画について、よりデータに基づいた意思決定を行えるよう、ビジネスおよび技術的なインサイトを提供するコンサルティング サービスも設けました。これらのインサイトによって収益が数百万ドル増加し、プロダクトの方向性だけでなく M&A 戦略にも影響があったことを皆さんからお聞きしています。
そして何より、私たちのパートナーシップは、世界中のユーザーに有意義なアプリやゲームを提供し、新たな雇用を創出し、地域経済に貢献するビジネスを成功させてきました。米国だけでも、Google Play と Android は 200 万人以上の雇用創出に貢献してきました。私たちは、世界中の地域社会や中小企業にもたらした経済効果を、心から誇りに思っています。
将来を見据えて
次の 10 年に目を向けるとき、私たちが共に経験したこの前例のない 2 年間と、私たちのパートナーシップが多くの人々の生活に与えた圧倒的な好影響について、立ち止まって考えてみることは有益なことだと思います。Android と Google Play は、皆さんのビジネスを通じて、家族や大切な人をつなぎ、日常生活をサポートすることでユーザーの安全を守り、遠隔医療へのアクセスを早め、雇用を創出し、子どもたちの学習と成長を可能にしてきました。 このことを今、しっかりと認識し受け止めるために少し時間を取ってみましょう。
この数年間で、私たちは、安全で信頼できるエコシステムを育てるという私たちの共同責任と、すべての人がモバイルにアクセスできるようにするために、さらに多くのことを行う必要があるという点について、重要な教訓を得ました。将来のことを考える際に、私たちは次の 3 つの分野を最重視しています：
デバイスや画面のタイプを問わず、より優れたアプリやゲーム (英語) を提供できるよう支援することで、世界中の誰もが (英語) アプリやゲームがもたらす価値を体験できるようにします。Play ゲームサービスを通じてゲームのリーチを PC へと拡大し、Play Pass のような厳選されたアプリやゲームの定期購入を通じてユーザーに最も関連性の高いアプリやゲームを表示し、Play Offers や LiveOps を通じてユーザーがアプリやゲームの最も興味深い側面を見つけられるよう支援しています。
皆さんのビジネス上の意思決定を支援し、自らのビジネスモデルを進化させ (英語）、進化するプライバシーとセキュリティの状況下で、皆さんのビジネスを安全に成長させ、ユーザーに最高品質の体験を提供できるように、継続して Google Play のツールを進化させ続けます。
アプリやゲーム業界における多様性を向上させる取り組みに投資し、より多くのマイノリティ グループに属する創業者がビジネスを成功させる支援をすることで、すべての人のためのエコシステムを構築することにフォーカスします。2021 年に、あらゆるタイプのビジネスが成功できるよう、単一のサービス手数料モデルから移行し、今後も多様性あるアプリのエコシステムをサポートするために複数のプログラムを用意しました。
インディー ゲーム フェスティバルや Accelerator (英語) プログラムを通じて、経験豊富で成功した創業者が次世代のデベロッパーに投資してきたこと、また、Change the Game (英語) イニシアチブやアクセシビリティの取り組みが有意義な影響を与えていることから、Google は、エコシステムについて前向きな見方をしています。次の 10 年間も、アフリカやカリブ海のヘアスタイルの認知度を高めるための着せ替えゲーム、Frobelles を制作した 9 歳のアリッサとその母親のような多くの創業者 (英語) を、#WeArePlay (英語) ファミリーに迎えられることを楽しみにしています。
どこにいても、誰もがモバイルを使えるようにする、という私たちの大胆な目標に不可欠な存在でいてくださる皆さんに感謝します。私たちは長い道のりを歩んできましたが、まだまだこれからです。私たちは、皆さん一人ひとりに刺激を受け、感謝し、今後も皆さんの成功のために尽力し続けます。皆さんが次に何を創り出すのか、そして皆さんが私たちを駆り立て、実現する新たな地平を見ることを楽しみにしています。
感謝を込めて
Purnima Kochikar
この記事は Takeshi Hagikura による Android Developers Blog の記事 " Android Studio Chipmunk" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今回は、Android Studio Chipmunk 🐿 安定版のリリースについてお知らせします。Android Studio は、Android アプリ開発の公式 IDE です。これは小さな機能リリースですが、最新の IntelliJ アップデートが含まれています。また、品質と安定性に多くの時間をかけており、このリリースだけで 175 以上の品質の問題に対応しています。
Android Studio の最新安定版を使いたい方は、さっそくダウンロード (英語) してください！
Android Studio Chipmunk のすべての新機能のリストを次に示します。
Jetpack Compose のデベロッパーが、Compose で作成したアニメーションを調査したりデバッグしたりできる機能です。この機能はこれまで試験運用版でした。コンポーザブル プレビューにアニメーションが記述されていれば、ある時間でのアニメーションの正確な値を調べたり、アニメーションの一時停止やループ、早送り、スロー再生ができます。この機能は特に、アニメーションとデザイン仕様をフレーム単位で比較する際に役立ちます。
現在の Compose アニメーション プレビューでは、AnimatedVisibility と updateTransition がサポートされています。今後、さらに多くの種類のアニメーションがサポートされる予定です。
Android Studio Chipmunk では、表示されるジャンク情報が更新されており、ジャンクの種類などが含まれるようになっています。想定期限と実際の期限も表示されるので、ジャンクの実際の原因を見つけるのに役立ちます。このジャンク情報は、API レベル 31（Android 12）以降の Android Emulator または実機を使う場合に表示されます。詳細については、こちらを参照してください。
Chipmunk では、Build Analyzer に新しい Jetifier チェックを導入しました。これにより、Jetifier フラグをオフにするとビルド時のパフォーマンスを改善できる場合に通知されます。
Jetifier フラグは、サードパーティ製ライブラリを AndroidX を使うように自動移行するもので、現在も大半の Android Studio プロジェクトで有効になっています。しかし、ほとんどのライブラリ エコシステムがネイティブに AndroidX をサポートするように移行されているため、このフラグをオンにしている場合、ビルドに不要なオーバーヘッドが追加されることになります。その場合、フラグをオフにすると一般的にビルド時間を 5～10% 短縮できます。
Android Studio Chipmunk での Android 固有の機能の数は少ないものの、このリリースには IntelliJ 2021.2 プラットフォーム メジャー リリース 😎 が含まれており、プロジェクト全体の分析、新しい強力なパッケージ検索 UI、ワークフローを高速化する IDE アクションの拡張など、多くの新機能が搭載されています。詳細はこちら (英語) をご覧ください。
Android Studio Chipmunk 🐿 は見逃すことができないアップデートです。短期間でのリリースでしたが、新しいバージョンの IntelliJ、IDE の品質やパフォーマンス、安定性改善に向けたたゆまぬ作業、そしてここで紹介した機能などが詰まっています。さっそくダウンロード (英語) してお試しください！
いつものように、気に入った機能や問題点、新機能の提案などのフィードバックは大歓迎です。バグや問題を見つけた方は、問題を送信してください。最新機能に関する情報をいち早く得るには、私たち Android Studio 開発チームを Twitter と Medium でフォローしてください。
この記事は Sameer Samat による Android Developers Blog の記事 " Exploring User Choice Billing With First Innovation Partner Spotify " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
大切なデベロッパーの皆さんとの密接なパートナーシップと皆さんからのフィードバックを活用し、進化を続けてこなければ、私たちはここにいないでしょう。例えば、パートナーからのフィードバックや競争に対応することで、プラットフォームを利用するすべての開発者が成功できるよう手数料モデルを進化させ、現在では 99% のデベロッパーの皆さんが 15% 以下のサービス手数料の対象となっています。
最近、アプリストアの課金システムの選択肢をめぐる議論が活発になっています。Google はこの議論を歓迎し、本ブログで、Google Play のデベロッパーとともに取り組んでいるエキサイティングなパイロット プログラムを紹介したいと思います。
ユーザーが Google Play を選ぶ理由は、Google Play が安全なアプリ体験を提供することを期待しており、これらにはユーザーのデータや支払い情報などを保護するアプリ内課金システムも含まれます。Google Play の課金システムは、プライバシーと安全性に関する最高水準の基準を満たすように構築されており、ユーザーがアプリ内課金を行う際に、重要な支払いデータが危険にさらされることが無いと安心してもらえるようにしています。
Google Play からアプリをインストールする際に、引き続き Google Play の課金システムを利用する選択肢をユーザーに提供すべきだと私たちは考えています。また、代替の課金システムが、ユーザーの個人データや機密性の高い金融情報を保護する上で、同様に高い安全基準を満たすことが極めて重要だと考えています。
先日、韓国のユーザー向けに、Google Play の課金システムに加えて、追加の課金システム (英語) を選択できるようにしました。それを踏まえて、Google の理念 (英語) に基づいて、他の一部の国でも、ユーザーによる選択制の課金方式を試行することをお知らせします。
このパイロット プログラムでは、少数の対象デベロッパーが、Google Play の課金システムの隣に、追加の課金オプションを提供できるようにし、エコシステムへの投資能力を維持しながら、ユーザーにこの選択肢を提供する方法を模索することを目的としています。これは重要なマイルストーンであり、モバイル、デスクトップ、ゲーム機を問わず、主要なアプリストアにおいて初めての取り組みです。
Google は、Spotify を皮切りに(英語)、デベロッパーの皆さんとパートナーシップを組み、ユーザーが選択できる課金方法のさまざまな実装を探っていきたいと考えています。Spotify は、世界最大規模の定期購入のデベロッパーであり、グローバルに展開し、多様なデバイスのフォームファクタに対応していることから、私たちにとって最初のパートナーです。両社 は、ユーザーのアプリ内課金に革新をもたらし、さまざまなデバイスで魅力的な体験を提供することで、より多くのユーザーに Android プラットフォームを活用してもらうために協業していきます。
Spotify は、Google Play の課金システムを、現在の課金システムとともに導入することになりますが、最初のパートナーとしての Spotify からの視点は、非常に貴重なものです。このパイロット プログラムは、ユーザーによる課金方法の選択が、さまざまな国のユーザーや、さまざまな規模やカテゴリーのデベロッパーにとって有益かどうか、またどのように機能するかについての理解を深めるために役立つことでしょう。
Spotify のフリーミアムビジネス最高責任者 Alex Norström 氏は、次のように述べています。「Spotify は何年も前から、アプリのデベロッパーが自由にイノベーションを発揮し、公平な場で競争できるようにすることを目指しています。今回、Google と共に、開発者、ユーザー、そしてインターネットのエコシステム全体にとっての課金方法の選択肢と機会について、このようなアプローチを模索できることを嬉しく思っています。この協業が、他の業界にも利益をもたらす道を切り開くことを期待しています。」
このプロセスには時間がかかり、デベロッパー コミュニティとの密接な協力も必要になることを理解しています。しかし、このように最初の一歩を踏み出せたのは喜ばしいことだと感じており、今後数か月の間にさらに詳しい内容をお知らせしていく予定です。
.gif)
.gif)
