この記事は 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 を使ってみてください！
この記事は Jeanine Banks による Google Developers Blog の記事 "Helping you build across devices, platforms, and the world" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
嬉しいことに、再び Shoreline Amphitheatre で Google I/O を開催できました。世界中の皆さんとバーチャルで、そして直接お会いできるのは、すばらしいことです。
I/O は、私たちからデベロッパーの皆さんに宛てたラブレターのようなものです。デベロッパーの皆さんは、情報革命を実現する原動力です。それだけでなく、情報やアイデアをコードに変えて、学習、仕事、通信、娯楽などに活用できるようにしています。
数十年前のデジタル エクスペリエンス構築とは、パソコンを使える人々に向けて静的なウェブサイトを公開することでした。それが今では、さまざまなブラウザ、パソコン、スマートフォン、タブレット、バーチャル アシスタント、テレビ、ゲーム機、自動車、スマートウォッチなどで動作する超高速でインタラクティブなエクスペリエンスを指すようになっています。最高水準のプライバシーと安全性を確保しながら、これまで以上に高速な新機能が期待されています。
この複雑さと高まる期待に応えるため、皆さんが直面している課題を簡単に解決できるようにしたいと考えています。今年の I/O では、デベロッパー プロダクトの連携を向上させ、提供するガイドやベスト プラクティスを増やして一連のワークフローを最適化できるように、長期的な取り組みを始めることを発表しました。ここでは、デベロッパー基調講演でお話ししたポイントの一部を紹介します。
Android、ARCore、Chrome OS、Cloud、Flutter、Firebase、Google Play、Kaggle、機械学習、ウェブ プラットフォーム (動画) など、さまざまなプラットフォーム上の今年の新機能の全容を把握したい方は、デベロッパー基調講演か次のハイライト動画をご覧ください。（※上記全て英語）
初めてアプリを作ろうとしている皆さん、製品でできることを増やしたい皆さん、そして責任ある ML を簡単に活用したい皆さん。皆さんの前に広がる広大な領域には、たくさんのインスピレーションがあふれています。ぜひそのアイデアを現実のものにして、人々の生活を向上させましょう。
Google Play では、あらゆる規模のデベロッパーの皆さんが、その可能性を最大限に発揮し、さらなる成長を実現することに注力しています。
そこで、先日、インディー ゲーム デベロッパーの皆さんに向けた 2 つのプログラム (英語) を発表いたしました。
応募は 2022 年 7 月 1 日まで。
新しいゲームの発売が間近、または最近発売したタイトルがあるインディー ゲーム デベロッパーの皆さんのために設計されたプログラムです。
Indie Games Accelerator (英語) は、Google とゲーム業界の専門家とのネットワークを通して、開発、ローンチ、成長の成功を支援するための研修とメンターシップを提供します。
プログラムに選ばれたゲームスタジオは、2022 年 9 月から始まる 10 週間のアクセラレーション プログラムに招待されます。このプログラムは、70 カ国以上の小規模なゲーム開発者を対象とした、カスタマイズされたプログラムです。業界屈指の講師陣が主催するオンラインのマスタークラス、講演、ゲームワークショップなどを予定しています。
また、ゲームを次のレベルへと進化させたい世界中の情熱にあふれたデベロッパーの皆さんと出会い、つながる機会も得られます。
応募は (英語) 2022 年 7 月 1 日まで。
2021 年 7 月 1 日以降に Google Play ストアで公開されているインディー ゲーム を対象に、2022 年もインディー ゲーム フェスティバルを開催します。(オープンベータ版も対象となります)
ファイナリストは、オンライン上で開催されるファイナル イベントで紹介され、世界中のゲーム業界の専門家やプレーヤーにあなたのゲームを発見してもらうことができます。また、Google Play ストアの特設コーナーへの掲載や、Google Pixel 6 Pro などの賞品もご用意しております。
昨年に引き続き「学生部門賞」もご用意しています。（13 歳以上の学生の方が対象です）
皆さんからのご応募お待ちしております。
すべての応募は 2022 年 7 月 1 日 17:00 (日本時間) が締切となります。
なお、本イベントの最新情報、参加規約、ルールについては必ず随時 Web サイトをご確認ください。
Posted by Tamao Imura - Developer Marketing Manager, Google Play
この記事は 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 (英語) にアクセスしてください！
サイバーエージェントは、コンバージョン率向上に向け、ユーザー評価の重要性に着目し、『IDOLY PRIDE』に Google Play In-App Review API を実装しました。これによりユーザーがゲームから離脱せず、ゲーム内でレビューが投稿できるようになったため、レビュー投稿へのハードルが軽減されました。また、サイバーエージェントは、よりレビューの数を増やすために、満足度が高いタイミング (最高レア確定補助チケットを初めて利用した直後など) にゲーム内でレビューを促すといった工夫も行っています。
「Google の In-App Review API は、私たちのゲームに対するユーザーからの意見と向き合う機会を与えてくれる便利なツールです。レビューやフィードバックの量が増えることで、ユーザーの好みを知り、よりユーザー満足度の高いゲームにしていく方法の一つとして有用だと思います」
株式会社サイバーエージェント QualiArts マーケティング責任者 木村 泰之 氏
サイバーエージェントは、ゲーム中の特定のタイミングでユーザーにレビューの投稿を促すことにより、ゲーム全体に対するポジティブなレビュー数の増加を達成することができました。また、いつ、どのようなレビューに返信するべきかというルールを設定し、個々のレビューに対して真摯な返信対応をすることで、『IDOLY PRIDE』は、過去 1 年間、アプリ評価を平均 4.0 以上に保ち、Google Play ストアのアプリ詳細ページでの高いコンバージョン率を達成しました。
Google Play In-App Review API の詳細については、こちらをご覧ください。
Written by Toru Shimazaki - Google Play, Partner Development Manager
この記事は 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
この記事は Manuel Vivo による Android Developers - Medium の記事 " Migrating Architecture Blueprints to Jetpack Compose " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリ アーキテクチャ ガイドを最新化する作業の一環として、異なる UI パターンを使って実験し、最適に動作する方式や各方式間の類似点や相違点を確認して、最終的にはそこから得られた教訓をベスト プラクティスとしてまとめたいと考えています。
そこで発見したことをできる限り容易に理解していただくには、おなじみのビジネスケースを扱う複雑すぎないサンプルが必要でした。そう考えると、最適な題材は TODO アプリでしょう。そこで、アーキテクチャ ブループリントを選択しました。これまで、このブループリントは、アーキテクチャを選択する際の実験場として使われてきました。この点でも、まさにうってつけだと言えるでしょう。
実際のアーキテクチャ ブループリント アプリ
今回試したいパターンは、現在利用できるさまざまな API から明らかな影響を受けています。今回の新入りは、Jetpack Compose の State API です。Compose は、どんな単方向データフローともシームレスに連携できるので、UI のレンダリングに Compose を使うことで、公正な比較ができるようにします。
このブログ投稿では、どのようにしてアーキテクチャ ブループリントを Jetpack Compose に移行したかをお伝えします。LiveData もこの実験の代替手段と考えることができるので、このサンプルは移行時の状態のままにしています。今回のリファクタリングでは、ViewModel クラスとデータレイヤーには手を加えませんでした。
⚠️ この LiveData ベースのコードベースで使ったアーキテクチャは、最新のアーキテクチャ ベスト プラクティスに完全に従ってはいません。特に、LiveData はデータレイヤーやドメイン レイヤーで使うべきではありません。代わりにフローやコルーチンを使うようにしてください。
背景が明らかになったので、ブループリントを Jetpack Compose にリファクタリングした手法の説明に入りましょう。完全なコードは、dev-compose ブランチで確認できます。
提案された変更点が全員の共通認識となるように、実際 のコーディング作業を始める前に、移行計画を作成しました。最終的な目的は、ブループリントを単一アクティビティ アプリにすることです。その際に、画面はコンポーズ可能な関数にして、画面間の移動には推奨の Compose Navigation ライブラリを使います。
ありがたいことに、ブループリントはすでに単一アクティビティ アプリになっており、Jetpack Navigation を使ってフラグメントで実装された画面間を移動しています。これを、Navigation の相互運用性ガイドに従いながら、Compose に移行します。このガイドで推奨されているのは、フラグメントベースの Navigation コンポーネントを使うハイブリッド アプリです。そこでフラグメントを使い、ビューベースの画面、Compose の画面、ビューと Compose の両方を使う画面を格納します。残念ながら、同じナビゲーション グラフでフラグメントと Compose の遷移先を混在することはできません。
段階的移行の目的は、コードレビューを簡単にし、移行の全段階でプロダクトが公開できる状態を維持することです。移行計画は、3 つのステップに分かれています。
これで完了です。🧑💻 ここで 2 週間早送り ⏩ します。この段階で、 統計 画面（PR）、 タスクの追加と編集 画面（PR）、 タスク詳細 画面（PR）、そして タスク一覧 画面（PR）の移行と、最終 PR のマージが完了しています。最終 PR は、未使用のビューシステムへの依存関係の削除を含め、ナビゲーションとアクティビティのロジックを Compose に移行したものです。
ブループリントを Compose に段階的に移行する方法
移行を進めるにあたり、Compose に特有ないくつかの動作に対応する必要がありました。その点について説明します。
アプリに Compose を追加すると、Compose UI を確認するテストには Compose テスト API が必要になります。
画面レベルの UI テストでは、launchFragmentInContainer<FragmentType> API の代わりに、テストの文字列リソースを取得できる createAndroidComposeRule<ComponentActivity> API を使いました。このようなテストは、Espresso でも Robolectric でも実行できます。Compose はすでにこの両方をサポートしているので、追加の変更は必要ありません。それを確認してみたい方は、移行前の AddEditTaskFragmentTest と移行後の AddEditTaskScreenTest のコードを比較してみてください。ComponentActivity を使う場合は、androidx.compose.ui:ui-test-manifest アーティファクトへの依存関係を追加する必要がある点に注意しましょう。
エンドツーエンド テストや結合テストには、何の問題もありませんでした。Espresso と Compose の相互運用性のおかげで、Espresso のアサーションでビューをチェックし、Compose API で Compose UI をチェックすることができます。Compose への移行作業中の AppNavigationTest はこちらです。
問題になったのは、ブループリントが ViewModel イベントを扱う方法でした。ブループリントはイベント ラッパー ソリューションを実装しており、それを使って ViewModel から UI に コマンド を送信していました。しかし、Compose ではこの仕組みは動作しません。最新のガイドでは、このような「イベント」を状態としてモデリングすることが推奨されています。そこで、移行の際に実施しました。
例として、 画面にメッセージを表示する というイベントのユースケースを取り上げます。ここでは、LiveData の Event<Int> 型を Int? に置き換えました。これは、ユーザーに表示するメッセージがない場合をモデリングすることにもなります。この特定のユースケースの ViewModel では、メッセージが表示される場合、必ず UI での確認操作も必要になります。次のコードは、両方の実装の差分です。
/* Copyright 2022 Google LLC. SPDX-License-Identifier: Apache-2.0 */class AddEditTaskViewModel( private val tasksRepository: TasksRepository) : ViewModel() {- private val _snackbarText = MutableLiveData<Event<Int>>()- val snackbarText: LiveData<Event<Int>> = _snackbarText+ private val _snackbarText = MutableLiveData<Int?>()+ val snackbarText: LiveData<Int?> = _snackbarText+ fun snackbarMessageShown() {+ _snackbarText.value = null+ }}
SPDX-License-Identifier: Apache-2.0 */
class AddEditTaskViewModel(
private val tasksRepository: TasksRepository
) : ViewModel() {
- private val _snackbarText = MutableLiveData<Event<Int>>()
- val snackbarText: LiveData<Event<Int>> = _snackbarText
+ private val _snackbarText = MutableLiveData<Int?>()
+ val snackbarText: LiveData<Int?> = _snackbarText
+ fun snackbarMessageShown() {
+ _snackbarText.value = null
+ }}
UI のコードでイベントが一度だけ処理されることを保証するには、event.getContentIfNotHandled() を呼び出します。このアプローチは、フラグメントでは うまくいきそう ですが、Compose では動作しません。Compose では、再コンポーズがいつ起きるかわからないので、イベント ラッパーは有効なソリューションではありません。イベントが処理されて関数が再コンポーズされると（このアプローチをテストする際に、よく起きる現象です）、スナックバーがキャンセルされるので、ユーザーはメッセージを見逃してしまうかもしれません。これは許容できない UX の問題です。Compose アプリでは、イベント ラッパー ソリューションを使うべきではありません。
次の 変更前 （イベント ラッパー）と 変更後 （状態としてのイベント）のコード スニペットをご覧ください。画面にメッセージを表示するのは UI ロジック であることと、この画面コンポーザブルが複雑になってきたことから、単純な状態ホルダークラスを使ってその複雑さに対処することにしました。その例として、次の AddEditTaskState をご覧ください。
Copyright 2022 Google LLC. SPDX-License-Identifier: Apache-2.0 */// FRAGMENTS CODE CONSUMING THE EVENT WRAPPER SOLUTION- class AddEditTaskFragment : Fragment() {- override fun onViewCreated(view: View, savedInstanceState: Bundle?) {- …- viewModel.snackbarText.observe(- lifecycleOwner,- Observer { event ->- event.getContentIfNotHandled()?.let {- showSnackbar(context.getString(it), Snackbar.LENGTH_SHORT)- }- }- )- }- } // COMPOSE CODE CONSUMING USER MESSAGES AS STATE// State holder for the AddEditTask composable.// This class handles AddEditTask's UI elements' state and UI logic.+ class AddEditTaskState(...) {+ init {+ // Listen for snackbar messages+ viewModel.snackbarText.observe(viewLifecycleOwner) { snackbarMessage ->+ if (snackbarMessage != null) {+ // If there's a previous message showing on the screen+ // stop showing it in favor of the new one to be displayed+ currentSnackbarJob?.cancel()+ val snackbarText = context.getString(snackbarMessage)+ currentSnackbarJob = coroutineScope.launch {+ scaffoldState.snackbarHostState.showSnackbar(snackbarText)+ viewModel.snackbarMessageShown()+ }+ }+ }+ }
// FRAGMENTS CODE CONSUMING THE EVENT WRAPPER SOLUTION
- class AddEditTaskFragment : Fragment() {
- override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
- …
- viewModel.snackbarText.observe(
- lifecycleOwner,
- Observer { event ->
- event.getContentIfNotHandled()?.let {
- showSnackbar(context.getString(it), Snackbar.LENGTH_SHORT)
- }
- )
// COMPOSE CODE CONSUMING USER MESSAGES AS STATE
// State holder for the AddEditTask composable.
// This class handles AddEditTask's UI elements' state and UI logic.
+ class AddEditTaskState(...) {
+ init {
+ // Listen for snackbar messages
+ viewModel.snackbarText.observe(viewLifecycleOwner) { snackbarMessage ->
+ if (snackbarMessage != null) {
+ // If there's a previous message showing on the screen
+ // stop showing it in favor of the new one to be displayed
+ currentSnackbarJob?.cancel()
+ val snackbarText = context.getString(snackbarMessage)
+ currentSnackbarJob = coroutineScope.launch {
+ scaffoldState.snackbarHostState.showSnackbar(snackbarText)
+ viewModel.snackbarMessageShown()
+ }
リファクタリングをしていると、そこにあるものを すべて Compose に移行したくなってしまうかもしれません。それでもまったく問題はありませんが、アプリのユーザー エクスペリエンスや「正しさ」を犠牲にすべきではありません。段階的に移行する重要な理由は、アプリを公開できる状態を保ち続けることにあります。
私たちのチームでそれが起きたのは、一部の画面を Compose に移行しているときです。同時にたくさんの移行をしたくはなかったので、一部の画面を Compose に移行 してから 、イベント ラッパーを移行しました。Compose でイベント ラッパーを扱って最善でないエクスペリエンスを提供することは避け、他の画面のコードを Compose に移した後も、このメッセージはフラグメントで処理し続けました。例として、移行中の TasksFragment の状態をご覧ください。
すべてが想定どおり順調に進んだわけではありません。🫤 フラグメントの内容を Compose に変換するのは簡単でしたが、ナビゲーション フラグメントを Navigation Compose に移行する作業には、多少の時間と検討が必要でした。
今後の Compose への移行を簡単にするさまざまな側面について、ガイドの拡張や改善が必要となります。今回の作業をきっかけに議論が始まったので、近日中に新しいガイドができることを期待しています！🎊
私はナビゲーションについてあまり詳しくない ✋ 状態で Navigation Compose への移行を担当しましたが、次のような問題点に直面することになりました。
ナビゲーション フラグメントから Navigation Compose への移行は楽しい作業でした。おかしなことに、プロジェクトの移行自体よりも、ピアレビューの待ち時間の方が長くなりました。移行計画を作成したことと、全員の共通認識を合わせたことで、早い段階で期待する内容を定め、長いレビューが待っていることを知らせることもできました。
今回紹介した Compose への移行の手法が皆さんの役に立つことを期待しています。また、アーキテクチャ ブループリントで今後行う予定の実験や改善についても、さらにお伝えしたいと思っていますので、ご期待ください。
Compose コードを含むブループリントを見てみたい方は、dev-compose ブランチをご覧ください。また、段階的移行の PR を順番に確認したい方のために、一覧を記載します。
👋
2022 年 6 月 15 日 (水) 、16 日 (木) の 2 日間に渡って「Android Roadshow」を開催いたします。
Android 開発者の皆様に楽しんでいただけるよう Day 1、Day 2 でそれぞれ異なる内容をご用意しております。
参加人数に制限を設けておりませんので、お誘い合わせの上ご参加ください。
2022 年 6 月 15 日 (水) 10:00 - 12:00
参加登録はこちら
Day 1 では、5 月 11 日 - 12 日に開催した Google I/O 2022 の発表内容から、アプリ開発の技術戦略を各社でご検討される上で今後重要になってくる話題について、日本語字幕つき英語動画と、日本側の関係者による対談を通じてご紹介いたします。
今年の Google I/O の発表のうち、Android アプリ開発者に特にご注目いただきたいのは「Jetpack Compose」「大画面対応」「Android 13」「Wear OS」の 4 つの話題です。
今回のイベントの内容はどちらかというとゲームではないアプリの開発者向けの構成となっておりますが、大画面対応や Android 13 の話題は今後ゲームにも関連が深く、また開発現場での対応ノウハウなど業種が違ってもお役立ていただけそうな情報もあるかと思いますので、ゲームアプリの開発会社様もご興味のある箇所についてご視聴いただけますと幸いです。
2022 年 6 月 16 日 (木) 16:00 - 17:30
本イベントでは 2022 年 3 月 15 日（日本時間 3 月 16 日）に開催したゲームデベロッパー様向けイベント 「Google for Games Developer Summit 2022 」の発表内容から、ゲーム開発の技術戦略を各社でご検討される上で、特に重要になってくる話題について、日本語字幕付き英語動画と、日本側の関係者による対談を通じてご紹介いたします。
今回の発表のうち、Android アプリ開発者に特にご注目いただきたいのは「エコシステム関連のアップデート」「多画面対応のゲーム」「高品質の Android ゲーム開発」「成長支援ツール」の 4 つの話題です。
ぜひこの機会に最新動向を把握しましょう。たくさんの方に楽しんでご覧いただけるよう準備をしておりますので、皆さまお誘い合わせの上、ご参加ください。
Written 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 が構成証明鍵とそれをリクエストした特定のデバイスを結びつけることはできません。
エンドユーザーは、この変更に気づくことはないでしょう。構成証明を利用しているデベロッパーは、以下の変更点に注意してください。
.jpg)
.jpg)
.png)
.png.jpeg)
.png)
