この記事は Google Play Games、ディレクター、Arjun Dayal による Android Developers Blog の記事 "Com2uS brings a seamless multi-platform gameplay experience with Google Play Games on PC" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
サマナーズウォー：クロニクルは、韓国のゲーム デベロッパー Com2uS が制作し、2023 年 3 月に全世界に向けてリリースされたモバイル MMORPG です。サマナーズウォー シリーズは、これまでに 1 億 8,000 万ダウンロードを突破して 27 億ドル以上を売り上げています。ファンタジーの世界でさまざまな召喚獣を育てて他のプレーヤーと対戦する、世界で最も人気のモバイルゲームの 1 つです。
Com2uS は、常に新しいコンテンツやアップデートをリリースすることで新鮮さと面白さを維持しており、そのプレーヤー コミュニティは 10 年近くにわたって拡大し続けています。Com2uS は、いつでもどこでも楽しめる最適な環境を提供するため、クロニクルに PC 版を追加することを決断しました。Google Play Games (ベータ) でモバイルゲームを拡張して PC でプレイできるようにし、臨場感あふれるハイエンドのゲーム エクスペリエンスを既存のプレーヤーに提供するとともに、新たなユーザーにリーチすることにしたのです。
PC 版 Google Play Games (ベータ) を利用すると、モバイル版と PC 版を、同じ Android ビルドを使って簡単かつスムーズに統合できます。数多くのデベロッパー ツールが用意されており、いくつかの最適化手順を実施するだけで PC 版のゲーミング エクスペリエンスを作成できます。PC 版 Google Play Games (ベータ) プレイリスト (動画/英語 - 日本語字幕あり) を視聴し、実装に関する手順の詳細を確認しましょう。
Com2uS チームは、タブレットや折りたたみ式デバイスなど、大きな画面で楽しむための入力サポートも追加しました。サマナーズウォー：クロニクルは現時点で、キーボードとマウスに加え、ユーザーからの要望が多かったゲーム コントローラもサポートしています。クロス プラットフォーム対応であることを念頭に、ユーザー エクスペリエンスを最適化することも重要でした。たとえば、すべてのプラットフォームで簡単に操作できる直感的なゲーム インターフェースにすること、サイズの異なる画面ごとに UI を調整すること、ゲームの操作についてわかりやすい説明を提供することなどが必要になりました。
プラットフォームごとにグラフィック設定を最適化するために Com2uS がメインのグラフィック API として選択したのが、マルチプラットフォーム対応の高パフォーマンスな Vulkan です。ハイエンドのモバイル デバイスを使用するプレーヤーでも、過熱を防ぎバッテリーを長持ちさせるため、柔軟な画質設定を好む傾向にあります。Com2uS は Vulkan を使用することで、主要なユーザー層が PC でもモバイル デバイスでも最適な画質でプレイできるようにしています。
Com2uS は PC 版デベロッパー エミュレータを使用してユーザーと同等の環境を再現し、さまざまなプレーヤー設定でビルドをテストしてデバッグすることができました。このエミュレータは、複数のアスペクト レシオを効率的にテストできるように設計されています。開発やデバッグにおいては、Google Play ストアから直接アクセスすることも、ADB を介してアクセスすることも可能です。サマナーズウォー：クロニクルは Unity で開発されているため、エミュレータを自動的に検知して直接デプロイすることができました。PC 版 Google Play Games エミュレータは、近日中にすべてのデベロッパーの皆様にご利用いただけるようにする予定です。なお、Unity、Unreal、Cocos などのゲームエンジンも引き続きサポートいたします。
2022 年 11 月、Com2uS はサマナーズウォー：クロニクルの PC 版とモバイル版を同時にリリースしました。プレーヤーはすでに、Google Play Games (ベータ) を通じ PC とモバイルの両方でゲームを楽しめるようになっています。PC 版のリリースによって、大きな画面とより高性能なハードウェアでのプレイが可能になり、新たなレベルのゲーム体験が提供されるようになりました。
また Google Play Games サービスにより、プレーヤーは新しいデバイスでゲームを起動してもゲームの進行状況を自動的に同期でき、どこにいても特典や Google Play Points の収集を継続できます。
日本のすべてのプレーヤーを対象に Google Play Games (ベータ) への登録受け付けを開始しています！PC 版 Google Play Games (ベータ) で、臨場感あふれるシームレスなマルチプラットフォーム ゲーム体験をプレーヤーに提供しましょう。ベータ プログラムへの参加をご希望の場合は、今すぐこちら (英語) からお知らせください。
2023 年 4 月 19 日時点、PC 版 Google Play Games (ベータ) は 14 カ国でダウンロードが可能です。
詳しくは g.co/googleplaygames をご覧ください。ゲームタイトルは地域ごとに異なる場合があります。
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は Android team による Android Developers Blog の記事 " U-NEXT sees 1.5X increase in tablet installations after boosting support for large screens " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
日本最大級の国内ストリーミング サービスかつデジタル コンテンツ サービスである U-NEXT は、ユーザーが好むコンテンツを表示するための新しい手法を常に模索しています。U-NEXT では、映画、アニメ、ライブ配信、マンガ、雑誌、電子書籍など、1,200,000 以上の作品を単一のアプリで利用できます。
UX を改善するための手法を常に模索し続けている U-NEXT は最近、Android タブレットや Chromebook などの大画面デバイスや折りたたみ式デバイスの市場が拡大している点に着目し始めました。そこで、U-NEXT のエンジニアは、大画面デバイスや折りたたみ式デバイスの独自の強みを活かして、コンテンツの視聴方法を改善できるのではないかと考えました。たとえば、大画面デバイスで利用できる優れたマルチウィンドウ機能を組み込むことで、多種多様な情報を表示できるようになったり、折りたたみ式デバイスの UX を改善すれば、従来の紙の本のような読書体験をうまく再現できるかもしれません。
ただ、大画面デバイスや折りたたみ式デバイスで U-NEXT のアプリを使用している際に、バグが発生することもありました。たとえば、U-NEXT を大画面デバイスで開いた場合に、重要なボタンが隠れてしまい、これらのナビゲーション ツールがページのどこにあるかユーザーが探さなければならなくなっていました。
そこで、UX を大幅に見直して Android の大画面デバイスや折りたたみデバイスにより対応できるようにするために、U-NEXT のチームは、既存のバグを一掃してから、大画面を最大限活用できる機能を追加するという 2 段階でプロジェクトに取り組みました。
バグを一掃する
アプリ内の重要なナビゲーション ボタンが見えなくなるという問題に対処するために、U-NEXT のエンジニアは ConstraintLayout (英語) を使用して、表示領域を制限する境界を設定しました。これにより、UI 要素が画面外に押し出されてしまうことを防止でき、また、画面のサイズによらずに適切な向きで表示されるようになります。
また、U-NEXT のアプリが大画面デバイスで適切に表示されないこともありました。たとえば、ユーザーが閲覧できる動画の一覧を表示するページは、通常、ヘッダーとキュレートされた動画一覧で構成されます。本来は動画の一覧がページ上のほぼ全体に表示されるはずですが、大画面の場合、ヘッダーが画面上のほとんどのスペースを占有してしまっていたため、動画コンテンツの操作がしづらくなっていました。U-NEXT のチームは、大画面でのヘッダー画像の幅を制限することで一覧の表示スペースを確保し、大画面デバイスを使用するユーザーが操作しやすくして、この問題を解決しました。
ユーザーが U-NEXT のアプリで書籍を読む場合、画面のタップ操作で横方向のスクロールバーを表示でき、文章内を迅速かつ簡単に移動できます。ただ Chromebook の場合、このナビゲーション ツールは表示されませんでした。
U-NEXT の Principal Engineer、三輪 智也氏は次のように述べています。「もともと、ユーザーのタップ時に Chromebook が全画面表示になっているかどうかの判定には、SystemUiVisibility を使用していました。全画面表示ではないことを SystemUiVisibility が検出した場合に、コントローラが表示される仕組みでした。ただ、Chromebook では SystemUiVisibility が変更されても、このリスナーが呼び出されないため、コントローラが表示されませんでした」
そのため、Chromebook で SystemUiVisibility が変更された場合に、コントローラの表示を処理する方法を変える必要がありました。このバグを修正することで、Chromebook で画面をタップすると、SistemUiVisibility の変更とコントローラの表示 / 非表示処理が同時に行われるようになったため、ユーザーが直面していた問題が解決されました。
U-NEXT のデベロッパーが対処した最後のバグは、視聴時にユーザーが折りたたみ式デバイスを折りたたんだ際に、動画が一瞬途切れてしまうというものでした。コンテンツの視聴時にデバイスを折りたたんでもシームレスに処理されなければなりませんが、ディスプレイを折りたたむ際にアクティビティを自動で削除して再作成するため、動画が一瞬途切れていたのです。
U-NEXT のデベロッパーは、この構成の変更を Android で自動的に処理するのではなく、手動で処理するようにアプリを変更しました。チームは、onConfigurationChanged() を使用して変更をオーバーライドし、UI 要素の削除と再作成が自動的に行われないようにしました。これにより UI 要素が維持され、動画の再生が途切れないようになりました。
さまざまなフォーム ファクタを活用する
U-NEXT はユーザー エクスペリエンスが大幅に向上することを期待し、機能刷新の一環として、従来型のナビゲーション バーをナビゲーション レール (英語) に置き換えました。
三輪氏は次のように述べています。「快適なユーザー エクスペリエンスを提供するという点に関して言えば、目的の箇所に手が届きやすいということが重要になります。従来型のナビゲーション バーの場合、中央にあるボタンに手が届きづらいです。ナビゲーション レールであれば簡単に手が届きます。」
次に U-NEXT のチームは、読者が折りたたみ式デバイスで電子書籍を読んでいる際に、コンテンツを 2 ページの見開きで表示できるように改善を加えました。折りたたみ式デバイスが縦向きの場合、通常は 1 ページのみが表示されます。ただ、ほとんどの折りたたみ式デバイスには 2 ページを表示できる十分なスペースがあります。そのため、U-NEXT のデベロッパーは、縦向きか横向きかによらずに、あるいは、デバイスが少し折りたたまれている状態でも常に 2 ページの見開きが表示されるようにしたいと考えました。
また、U-NEXT のチームは、大画面デバイスや折りたたみ式デバイスでのユーザー エクスペリエンスをさらに改善するために、生活の質を上げられるちょっとしたアップデートも加えました。このアップデートには、大画面デバイスでの Google Play アプリ内課金への対応の強化、ピクチャー イン ピクチャー (英語) の表示の最適化などが含まれています。
Android であれば最適化が簡単
U-NEXT チームは、大画面デバイスや折りたたみ式デバイス向けにアプリを簡単に最適化できたことに驚いていました。U-NEXT は、Android のデベロッパー リソースを活用することで、時間と労力を最小限に抑えながら、U-NEXT のアプリを使用してさまざまなデバイスでコンテンツを視聴する方法を改善できました。
三輪氏は次のように述べています。「そこまで難しくはありません。ナビゲーションを導入することは比較的簡単でしたし、アプリが基本的な画面の回転に対応していれば、折りたたみ式デバイスへの対応も一般的にそれほど難しくはありません。」
大画面により対応するように U-NEXT アプリをアップデートしてから、タブレットでのインストール数は 1.5 倍になりました。また、大画面デバイスを使用するユーザーの視聴時間も、10% 以上増加しています。
今後、U-NEXT のチームは、マウスやキーボードとの互換性の向上、詳細なリスト表示の導入による検索機能の強化、テーブルトップ モードのサポートの推進、簡単にコンテンツを共有できるドラッグ＆ドロップ機能の実装など、引き続き大画面デバイス向けの機能を強化していく予定です。
U-NEXT は、最近のマテリアル デザイン 3 (英語) のアップデートをはじめ、Android の増え続ける大量のドキュメントにさらにリソースが追加されたことを歓迎しています。これによって、大画面デバイスや折りたたみ式デバイスを利用するユーザーが拡大し続ける状況にもさらに対応しやすくなります。
大画面デバイスへの最適化を今すぐ開始する
大画面デバイスや折りたたみ式デバイスなど、新しいフォーム ファクタを使用するユーザーの数は増加しています。そのようなデバイスを使用するユーザーをサポートする方法は Android の大画面ギャラリーの例を参考にしながら学べます。
この記事は Google Play、スタッフ ソフトウェア エンジニア、Harini Chandrasekharan による Android Developers Blog の記事 "Feature Engineering in the Google Play Store" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
10 年前の 2012 年にスタートした Google Play ストアは、Android の中核になっており、世界中で数十億人のユーザーと、世界中で増え続けるアプリやゲームのコレクションを結びつけています。
ここでは、世界最大の Android マーケットプレイスを支えるインフラストラクチャを設計するうえで必要なことを紹介するために、その舞台裏をのぞいてみることにしましょう。コンシューマー向けソフトウェアの世界を考えるなら、既製のエンジニアリング ソリューションでは、 Google のスケールが求める要件を満たすことが難しいことは当然です。そのため、Google のすべてのシステムは Google Play ストアのユニークな可用性、品質、遅延の要求を満たすために、慎重に作られ、機能を改善し続けることで磨かれています。
機能とは、フォーマット、コンテンツ、コンテンツの配置、ページ レイアウト、情報アーキテクチャなど、ユーザーが触れるものを指します。フォーマットとは、Google のレコメンデーション システム、広告主、販売者など、さまざまなソースから取得されるアプリのコンテンツをどのように UI に表示するかを表します。ここで目指すのは、ユーザーが Google Play ストアを操作しているときに最も関連性の高いアプリやゲームを提示できるように、適切なコンテンツと UI を組み合わせてオーダーメイドの体験を実現することです。
ユーザーを対象とした機能では、ユーザーの意見や選択、デベロッパーのエコシステムや需要がインフラストラクチャよりも速く変化することがほとんどです。そのような環境でエンジニアが直面する最大の課題は、スケーラビリティやパフォーマンスの制約の中で、陳腐化しないだけでなく、ユーザー領域のニーズにも応えられるインフラストラクチャをいかにタイムリーに設計するかという点です。そのようなダイナミックな領域におけるエンジニアリングの課題について、いくつかを詳しく取り上げることにしましょう。
Google Play ストアのようなデータドリブンな組織では、あらゆる重要なものを計測する指標が作られています。次に挙げるのは、成功を測定し、追跡する際に役立ついくつかの特性です。
プロダクトやビジネスの指標 - 対象のプロダクトやサービスに固有な指標です。新たな処理に対して A/B テストを実施し、この指標の変化を測定すれば、意思決定に多くのトレードオフが伴う場合などの信頼性が高まります。
パフォーマンス - レイテンシ、エラー率、可用性の測定は、ほぼすべてのサービスの根幹を成しており、それには正当な理由があります。このような基本指標から、ユーザー エクスペリエンスやプロダクトの認識を細かく追跡できるので、これを把握することは不可欠です。
システム健全性 - リソースの使用率やフリートの安定性を追跡する内部システム指標です。
最も重要なのは、Google Play ストアの要件までスケーリングでき、ユーザーのスムーズな操作と応答の速さに必要なパフォーマンス基準を満たすバックエンド システムを設計することです。エンジニアリングの観点から見れば、インフラストラクチャは継続的に進化してビジネスニーズを満たせるものでなければなりません。Google Play ストアも同じで、ストアのインフラストラクチャはこの 10 年で何度も進化を遂げ、現在ユーザーが利用している新機能に対応しています。それだけでなく、モダナイズによって、とりわけ重要なレイテンシの削減などの技術的負債の解消も行っています。
課題 : 多くの場合、機能には長期にわたる大量の反復作業が必要です。そのため、すべての機能要件を満たすインフラストラクチャの開発を計画するのは困難です。
実験主導のやり方では、大規模な機能をすばやく構築するための最適なアプローチによって、技術的負債が生じることが多くなります。技術的負債にはさまざまな形があります。うまく動作せず、クリーンアップできない過去の機能の遺産が積み重なり、パフォーマンスに影響が生じ、コードのエラーが起きやすくなり、テストが難しくなります。
課題 : 数百名のエンジニアを抱える大規模組織では、多くの機能が独立して並行に開発されることがほとんどです。
インフラストラクチャの再利用やイノベーションの共有は、大幅にスピードを落とさない限り、実現できない場合がほとんどです。多くの場合、プロダクトが急速に進化する領域では、システムを柔軟にするために組み込むさまざまなレバーやノブに大量の不確実性が存在します。レバーが多すぎると、システムの複雑さが大幅に増す場合があります。レバーが少なすぎると、反復作業にかかるコストが膨大になります。この 2 つの間のバランスを見つけることは、この領域のフィーチャー エンジニアリングの中核の 1 つです。
課題 : 多くの場合、優れたエンジニアリング ソリューションを開発する時間のために、機会費用が発生します。
実験にかかる時間は、ユーザー向けの機能ソリューションを設計するときに念頭におくべき、特に重要な指標の 1 つです。反復作業を速くし、レイテンシなどのパフォーマンス SLO を満たせる柔軟な設計が理想です。
実際には、特にユーザーに影響する変更の影響を見積もる場合は、大量の推測が必要になることがほとんどです。過去のデータや教訓を活用して確実に見積もれる状況もありますが、試したことのないまったく新しいアイデアに対しては十分な方法ではありません。
Google Play ストアがこういった課題をどう解決し、最先端のイノベーションを実現しているかを確認してみましょう。
市場投入までの時間（ユーザーに機能を届けるまでの時間）を最適化し、それがアプリのインストール数などのストアのビジネス指標にどう影響するかを A/B テストによって計測することが最も重要です。データに基づいて高速に反復することで、最終的な機能を調整し、目指す最終状態に向かうことができます。Google には、世界規模で A/B テストができる複数の自社製テクノロジーがあります。デベロッパーが分析ではなくコーディングに時間をかけることができるように、指標提示ツールとシームレスに統合され、A/B テストなどを簡単かつスムーズに行えるようになっています。
何を開発するのか、それが Google の品質標準を満たしているか、そしてエンジニアリング費用とそれが解決するユーザーのニーズを理解しているか、といった問いは、いずれも何かを設計する前に答えを出すべき重要な問いです。そのため、プロダクト マネージャーと密接に連携してフィーチャー エンジニアリングを実施する場合がほとんどです。プロダクトの成功に向けて重要なのは、妥当なエンジニアリング時間で構築でき、ユーザー ジャーニーに一致する完全な実用最小限の製品（MVP）に近づけることです。
反復作業を頻繁に行い、短時間で MVP を開発する方式には、いくつかの短所が存在することがほとんどです。その最も大きなものが技術的負債です。スピードアップのための最適化の際に手を抜くと、（開始できない指標のため）コードが陳腐化したり、試験運用版フラグのまま捨てられてしまったりすることがあります。これを放置すると、テストや保守、今後の開発速度に影響することが多くなります。また、優れた最新フレームワークを使うことで、最後の数ミリ秒のレイテンシを解消し、開発を簡単にして長期的なメリットにつなげることができます。昔から、リファクタリングや完全な書き換えによってインフラストラクチャを頻繁にモダナイズすることは、コードの設計不良の兆候と見なされることがあります。しかしこれは、フィーチャー エンジニアリングで必要になる大きなトレードオフの 1 つです。たとえすばらしいインフラストラクチャがあったとしても、ユーザーがその機能を使わないなら、何の役にも立たないからです。
この記事は エンジニアリング部門副社長、Dave Burke による Android Developers Blog の記事 " Android 14 Beta 1" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android は、年間を通して機能強化と新機能を提供します。Android の継続的改善においては、Android ベータ版プログラムのフィードバックが重要な役割を果たします。Android14 デベロッパー サイト (英語) には、Pixel にダウンロード (英語) する方法やリリース スケジュール (英語) など、ベータ版に関する多くの情報が掲載されています。皆さんの感想を聞く (英語) のを楽しみにしています。そして、Android を誰もが使えるプラットフォームにするために、引き続き協力をお願いいたします。
Android 14 は、これまでのリリースで行われたタブレットや折りたたみ式のフォーム ファクタをサポートするための作業が基礎となっています。また、デザイン アイデア集や開発ガイドなど、アプリのエクスペリエンスを洗練するためのツールやリソースも作成しています。
Android オペレーティング システムでは、等しく重要な 2 つの異なるパッケージによって機能を実現しています。それは、サービスを提供するフレームワークと、ユーザーがそのサービスを操作するために使うシステム UI です。システム UI は Android のリリースのたびに微調整していますが、ベータ版 1 に導入されているものをいくつか紹介します。
新しくなった戻る矢印
システム共有シートの改善
また、ダイレクト シェア ターゲットのランキングを決定するために、さらに多くのアプリシグナルが使われるようになります。シグナルは、pushDynamicShortcut (英語) を呼び出し、対応する機能バインディング (英語) を使ってショートカットの使用方法を報告することによって提供します。
Android 14 では、アプリを際立たせるために、新しいグラフィック機能が追加されています。
パスのクエリと補間に対応
Android の Path API (英語) は、ベクター グラフィックの作成とレンダリングの強力で柔軟な仕組みです。Android 14 より、パスを照会して内容を確認できるようになります。今回の API アップデートには、構造が完全に一致するパス間の補間機能が含まれています。これにより、モーフィング効果を実現できるようになります。また、AndroidX ライブラリによって API 21 までの下位互換性が提供されます。詳細はこちら (英語) をご覧ください。
アプリ別の言語設定
Android 14 では、アプリ別の言語設定が強化され、Android の [設定] のアプリ別の言語リストに表示される言語セットを動的にカスタマイズ (英語) できるようになります。また、IME から現在のアプリの UI 言語を取得できるようになります。Android Studio Giraffe Canary 7 と AGP 8.1.0-alpha07 より、アプリ別の言語設定をサポートするようにアプリを自動構成できます。Android Gradle プラグインは、プロジェクトのリソースに応じて LocaleConfig (英語) ファイルを生成し、このファイルへの参照を生成されたマニフェスト ファイルに追加します。そのため、言語サポートを変更する際に、手動でファイルを作成したり更新したりする必要はなくなります。詳しくは、アプリ別言語の自動サポートをご覧ください。フィードバックもお願いいたします。
障がいのある方向けのユーザー補助サービスのみに公開範囲を限定する
Android 14 では、accessibilityDataSensitive 属性が導入されます。これを使うと、障がいのあるユーザーをサポートするものであることを宣言したユーザー補助サービスのみに、特定のビューを公開できるようになります。Google Play ストアからダウンロードするアプリでは、Google Play プロテクトがこの宣言の信頼性を保証します。TalkBack など、障がいのあるユーザーをサポートするものであることを宣言したサービスは、この属性の影響を受けません。
アプリでは、以下の目的で accessibilityDataSensitive を使うことを検討できます。
ユーザーデータを保護する（個人の詳細や平文パスワードなど）
重要なアクションが意図せずに実行されることを防ぐ（送金、ショッピング アプリでの決済など）
まだ Android 14 でアプリの互換性テストを実施していない方は、ぜひこのタイミングで行っておきましょう！Android 14 がベータ版になったので、デベロッパーだけでなく、先行ユーザーもアクセスできるようになります。今後数週間のうちに、Android 14 で皆さんのアプリを試すユーザーが増え、見つかった問題が報告される可能性があります。
互換性テストを実施するには、公開しているアプリを Android 14 ベータ版を実行しているデバイスかエミュレータにインストールし、アプリのフローをすべて試します。重点的にテストを実施すべき点については、動作の変更点 (英語) を確認してください。見つかった問題を解決できたら、できる限り早くアップデートを公開しましょう。
このタイミングで、アプリのターゲットを Android 14 にする準備を始めることをおすすめします。開発者向け設定で、アプリの互換性変更を切り替えてテストを実施しましょう。
今回のベータ版のリリースには、Android 14 の機能を試し、アプリをテストしてフィードバック (英語) を提供するために必要なすべてのものが含まれています。タブレットや折りたたみ式でアプリのテストを始める一番簡単な方法は、Android Studio SDK Manager (英語) の最新プレビュー版で、タブレットまたは折りたたみ式設定の Android Emulator を使うことです。ベータ版フェーズに入ったため、こちらからサポート対象の Pixel デバイスを登録するだけで、今回と今後の Android 14 ベータ版やフィーチャー ドロップのベータ版アップデートを無線（OTA）で受け取ることができます。Pixel デバイスをお持ちでない方は、Android Studio で 64 ビット システム イメージと Android Emulator を使うことができます。
Android 14 向けに最高の開発をするには、Android Studio Giraffe (英語)（または Giraffe 以降の最新版）の最新プレビュー版を使うことをおすすめします。セットアップ (英語) の完了後にやるべきことは、以下のとおりです。
新しい機能や API を試す - API の確定に向けて、皆さんのフィードバックが不可欠です。問題は、フィードバック ページ (英語) のトラッカーで報告してください。
現在のアプリの互換性をテストする - アプリが Android 14 のデフォルト動作の変更による影響を受けるかどうかを確認します。Android 14 を実行しているデバイスかエミュレータにアプリをインストールし、幅広くテストします。
変更をオプトインしてアプリをテストする - Android 14 では、動作の変更点はターゲットに新しいプラットフォームを指定した場合にのみアプリに影響するようになっており、それをオプトインすることができます。変更点を早めに把握し、評価することが重要です。簡単にテストできるように、変更点のオン、オフを個々に切り替え (英語) られるようになっています。
プレビューやベータ版のシステム イメージと SDK は、Android 14 のリリース サイクル期間を通じて定期的にアップデートされる予定です。
すでに Android 13 QPR ベータ版プログラムに登録しており、デバイスがサポートされている場合は、特に何もしなくても Android 14 ベータ版 1 が利用できるようになります。
ベータ版の入手方法の詳しい説明は、Android 14 デベロッパー サイトをご覧ください (英語) 。
