この記事は Maru Ahues Bouza による Android Developers Blog の記事 " 13 Things to know for Android developers at Google I/O!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
何かを作ってすぐ、スマートフォンだけでなく、テレビ、自動車、タブレット、スマートウォッチを含め、世界の数十億の人々に届けることができるプラットフォームは多くはありません。今年の Google I/O では、このチャンスを最大限に活用していただけるように、Android がたくさんの方法で皆さんをサポートしていることを説明しました。また、最新の Android 開発が、可能な限り多くの共通性をもたせることで、日常生活で使用するあらゆる場面に適したエクスペリエンスを短時間で、かつ簡単に作成できるようになっていることにも触れました。
ここでは、Android デベロッパーが知っておくべきことの上位 13 をまとめています。Jetpack Compose やタブレット、Wear OS、そしてもちろん Android 13 も含まれています! Android の I/O プログラムには、26 のテクニカル セッションと 4 つのワークショップが含まれています。さらに、もう 1 つの #TheAndroidShow (動画/英語) のエピソードとして、Android ライブ Q&A も開催しました。#AskAndroid を使って質問されたツイートはエキスパート チームがライブ配信 (動画/英語) で回答しました。
Android の最新 UI ツールキットである Jetpack Compose は、ダウンロード可能フォント、LazyGrids、ウィンドウ インセット、ネストされたスクロールの相互運用性など、さらに高度なユースケースを実現する API を提供し続けています。また、Live Edit、再コンポーズのデバッグ、アニメーション プレビューといった機能を搭載したツールもサポートします。詳細はブログ投稿をご覧ください。
Android Studio Dolphin ベータ版と Electric Eel Canary を使うと、より多くのことを短時間で行うことができます。Android Studio Dolphin には、Jetpack Compose や Wear OS 開発向けの新機能や機能改善が搭載されています。また、Logcat の操作も新しくなっています。Android Studio Electric Eel には、新しい Google Play SDK Index や Firebase Crashlytics との連携機能が追加されます。さらに、大画面でアプリをテストするための新しいサイズ変更可能なエミュレータや、コンポーズ可能な関数内のコードの変更を即座にデプロイできる新機能 Live Edit も提供されます。Android 開発ツールの新機能 (動画/英語) に関するセッションを視聴し、こちらの Android Studio I/O ブログ投稿をお読みください。
インストール直後のアプリのスピードは、ユーザーの維持率に大きく影響します。そのスピードを高めるために、ベースライン プロファイルを作成しました。ベースライン プロファイルを使うと、アプリやライブラリが Android ランタイムにコードパスの使用方法に関するメタデータを提供できます。ランタイムは、それを使って Ahead-Of-Time コンパイルの優先順位を判断します。コードを一切変更せず、ベースライン プロファイルを追加するだけで、アプリの起動時間が最大 30% 短縮されます!ベースライン プロファイルは、すでに Jetpack の内部で使われています。私たちは、Fragments や Compose といった人気のライブラリにベースラインを追加して、エンドユーザーのエクスペリエンスを向上させています。アプリ フレームワークの新機能 (動画/英語) を視聴し、こちら (英語) の Jetpack ブログ投稿をお読みください。
Google は全力を挙げてタブレットに対応しています。前回の I/O 以降、大画面の最適化に注力した Android 12L をリリースしました。Android 13 にはその機能改善がすべて含まれているだけでなく、さらなる機能追加も行われています。また、来年登場する Pixel タブレットについてもお知らせしました。すばらしい新ハードウェア、アップデートされたオペレーティング システムと Google アプリ、改善されたガイドラインとライブラリ、そして刺激的な Google Play ストアの変更がそろった今こそ、アプリを見直して大画面と Android 13 に対応する絶好のタイミングです。今年の I/O で 4 つのセッションと 1 つのワークショップ (動画/英語) を開催し、大画面のデザイン (動画/英語) から実装 (動画/英語) まで、詳しく説明しているのはそのためです。
Wear OS の最新アップデートが行われた今、ウェアラブルの開発でできることを再考できます。Jetpack Compose for Wear OS は現在ベータ版です。これを使うと、これまでよりも少ないコードで、美しい Wear OS アプリを作成できます。健康とフィットネス関連のデベロッパー コミュニティに大きなイノベーションをもたらすヘルスサービスも、現在ベータ版になっています。そして今回は、Google Pixel Watch を発表しました。Fitbit と Wear OS の長所を合わせ持つもので、今秋発売予定です。ウェアラブルの期待のアップデートの詳細については、Wear OS テクニカル セッション (動画/英語) をご覧いただくか、Jetpack Compose for Wear OS のお知らせ (英語) をお読みください。
Health Connect は、Google と Samsung が密接に連携して作り上げた新しいプラットフォームです。これを使うと、簡単にアプリ同士を接続して、ユーザーの健康とフィットネスに関するデータに安全にアクセスしたり、それらのデータをすべてのアプリとデバイスで共有したりできるようになり、少ない作業で多くのユーザーに簡単にアプローチできます。5 月 11 日より、Jetpack Health から Health Connect にアクセスできるようになりました。詳しくは、お知らせ (英語) を確認するか、I/O のセッション (動画/英語) をご覧ください。
Android for Cars と Android TV OS が、米国やその他の国で拡大を続けています。ネットワークに接続しながら運転したりテレビを見たりするユーザーが増える中、今年は自動車やテレビ向けの開発がさらに簡単になる新機能を導入します。詳しくは、2 日目 (5 月 12 日) に開催された、Android for Cars の新機能 (動画/英語) や Google TV と Android TV の新機能 (動画/英語) に関するセッションをご覧ください。
Android for Cars の Shortcuts API にアクセスできるデベロッパーを拡大することにより、Google アシスタントを搭載したさまざまなデバイスで、音声を使って簡単にアプリにアクセスできるようにしています。この機能は、Wear OS (英語) アプリでも今年中にサポートされる予定です。また、Smarter Custom Intents (英語) を使ってこのようなエクスペリエンスを簡単に開発できるようにしています。具体的には、手間がかかる NLU トレーニングなしに、アシスタントが ML を通してさまざまな形態のユーザークエリを検出できるようにします。加えて、モバイルで音声を使ってアプリを見つけやすくする改善もしています。まずは、Brandless Queries によって、ユーザーが明示的にアプリの名前を話さなくてもアプリを使用できるようにします。また、まだアプリをインストールしていない場合には、App Install Suggestions が表示されてインストールを提案します。こちらの機能 (動画/英語) は、5 月 11 日より既存の App Actions で自動的に有効になりました。
Google Play を活用して皆さんのビジネスを拡大する新しい方法について、Google Play の最新情報をご覧ください。特に重要なのは、ディープリンクや最大 50 個のカスタム掲載情報を作成できる機能、Google Play ストアに掲載したいコンテンツを送信できるデベロッパーを拡大する LiveOps ベータ版、そして柔軟性が増したサブスクリプション販売などです。以上の最新情報の詳細は、ブログ投稿 (英語) をご覧ください。
新しい Google Play SDK Index で、SDK がアプリに適切かどうかを評価しましょう。この新しいパブリックポータルは、特によく使われている 100 以上の商用 SDK が登録されており、SDK がアプリのどんなパーミッションを要求するのか、SDK を使っているアプリの統計、どのバージョンの SDK が最もよく使われているのかといった情報が公開されています。ブログ (英語) 記事を確認し、Google Play の新機能 (動画/日本語字幕付き) や Android 開発ツールの新機能 (動画/英語) についてのセッションを視聴しましょう。
Android のプライバシー サンドボックス (英語) は、無料のコンテンツやサービスへのアクセスを危険にさらすことなく、ユーザーのプライバシーを強化した新しい広告ソリューションを実現する仕組みです。先日、Android のプライバシー サンドボックスの初めてのデベロッパー プレビュー版 (英語) を公開したので、SDK ランタイムと Topics API をいち早く確認できます。これら新技術を予備テストし、どのようにソリューションに採用できるかを評価し、フィードバックを提供してください。
新しい Google Wallet を使うと、Android や Wear OS から日常的に使用する機能に高速で安全にアクセスできます。私たちは、以前 Google Pay Passes API と呼ばれていた Google Wallet API を強化し、汎用パスやパスのグループ化とミックス(イベント チケットとバウチャーをまとめるなど)のサポート、そしてバックエンド統合なしにアプリからパスを直接保存できる新しい Android SDK のリリースしました。詳細については、詳細なブログ記事 (英語) を読むか、セッション (動画/英語) をご覧ください。また、developers.google.com/wallet のドキュメントを確認することもできます。
Android 13 の 2 回目のベータ版が 5 月 11 日にリリースされました。新しい通知パーミッション、プライバシーを保護する写真ピッカー、近くのデバイスとペア設定したり、メディア ファイルにアクセスしたりするパーミッションの改善など、アプリをプライバシーとセキュリティの最新機能に対応しましょう。また、アプリ別の言語設定やテーマ対応アプリ アイコンなどの機能で、アプリを強化しましょう。HDR 動画や Bluetooth LE オーディオなど、最新の標準を使って開発することもできます。こちらから Pixel デバイスを登録すると、すぐに試してみることができます。Android 13 ベータ版は、パートナー製の一部のスマートフォンやタブレット、折りたたみ式デバイスでも利用できます。詳細は、developer.android.com/13 をご覧ください。
ここで紹介した内容は、今年の Google I/O の Android デベロッパー向けハイライトの一部にすぎません。ぜひ Android の新機能 (動画/日本語字幕付き) セッションを視聴して、Google I/O での Android テクニカル トラックの全容を把握してください。全部で 26 のセッションと 4 つのワークショップがあります。ぜひご利用ください!
この記事は Yafit Becher、Ray Brusca による Android Developers Blog の記事 "New Google Play SDK Index helps you choose the right SDKs for your app" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリ デベロッパーは、アプリやゲームに重要な機能やサービスを組み込む際に SDK を利用します。SDK は構成要素として欠かせないものですが、信頼できて安全に使用できる SDK を判断するのは難しいという声がデベロッパーから寄せられています。そのため、皆さんのようなデベロッパーが十分な情報をもとに SDK を適切に決定できることは、数十億ものユーザーに利用される Google Play を安全で信頼できる場所にするための取り組みの一環だと言えます。
2020 年、Google は Google Play SDK Console をリリースしました。これにより、SDK プロバイダが障害レポートや使用統計情報を提供したり、Google Play Console や Android Studio を通してアプリ デベロッパーに重大な問題を公開したりできるようになりました。今回は、さらにコミュニケーションを強化し、透明性を高めるための新たな手段として、Google Play SDK Index をリリースしました。このパブリック ポータルでは、特に広く使われている 100 以上の商用 SDK と、それぞれの SDK に関する分析情報を確認できます。
Google Play SDK Index には各 SDK の信頼性と安全性シグナルが表示されるため、その SDK がビジネスとユーザーに適切であるかどうか、判断できます。
また、SDK を検索 (英語) したり、広告と収益化 (英語) やアナリティクス (英語) といったカテゴリ別に SDK を調べたりすることもできます。Google Play SDK Index では、ビジネスとユーザーに適した SDK を選択できるように、各 SDK について Google Play アプリの使用状況データと SDK コード検出を組み合わせた分析情報を提供しています。たとえば、次の情報を確認できます。
SDK プロバイダは、Google Play SDK Console に登録した SDK について、次のような重要な情報を共有することもできます。
開発ライフサイクルのどの段階であっても、情報に基づいて SDK を選択するために Google Play SDK Index をご活用ください。SDK のデータ ポイント、カテゴリ、ボリュームは今後も追加されていきますので、定期的に最新情報をご確認ください。
さらに詳しくは以下をご覧ください :
この記事は Juan Sebastian Oviedo による Android Developers Blog の記事 " Google I/O 2022: What’s new in Android Development Tools " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 5 月 11 日、Google I/O 2022 の中で、Android Studio Dolphin Beta と Android Studio Electric Eel Canary で利用可能になった新しい機能を発表しました (どちらのリリースもこちら (英語) からダウンロードできます) 。Android アプリを作成する際の生産性を向上させたいというデベロッパーからのご要望を受け、豊富な情報を活用しながらスムーズに開発するための改善です。
Android Studio Dolphin リリースが、安定版に近い品質で提供され、次のような新機能や機能向上を Beta チャネルで利用できます。
さらに新しい Android Studio Electric Eel のプレビュー リリースの機能は、Canary チャンネルでお試しいただけます。
上記の機能は、皆さんからのフィードバックを基にさらに改善を加えてから、より安定したチャンネルでリリースにも昇格されますので、ぜひお試しください。
すべての新機能の実際の動作については、Android デベロッパー ツールの新機能に関するセッションをご覧ください。
次に、Android Studio Dolphin の主な新機能と機能向上について紹介します。
Compose アニメーションの調整
マルチプレビュー アノテーション
Compose 再コンポーズ回数
Wear OS エミュレータ ペア設定アシスタント
Wear OS エミュレータのサイド ツールバー
Wear OS 実行 / デバッグ構成の新しいタイプ
Logcat V2
Gradle マネージド デバイス
次に、Android Studio Electric Eel の主な新機能と機能向上について紹介します。
エミュレータ上の Live Edit
プレビュー上の Live Edit
Google Play SDK Index のインサイト
Firebase Crashlytics に基づく App Quality Insights
サイズ変更可能なエミュレータ
ビジュアル lint チェック
エミュレートされた Bluetooth を使った、2 つの Android Emulator のペア設定
デバイスのミラーリング
まとめると、安定版に近い品質の Android Studio Dolphin Beta では、以下の新機能と機能向上をご利用いただけます。
Jetpack Compose
Wear OS
開発ツール
Android Studio Electric Eel Canary では、以下の新機能と機能向上をご利用いただけます。
Google Play と Firebase
大画面デバイス
Android Studio Dolphin Beta と Android Studio Electric Eel Canary は、いずれもこちら (英語) からダウンロードできます。こちらの手順に従ってインストールし、現在の安定版 Android Studio と共存することができます。ベータ版のリリースは安定版のリリースに近い品質ですが、まだバグが存在する可能性があります。問題が見つかった場合は、こちらのフォーム (英語) でご報告ください。同様に、Canary リリースで問題が見つかった場合や、機能についてフィードバックがある場合もご連絡ください。
問題に関するフィードバックや機能リクエストは、私たちにとって有用です。Twitter や Medium で、Android Studio 開発チームをフォローしてください。
新機能の詳細は、プレビュー リリースノートをご覧ください。 (※翻訳のタイミングによって、英語版と日本語版のリリースノートの説明内容に多少の差があります。)
この記事は Dave Burke による Android Developers Blog の記事 " The Beta for Android 13 is out now: Android 13 Beta 1 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは Android 13 の機能と安定性を向上させる作業を着実に進めています。Android 13 では、プライバシーとセキュリティ、デベロッパーの生産性、タブレットと大画面のサポートという中核テーマを主眼に置いて開発しています。2022 年 4 月 26 日、その作業がサイクルの次の段階に入り、Android 13 最初のベータ版をリリースしました。
Android 13 には、デベロッパーが注目すべきたくさんの機能があります。まずは、新しい通知パーミッションや写真ピッカーなどのプライバシー機能です。そして、テーマ対応アプリアイコン、クイック設定タイルの配置、アプリごとの言語サポートなど、魅力的なエクスペリエンスを開発するために役立つ API があります。さらに、Bluetooth LE オーディオや MIDI 2.0 over USB といった機能も導入されます。ベータ版 1 では、メディア ファイルへのアクセスを細分化した新しいパーミッションの追加、オーディオ ルーティング API の改善などをしています。5 月 11~12 日の Google I/O では、さらに多くのことをお知らせしましたので、ぜひごアーカイブをご覧ください!
このリリースについてのフィードバックを提供してくださる先行ユーザーの皆さんが増えることは大歓迎なので、ぜひベータ版 1 を試してみてください。Android 13 ベータ版 1 は、2022 年 4 月 26 日からサポート対象の Pixel デバイスで試すことができます。こちら (英語) から登録すると、無線(OTA)アップデートを受け取ることができます。すでに Android 13 のデベロッパー プレビューをお使いの方には、今回のアップデートや今後のアップデートがデバイスに無線(OTA)で自動配信されます。いつものように、Pixel と Android Emulator 用のダウンロードも利用できます。アプリの開発やテストを開始する詳しい方法は、Android 13 デベロッパー サイトに掲載されています。
ベータ版 1 では、プライバシーとセキュリティへの注力を続けつつ、ユーザーにとって魅力的なエクスペリエンスを開発するために役立つ新しい API を提供しました。ベータ版 1 には、新しい通知パーミッション、写真ピッカー、テーマ対応アプリアイコン、ローカライズや言語サポートの強化など、以前にお知らせした機能への最新アップデートが含まれています。また、少数の新機能も導入されるので、ぜひ試してみて感想をお聞かせください。
メディア ファイルにアクセスするパーミッションの細分化 - これまで、ローカル ストレージの共有メディア ファイルを読み取るアプリは、READ_EXTERNAL_STORAGE (英語) パーミッションをリクエストする必要があり、このパーミッションが付与されると、すべての種類のメディア ファイルにアクセスできるようになっていました。今回は、透明性とユーザーの制御を向上させるため、アクセスできる共有メディア ファイルのスコープを細分化した一連のパーミッションを新たに導入します。
新しいパーミッションでは、共有ストレージ内の特定の種類のファイルへのアクセスをリクエストすることになります。 (以下、全て英語)
My App が、このデバイスに格納されている音楽などのオーディオ ファイルにアクセスすることを許可する
ユーザーがパーミッションを付与すると、アプリはそれぞれの種類のメディア ファイルに読み取りアクセスできるようになります。シンプルなユーザー エクスペリエンスを実現するため、アプリが READ_MEDIA_IMAGE と READ_MEDIA_VIDEO を同時にリクエストした場合、両方のパーミッションを付与するダイアログを 1 回だけ表示します。アプリから共有メディア ファイルにアクセスしている方は、アプリのターゲットを Android 13 にする際に、新しいパーミッションに移行する必要があります。詳しくはこちらをご覧ください。
Keystore と KeyMint のエラー報告の改善 - 鍵を生成するアプリに対して、Keystore と KeyMint がこれまでよりも正確で細かいエラー インジケーターを提供します。具体的には、java.security.ProviderException (英語) の下に例外クラス階層を追加し、Keystore/KeyMint のエラーコード (英語) や再試行可能なエラーかどうかを含む Android 固有の例外を提供します。また、鍵生成、署名、および暗号化のメソッドを変更して、新しい例外を投げるようにすることも可能です。改善版のエラー報告では、鍵生成の再試行に必要な内容が提供されます。
オーディオ ルーティングの予測 - メディアアプリでオーディオがどのようにルーティングされるかを把握しやすくするため、AudioManager (英語) クラスに新しいオーディオ ルーティング API を追加しました。新しい getAudioDevicesForAttributes() (英語) API を使うと、指定したオーディオの再生に使われる可能性があるデバイスのリストを取得できます。また、オーディオ ストリームを直接再生できるかどうかを把握しやすくするため、getDirectProfilesForAttributes() (英語) API を追加しました。以上の新 API を使うと、オーディオ トラックに最適な AudioFormat (英語) を判断できます。
まだ Android 13 でアプリの互換性テストをしていない方は、ぜひこのタイミングで行っておきましょう!Android 13 がベータ版になったので、デベロッパーだけでなく、先行ユーザーもアクセスできるようになります。つまり、これから数週間のうちに、Android 13 で皆さんのアプリを試すユーザーが増え、見つかった問題が報告される可能性があります。
互換性テストをするには、Android 13 ベータ版を実行しているデバイスかエミュレータに、Google Play などのソースで公開しているアプリをインストールし、アプリのフローをすべて試します。特に注意してテストをするべき点については、動作の変更点を確認してください。見つかった問題を解決できたら、できる限り早くアップデートを公開しましょう。
ベータ版を公開したことで、2022 年 6 月の Platform Stability に近づいています。その時点で、アプリに関連するシステムの動作、SDK/NDK の API、非 SDK リストが確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリをリリースしてください。デベロッパー向けのタイムラインの詳細は、こちらをご覧ください。
ベータ版 のリリースには、Android 13 の機能を試し、アプリをテストしてフィードバックを提供するために必要なすべてのものが含まれています。こちら (英語) からサポート対象の Pixel デバイスを登録するだけで、今回と今後の Android 13 ベータ版やフィーチャー ドロップのベータ版アップデートを無線(OTA)で受け取ることができます。すでにデベロッパー プレビュー ビルドをインストールしている方は、自動的にアップデートを受け取ります。開発を始めるには、SDK をセットアップが必要です。
サポートされている端末で幅広くテストしたい場合は、Android GSI イメージ (英語) の Android 13 ベータ版をお試しください。デバイスをお持ちでない場合は、Android Studio の SDK Manager から最新のエミュレータ システム イメージをダウンロードするだけで、Android Emulator でテストできます。
ベータ版の入手方法の詳しい説明は、Android 13 デベロッパー サイトをご覧ください。
この記事は Android チーム による Android Developers Blog の記事 " Twitter going all in on Jetpack Compose for feature development: greater productivity, less bugs " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
最も広く使われているソーシャル メディア プラットフォームの 1 つである Twitter は、ユーザーとの繋がりを強化する方法を常に探っています。同時に、既存の機能を維持しつつ効率よく新機能を構築するには、デベロッパーをサポートするインフラストラクチャも必要です。Twitter のエンジニアリング チームは、急務だったアプリの UI 基盤のオーバーホール作業に着手するにあたり、Jetpack Compose に注目しました。Compose を使うデベロッパーは、適切な API を簡単に見つけて使うことができます。また、柔軟にコンポーネントのスタイルを設定したり、コンポーネントをモジュール化したりできるので、最終的に少ないコードで多くのことを実現できます。
Android クライアント UI チーム、顧客獲得チーム、Twitter Blue チーム、コミュニティ チームなど、いくつかのチームが開発プロセスを刷新し、Twitter のエンジニアたちはそれに注目しました。「Twitter の複数のチームは、すでに Compose を日常のワークフローに採用しています」と、Twitter のシニア ソフトウェア エンジニアであり、Android アプリでコミュニティ チームのテクニカル リードを務める Sneha Patil 氏は語ります。Compose では、カスタムのテーマや属性の作成や設定作業は不要なので、ビューの場合よりも機能の記述やデザイン要件の実装をかなりすばやく簡単に行うことができます。Jetpack Compose を使うことで、各チームの作業時間が短縮され、効率が上がります。さらに、コードの再利用性が向上し、新しいエンジニアも作業に加わりやすくなります。
Compose では、簡単に動的コンテンツを生成できます。Twitter チームは、Adapter や ViewHolder を使わずに、LazyColumn コンポーザブルで UI を構築しました。それにより、コードの記述プロセスがシンプルになり、レイアウト、テーマ、スタイルをシームレスに動作することができます。記述するコードの行数が減ったことで、Twitter の開発チームはボイラープレートを削減し、開発やリリースの際のバグを減らすことができました。また、UI の実験が可能になり、テストプロセスがスピードアップしました。こういった改善によって生産性が高まったので、デベロッパーは Twitter ならではの機能の開発に時間をかけられるようになりました。
また、Compose を使って、複数のアプリで再利用できるステートレスなコンポーネントの開発も行われています。Compose は柔軟なので、デザイン要件をすばやく簡単に満たすことができ、新しいエンジニアでも経験を積んだエンジニアでも、簡単にテーマやスタイルを設定できます。
このような改善体験を受けて、Twitter は新機能をすべて Compose で開発することにしました。そして、Compose を使ってゼロからコミュニティ機能(ユーザーが興味のあることをディスカッションできる Twitter の専用スペース)を開発しました。これまでビューを使った他の機能の開発で積んできた経験に基づいて Compose で開発したところ、作業時間を大幅に短縮でき、バグも少なくなりました。 「まるで魔法のようでした」と Patil 氏は話します。「Compose は、Android での開発方法を変えるゲーム チェンジャーです」
Compose によって、Twitter エンジニアの UI 開発のスピードと効率が飛躍的に向上しました。デベロッパーは、簡単に Compose を組み込んで開発することができました。そのため、コードのモジュール化、コンポーネントの再利用、依存関係の解消が簡単になり、定期的に UI の実験ができるようになりました。さらに、Compose を使えば、ユーザーの操作、データの更新、異なる画面サイズに反応するコンポーネントが実際の環境でどのように見えるかがわかるので、安心感も深まりました。
各チームが最初にこのような成功を収めたことで、Twitter の他の開発チームも Compose を採用するようになりました。今では、複雑なレガシー コンポーネントを扱うエンジニアでさえ、Compose の採用を検討しています。
最終的に、Compose の導入によって、ビューを使っていたときに生じていた多くの問題を解消できただけでなく、ワークフローに楽しさがもたらされることにもなりました。一部のデベロッパーは、すでに古い手法をこの優れた手法に置き換えようとしています。「Compose で書くのが楽しみです。もう XML レイアウトを触ることはないでしょう。UI 開発が簡単になるだけでなく、楽しく、直感的になります」と、Twitter の Android クライアント UI ソフトウェア エンジニア、Yoali Sotomayor Baqueiro 氏は語りました。
UI 開発を Compose で最適化しましょう!
この記事は #TheAndroidShow 共同司会、Florina Muntenescu、Huyen Tue Dao による Android Developers Blog の記事 " Happening now! #TheAndroidShow: Tablets, Jetpack Compose & Android 13 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
※翻訳者注:本記事はライブ配信中 (2022 年 3 月 9 日) に投稿されたものです。日本語記事投稿時点では既にライブ配信が終了していることをご了承ください。
#TheAndroidShow の新しいエピソードを配信しましたので、ぜひご覧ください。このエピソードでは、Jetpack Compose と Android 13、そしてすべての Android タブレットのアップデートについて、その内側を紹介します。
※翻訳者注:当日のライブ配信では、Android タブレットについてどうしても聞きたいことがある方と、#AskAndroid を使って、専門家たちにリアルタイムでお答えいただく機会もありました。
今回の #TheAndroidShow では、まず Android の最新ネイティブ UI ツールキットである Jetpack Compose についてお話ししました。私たちは、2 月にJetpack Compose のバージョン 1.1 をリリースしました。このバージョンには、フォーカス処理の改善、タッチ ターゲットのサイズ設定、ImageVector のキャッシュ、Android 12 のストレッチ オーバースクロールのサポートといった新機能が含まれています。さらに、Compose 1.1 では、これまで試験運用版だったたくさんの API が安定版になっているほか、より新しいバージョンの Kotlin もサポートされています。今回の #TheAndroidShow では、アニメーション関係の開発に携わったエンジニア、Doris Liu と一緒に、アニメーションの世界の舞台裏に迫りました。その後、Compose を使って半分の時間で新機能を開発できるようになった Twitter から、その方法について話をうかがいました。
次に紹介したのは、タブレットの世界です。3 月初めには、大ニュースが届きました。12L フィーチャー ドロップが AOSP に正式リリースされ、3 月上旬から数週間のうちに、サポート対象のすべての Pixel デバイスにロールアウトされました。Android の大画面デバイスは、2.5 億台以上存在しています。12L には、アプリをドラッグ&ドロップしてすばやく分割画面モードに切り替えることができる新しいタスクバー、通知シェードとロック画面の新しい大画面レイアウト、アプリの互換性モードの改善などのアップデートが含まれ、タブレットでの Android 12 がさらに改善されています。詳細については、こちら (英語) を参照してください。
12L は、今年中に行われるアップデートによって、Samsung、Lenovo、Microsoft のタブレットや折りたたみ式デバイスで利用できるようになる予定です。そのため、今のうちにアプリの準備を整えておくようにしましょう。さまざまなウィンドウ サイズの分割画面モードや異なる画面の向きでアプリをテストし、該当する場合は新しい互換性モードの変更点を確認することを強くおすすめします。デベロッパー向けの 12L の説明は、こちら (英語) をご覧ください。
私たちは、大画面機能を Android の将来にとって重要な機能と位置付けています。そのため、皆さんがタブレットや Chromebook、折りたたみ式デバイスで優れたエクスペリエンスを構築するために必要になるツールを提供できるように、今後も注力を続けます。詳細については、大画面向けの最適化を始める方法や、大画面デベロッパー リソースをご覧ください。
最後のまとめとして、Android デベロッパー リレーションズのディレクター、Maru Ahues Bouza から話を聞きました。Android 13 のことに加え、今年の Android に関する幅広い話題が登場しました。
すべての内容は、現在配信中の #TheAndroidShow でご覧いただけます。ぜひ YouTube (英語) にアクセスしてください!
この記事は 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
この記事は 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 に入社したい)と思った方は、プロダクトのオーナーや経営者向けに凝縮したケーススタディをご覧ください。こちら(英語)のリンクから参照できます。
この記事は 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 に継続的に関心を寄せていただき、ありがとうございます。皆さんと共同で、ユーザーのためにすばらしいカメラ体験を作成できることが楽しみです。
この記事は 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 ストアの機能は、今後数か月間で徐々にロールアウトされます。変更が行われる前に大画面アプリの品質改善計画を立て、一歩先にスタートすることをおすすめします。今後も、大画面の最適化を最大限にサポートしてユーザー エクスペリエンスを改善できるように、フィードバックを集めて、優れたアプリを開発するデベロッパーの皆さんをサポートし続けたいと考えています。