この記事は Jolanda Verhoef , Anna-Chiara Bellini による Android Developers Blog の記事 " What's new in Jetpack Compose " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Jetpack Compose 1.0 がリリースされてからほぼ 1 年が経過し、その間にコミュニティによる積極的な採用が進んでいます。簡潔な Kotlin の構文と、UI についてすばやく簡単に検討できる宣言型アプローチは高く評価されています。
多くの企業が Compose を大々的に採用し、アプリの新機能や目玉機能を開発しています。たとえば、私たちはかなり早い段階から Compose の実験を始めていた Google Play ストアチームと密接に連携し、Compose を使うと開発が楽しくなるだけでなく、デベロッパーの生産性も上がることを発見しました。チームのメンバーはこのように話しています。「Play ストアのすべての新機能は、このフレームワークを使って構築しています。Compose は、アプリの開発速度向上やスムーズな導入に役立っています」。また、Twitter のチームも、アプリのさまざまな部分で Jetpack Compose を使っており、その成果について、「Compose を使うと、独自のコンポーネントをとてもに簡単に定義でき、API コントラクトの明示性、柔軟性、直感性が向上します」と述べています。Airbnb (英語) チームも Compose を採用し、「Jetpack Compose は技術戦略上欠かすことのできない部分です。これによって向上する生産性は計り知れません」と語っています。
うれしいことに、こういったチームが大規模で複雑な本番環境で慎重に Compose を評価した結果、UI 開発が楽しくわかりやすいものになっただけでなく、さまざまなエンジニアリング上のメリットを得ることもできました。そして、それは一例に過ぎません。なぜなら、Play ストアのトップ 1,000 アプリのうち 100 以上がすでに Compose を使っているからです。
このような緊密な共同作業や、幅広い Android コミュニティからのフィードバックに慎重に耳を傾けることは、常に私たちの開発プロセスの中核であり、ロードマップの実現に向けた鍵でもあります。現在は、新しい API や機能の改善、Compose での開発を今まで以上に簡単にする新ツールを通して、さらに高度なユースケースをサポートする作業を重点的に進めています。Compose が UI の構築方法を根本的に変革するものであることはわかっています。すばらしい見栄えの高性能なアプリを作成するには、考え方の転換が必要です。そのためのサポートとして、ガイド、高度なトピックに関するセッションや Codelab、詳細な解説動画をさらに公開します。以下は、新機能の紹介です。
2022 年 5 月 11 日、たくさんの機能や改善が含まれている Compose 1.2 最初のベータ版をリリースしました。
includeFontPadding をカスタマイズ可能なパラメータにすることで、Issue Tracker で特に要望の多かったバグ (英語) に対応しました。この値は、false に設定することをお勧めします。それにより、レイアウト内のテキストの配置をより厳密に調整できるようになります。今後のリリースでは、これをデフォルト値にすることを検討しています。値を false に設定するとアプリで問題が起きる場合は、前述の Issue でぜひお知らせください。また、includeFontPadding を false に設定した場合、lineHeightStyle パラメータを設定して Text コンポーザブルの行の高さを適合させることができます。これを組み合わせると、次のようになります。
includeFontPadding
false
lineHeightStyle
Text( text = myText, style = TextStyle( lineHeight = 2.5.em, platformStyle = PlatformTextStyle( includeFontPadding = false ), lineHeightStyle = LineHeightStyle( alignment = Alignment.Center, trim = Trim.None ) ))
Text(
text = myText,
style = TextStyle(
lineHeight = 2.5.em,
platformStyle = PlatformTextStyle(
includeFontPadding = false
),
lineHeightStyle = LineHeightStyle(
alignment = Alignment.Center,
trim = Trim.None
)
Compose 1.2 では、Compose にダウンロード可能なフォントが導入されます。複雑な設定を行わずに、Compose の新しい API を使って Google Fonts に非同期的にアクセスしたり、フォールバック フォントを定義したりできます。ダウンロード可能なフォントを使うと、プロバイダを通して複数のアプリで同じフォントを共有できるので、APK のサイズを小さく保ち、ユーザーのシステムの健全性を向上させることができます。
Android のテキストは、テキストを選択しやすくする拡大鏡ウィジェットを提供しています。今回、Compose がテキスト拡大鏡をサポートします。
選択ハンドルをドラッグすると、拡大鏡が表示されて指の下にあるものが見やすくなります。Compose 1.1.0 では、テキスト フィールドで選択をする際の拡大鏡が導入されました。今回の Compose 1.2.0 では、テキスト フィールドと SelectionContainer (英語) の両方で拡大鏡がサポートされます。この拡大鏡は、ビューの Android 拡大鏡の動作とも完全に一致するように拡張されています。
SelectionContainer
Lazy レイアウトがさらに進化します。グリッド API の LazyVerticalGrid (英語) と LazyHorizontalGrid (英語) が試験運用版を終了して正式版になり、独自のカスタム Lazy レイアウトを実装できる LazyLayout (英語) という試験運用版 API が新たに追加されます。これらの API の詳細については、I/O セッション動画 Compose の Lazy レイアウト (英語) をご覧ください。
LazyVerticalGrid
LazyHorizontalGrid
ビューシステムからスクロール可能なコンポーザブルを CoordinatorLayout に埋め込む際に、スクロール動作の相互運用性を確保できるようになります。これにより、折りたたみ可能なツールバーをはるかに簡単に設定できるようになります。この動作は、試験運用版の新しい rememberNestedScrollInteropConnection メソッドを呼び出した結果を nestedScroll 修飾子に渡すことでオプトインできます。この新機能のデモは、こちらのサンプルでご確認ください。
CoordinatorLayout
rememberNestedScrollInteropConnection
nestedScroll
Accompanist の insets ライブラリ (英語) が正式版として Compose Foundation ライブラリに追加され、WindowInsets (英語) クラスから利用できるようになりました。詳しくは、既存の UI に Compose を組み込む方法を説明したドキュメントをご覧ください。
WindowInsets
サイズ変更可能なレイアウトの設計、開発、テストを容易にするため、綿密に検討されたビューポートの一連のブレークポイントであるウィンドウ サイズ クラスをリリースしました。これはマテリアル 3 ライブラリ セットの一部で、現在、新しいライブラリ material3-window-size-class でアルファ版を利用できます。サイズクラスの詳細については、異なる画面サイズをサポートするためのドキュメントで参照できるほか、Crane でサンプル実装を確認することもできます。
material3-window-size-class
アプリのパフォーマンスの理解と改善に役立てていただけるよう、新しいパフォーマンス関連のツールやガイドにいっそう注力しています。この対応により、アプリが遅くなっている理由や場所を、はるかに簡単に理解できるようになります。
Android Studio Dolphin より、Layout Inspector でコンポーザブルの再コンポーズ発生頻度を確認できるようになります。再コンポーズの回数が異常に多い場合は、そのコンポーザブルを最適化する余地があることを示している可能性があります。さらに、Android Studio Electric Eel には再コンポーズのハイライト表示機能が追加され、どのコンポーザブルでいつ再コンポーズが発生したかを視覚的に確認できるようになっています。これらの新ツールについては、Android Studio の新機能ブログをご覧ください。
Compose は、根本的なレベルで UI の記述方法を変革します。そのため、アプリのパフォーマンス向上に役立ついくつかのベスト プラクティスがあります。新たに公開されたドキュメント ページには、最高のパフォーマンスを実現するための Compose アプリの記述方法や設定方法を掲載しています。I/O セッション動画 Jetpack Compose の一般的なパフォーマンスの落とし穴 (英語) では、Compose チームがパフォーマンス関連のよくある失敗例とその修正方法について説明します。
パフォーマンスは、私たちが引き続き重点を置いている領域です。現在、ツールやガイドの改善や追加に懸命に取り組んでいます。それと合わせて、これまでの作業に対するフィードバックもお待ちしています。Issue Tracker (英語) でバグを報告するか、KotlinLang Slack グループ (英語) で質問してください。
これまでの改善をベースに、Compose の効率アップを図る新ツールの最新情報をお知らせします。現在ベータ版の Android Studio Dolphin (英語) では、Compose 開発にすばらしい機能が追加されます。再コンポーズの回数に加え、すべてのアニメーションを一度に確認できる Animation Coordination や、複数の画面サイズに対応する開発に役立つ MultiPreview アノテーションなどの新ツールが導入されます。また、反復処理を高速化できるように、Android Studio Electric Eel Canary に LiveEdit を追加します。
完全な情報は、Android 開発ツールの新機能 (英語) に掲載されています。また、Compose に必要なツールのサポートを実現するため、ぜひフィードバックを共有してください。
もし Compose よりも優れたものがあるとすれば、それはもう 1 つの Compose です。Compose for Wear OS がベータ版になりました。Compose for Wear OS は、他の Jetpack ライブラリと同じ考え方に従っており、ベータ版になったことは、機能が完成して API が安定版になったことを意味します。そのため、本番環境に対応できるアプリの開発を始めることができます。さっそくブログ記事 (英語) を読んで、開発にとりかかりましょう!
Compose に関するたくさんのガイドを追加、刷新しました。
これらの新機能を私たちと同じ用に皆さんにも気に入ってもらえることを願っています。まだ Jetpack Compose を使ったことがない方は、速度やデベロッパーの生産性向上によるあらゆるメリットを享受できるように、チームや開発プロセスでどのように利用できるかをこのタイミングで学びましょう。ぜひ Compose を使ってみてください!
この記事は 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 のグループ会社による商標です。
ゲームのタイトルは、地域によって異なる場合があります。