この記事は Jamal Eason による Android Developers Blog の記事 "Android Studio 4.2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリのプロジェクトを最新版にアップグレードする作業は時に複雑になる場合があります。その問題に対処するため、Android Studio 4.2 に新しいアプリ プロジェクト アップグレード アシスタントを搭載しました。これにより、プロジェクトの移行が簡単になるとともに、最新の Android Gradle プラグインの API を活用できるようになります。さらに、Database Inspector、System Trace、Safe Args のサポート、Apply Changes、新規プロジェクト ウィザードといった既存機能にも、幅広く機能強化を行っています。これらの機能を使っている方や、Android Studio の次の安定版を探している方は、すぐに Android Studio 4.2 をダウンロードしてみてください！
Android Studio 4.2 の新機能の詳細については、重要なデベロッパー フローごとに分類された以下のリストをご覧ください。
./sdk/cmdline-tools/latest/bin/retrace
// build.gradle.kts android { ... signingConfigs { config { ... enableV3Signing(true) enableV4Signing(true) } } }
Android Studio 4.2 に含まれる主な機能拡張と新機能をまとめます。
開発
デバッグ
ビルド
テスト
複数のデバイスへのデプロイ
プロファイル
詳しい情報は、Android Studio のリリースノート、Android Gradle プラグインのリリースノート、Android Emulator のリリースノートをご覧ください。
最新バージョンの Android Studio 4.2 は ダウンロード ページからダウンロードしてください。以前のバージョンをお使いの方は、Android Studio 4.2 にアップデートしてください。Android Studio の安定バージョンを保持する必要がある場合、Android Studio Arctic Fox の安定リリース バージョンと、canary リリース バージョンを同時に実行することができます。詳細はこちらをご覧ください。
デベロッパーの皆さんからのフィードバックをお待ちしています。Android Studio 4.2 で気に入った機能や問題点や、新機能の提案をフィードバックでお寄せください。また、バグや問題を見つけた方は、こちらから問題をご連絡ください。Android Studio 開発チームからの最新情報は、Twitter と Medium でご覧ください。
Java は Oracle および/またはその関連会社の登録商標です。
この記事は Dave Burke による Android Developers Blog の記事 "Android 12 Developer Preview 3" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android 12 では、プライバシーとセキュリティを中核に据え、OS をよりスマートにし、使いやすさとパフォーマンスを向上させることに特化しています。また、ユーザーがスマートフォン、ノートパソコン、タブレット、TV、自動車のユーザーにすばらしい体験を提供できるように、新しいツールの開発も進めています。今回のリリースで注目すべき点は、新しいアプリ起動エクスペリエンス、下層ハードウェアのサポートを最大限に引き出す動画やカメラの新機能、電池を節約するために新しく導入された、正確なアラームのパーミッションなどです。
詳しい内容や Pixel へのダウンロード方法については、このブログ記事を読み進めるか、Android 12 デベロッパー Web サイトにアクセスしてください。既にデベロッパー プレビュー 2 のビルドを実行している方には、まもなく無線（OTA）アップデートが届きます。いつものように、ぜひフィードバックをお寄せください。
デベロッパー プレビュー 3 には、洗練されたエクスペリエンスと高いパフォーマンスを提供するために役立つ新しいツールが含まれています。主なアップデートは以下のとおりです。
アプリ起動エクスペリエンスの改善 - Android 12 では、アプリを起動するときの一貫性と楽しさが向上します。すべてのアプリに、新しいアプリ起動アニメーションとアプリアイコンを表示するスプラッシュ画面が追加され、その後にアプリ自体に遷移するようになります。この新しいエクスペリエンスでは、すべてのアプリが起動する際に共通のデザイン要素が導入されますが、アプリで独自のブランディングを継続できるように、カスタマイズも可能になっています。たとえば、新しいスプラッシュ画面 API や、スプラッシュ画面のウィンドウの背景色を管理するリソースを利用できます。静的なランチャー アイコンをカスタム アイコンやアニメーションで置き換えたり、ライトモードやダークモードを設定したり、終了アニメーションでアプリが登場するタイミングをコントロールしたりすることもできます。
デフォルトですべてのアプリで有効になりますので、新しいエクスペリエンスを活用するために必要なことは何もありません。できるだけ早いうちに、皆さんのアプリで新しいエクスペリエンスをテストすることをお勧めします。特に、既にスプラッシュ画面を使っている方は、忘れずにテストしてください。エクスペリエンスをカスタマイズしたい方は、新しい API を確認してフィードバックをお知らせください。詳しくはこちらをご覧ください。
新しい通話通知テンプレート - ユーザーにとって通話の着信と発信は重要で、簡単に確認および管理できる必要があります。Android 12 では、通話通知の視認性を高め、調べやすくし、他の通知コンポーネントとの整合性を向上させるための改善を行っています。電話アプリやビデオ通話に対応したチャットアプリなど、通話を扱うアプリでは、新しい CallStyle テンプレートを試すことができます。このテンプレートを使うと、着信、発信、スクリーニングされた通話の通知を作成できます。種類ごとに、デフォルトのアクションや、アプリに固有のカスタムのアクションなど、複数のアクションがサポートされています。また、大きなアバター イメージを添付したり、テキストを表示したり、ボタンの色のヒントを設定することもできます。通知シェードの一番上に表示するなど、OS は CallStyle 通知を目立つように表示します。詳しくはこちらをご覧ください。
CallStyle
正確なアラームのための新しいパーミッション - アラームは、アプリが作業をスケジューリングする際の重要な方法の 1 つです。ほとんどのアプリでは、正確でないアラームを使う必要があります。これにより、バッテリーに負荷をかけない処理が可能です。Android は Doze やアプリ スタンバイなどによってこのようなアラームを管理し、復帰の回数とバッテリーへの影響を最低限にとどめています。アラーム時計やタイマーなど、正確なタイミングが必要なアラームでは、正確なアラームを使うことができます。これは便利で信頼性が高いものですが、多用するとバッテリーの残量が急激に減る可能性もあります。そこで Android 12 では、ユーザーがさらに細かく制御できるように、いくつかの変更を加えています。
ターゲットが Android 12 で正確なアラームを使用するアプリは、新しいパーミッション SCHEDULE_EXACT_ALARM をリクエストする必要があります。これは通常のパーミッションなので、マニフェストで宣言すれば初回起動時に自動的に付与されます。ただし、ユーザーがこのパーミッションを持つアプリを確認したり、[Settings] の [Special App Access Permissions] からパーミッションの付与と取り消しを行ったりできるようになります。アプリで正確なアラームが必要な場合は、パーミッションがなくなった場合の処理を忘れないようにしてください。アプリのパーミッションの状態を確認できるようにするため、新しい API canScheduleExactAlarms() を追加しています。一般的には、可能な限り正確なアラームを使わないようにアプリを移行することをお勧めします。詳しくはこちらをご覧ください。
SCHEDULE_EXACT_ALARM
canScheduleExactAlarms()
ウェブリンクの改善 - Android 12 では、ユーザーがコンテンツを高速かつシームレスに取得できるようにするための変更を行っています。まず、Android アプリリンクを通して検証されないリンクや、ユーザーが手動で承認したリンクのデフォルトの処理を変更しました。新しい動作では、OS は選択ダイアログを表示せず、デフォルトのブラウザで直接リンクを開きます。また、リンクを使うアプリをユーザーが簡単に承認できるようにするため、[Settings] の [Open by default] を表示する新しい Intent を追加しました。自分のドメインのリンクを自分のアプリだけが処理できるようにしたい場合は、アプリリンクを利用できます。リンクの設定とテストに役立つ新しい adb コマンドも追加しています。詳しくはこちらをご覧ください。
adb
高度な触覚フィードバック - UI イベントに対する効果的な触覚フィードバック、ゲーム向けの迫力ある楽しい効果、生産性を高めるために注意を促す触覚フィードバックを作成するために提供しているツールを拡張し、低周波数の連続効果など、最新のアクチュエータの幅広い周波数帯域のメリットを活用した表現力の高い効果を追加しました。
ゲーム デベロッパーは、ゲーム用コントローラで種類の異なる複数のアクチュエータに個別にアクセスして同じ効果を同期的に生成したり、複数のアクチュエータ上で異なる触覚効果を生成したりできるようになります。デベロッパーの皆さんには、高度な触覚効果の構成要素として、定数とプリミティブを使うことをお勧めします。また、UI イベントを拡張する定数や、プリミティブを並べて複雑な効果を実現する触覚コンポーザも利用できます。
すべての API は、現在の Pixel 4 デバイスでテストすることができます。また、Android エコシステム全体のユーザーに最新の触覚サポートを提供するため、デバイス メーカーのパートナーとも連携を続けています。
動画エンコードの改善 - Android 12 では、動画の量子化パラメータ（QP）の範囲をコントロールする一連のキーを標準化します。これにより、デベロッパーはベンダー固有のコードを避けることができます。
この新しいキーは、MediaFormat API と NDK Media ライブラリで利用できます。動画が複雑な場合に、ユーザーが目にする動画の画質が極端に落ちないようにするため、動画エンコーダは、動画の最低画質しきい値を指定する必要があります。
Camera2 のベンダー拡張機能 - 多くのデバイス メーカーは、カメラに、ぼけ、HDR、ナイトモードなどのカスタム効果を組み込んでいます。そして、デバイスのエクスペリエンスを差別化できるように、その効果をアプリで使ってほしいと考えています。
このようなカスタム効果は、CameraX ライブラリのベンダー拡張機能を通して既にサポートされていますが、Android 12 では、このベンダー拡張機能をプラットフォームにも直接公開します。これにより、複雑な Camera2 の実装を伴うアプリは、以前のコードを大幅に変更しなくても、拡張機能を簡単に活用できるようになります。
Camera2
拡張機能の API では、CameraX とまったく同じ効果セットを公開しています。これらはさまざまなデバイスで既にサポートされているので、すぐに利用できます。詳しくはこちらをご覧ください。
Quad Bayer カメラセンサーのサポート - 現在の Android デバイスの多くには、Quad / Nona Bayer パターンなどの超高解像度カメラセンサーが搭載されています。これにより、画像の画質と低光量時のパフォーマンスで、高い柔軟性が実現しています。Android 12 では、サードパーティ製のアプリがこの多機能センサーをフル活用できるように、新しいプラットフォーム API を導入します。
新しい API は、こういったセンサー独自の動作をサポートし、フル解像度の「最大解像度」モードで動作している場合と「デフォルト」モードで動作している場合で、異なるストリームの構成と組み合わせをサポートすることも考慮します。
機械学習の高速化 - Android 12 では主要領域に注力し、デベロッパーが Neural Networks API を通して ML アクセラレータを限界まで活用し、常に最大限のパフォーマンスを発揮できるようにしています。パフォーマンスの改善に関しては、パディング、同期フェンス、再利用可能な実行オブジェクトなどの改善を導入することで、推論呼び出しのオーバーヘッドを半分以下にしました。
さらに、プラットフォームのリリースによらず、Google Play 開発者サービスを通して ML アクセラレータのドライバを更新できるようにしました。これにより、すべての対応デバイスで最新のドライバを簡単に活用できるようになるので、ML パフォーマンスの改善やバグの修正をこれまで以上に迅速にユーザーに届けることができます。
GPU 計算の標準化 - Vulkan や OpenGL などのクロスプラットフォームな GPU 計算ソリューションを優先し、RenderScript API を非推奨とします。これは、GPU ハードウェアで高パフォーマンスなワークロードを確実に実行できるようにするための対応です。既に RenderScript のみを CPU サポートした状態で出荷されたデバイスも多く存在するので、当面の間は既存の API も動作するようにします。
高度に最適化されたプラットフォーム固有のコードを使う、組み込みぼかし処理など、RenderScript 固有の機能のライブラリは、オープンソース化しました。Vulkan を使ってイメージ処理を実装する際のサンプルと移行ガイドも公開しています。詳しくはこちらをご覧ください。
ネイティブ コードでのクラッシュのデバッグ機能の強化 - NDK 関連のクラッシュのデバッグを行うことが難しい場合があるという声が寄せられています。Android 12 では、アクションにつながる診断を増やすことで、このようなデバッグを簡単に行えるようにします。
プラットフォームでは、Tombstone と呼ばれるクラッシュ ダンプファイルを使ってネイティブ コードでのクラッシュをデバッグしています。このファイルには、ART による巻き戻し、fdsan との統合、GWP-ASan、HWASan、MTE のクラッシュに関するすべてのスタックの記録など、さまざまな問題の診断に必要な情報が含まれています。今回は、App Exit Reasons API を通して、アプリからこの Tombstone ファイルにアクセスできるようになります。アプリで `ApplicationExitInfo` と `REASON_CRASH_NATIVE` を利用し、`getTraceInputStream()` を呼び出すと、Tombstone データをプロトコル バッファとして取得できます。
バックアップ構成の柔軟性向上 - Android のバックアップ サービスを使うと、ユーザーは新しいデバイスに簡単にデータを復元または移行できます。この操作の中心となるのはアプリで、ユーザーは簡単にアプリデータを転送したり、中断したところから継続したりできます。バックアップ サービスは、Google ドライブへのクラウド バックアップと、デバイス間の転送の両方をサポートします。また、デベロッパーは最小限のアプリの変更だけでこの機能を活用できます。
今回、このサービスを改善し、Android 12 をターゲットとしたアプリの柔軟性とコントロールを向上させます。クラウド バックアップとデバイス間の転送で異なるルールを設定できるように、XML 構成フォーマットを更新しました。これにより、たとえばクラウド バックアップからは巨大なファイルを除外し、デバイス間の転送には含める、といったことが可能になります。バックアップと転送で暗号化要件を別々に設定することもできます。なお、デバイス間の転送で自動バックアップをオプトアウトしたい場合は、allowBackup マニフェスト属性ではなく、新しい構成フォーマットを使用してください。詳しくはこちらをご覧ください。
allowBackup
Android 12 の詳しい機能や動作の変更点は、こちらからご覧いただけます。
新しいバージョンのプラットフォームをロールアウトするにあたって、アプリの互換性を優先し、迅速でスムーズにアップデートできるように対応しています。皆さんがアプリの動作確認などになるべく長い時間が取れるよう、Android 12 ではアプリに関連する変更のほとんどがオプトイン方式になっています。また、意図しない動作となる場合でも、短時間で対応できるように、ツールやプロセスをアップデートしています。
デベロッパー プレビュー 3 は最初のベータ版リリースにさらに近づいており、安定性を向上させるための作業が続いています。新機能や変更点を試し、アプリがどのように動作したのか、引き続きフィードバックをお寄せください。
最初のベータ版のリリースが近づいているので、確実にアプリの準備ができるようにこのタイミングで互換性テストを開始し、今後数週間のうちに、互換性のあるアップデートをリリースすることをお勧めします。現時点では、アプリの targetSdkVersion を変更する必要はありませんが、動作の変更点の切り替えを利用できます。Android 12 の変更点をオプトインすることで、アプリがどのような影響を受ける可能性があるかについての予備知識を得ることができます。
2021 年 8 月に Platform Stability に到達すると、アプリに関連するすべてのシステム動作、SDK/NDK API、非 SDK リストが確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリをリリースできます。デベロッパー向けの Android 12 リリース予定についての詳細は、こちらをご覧ください。
デベロッパー プレビュー 3 には、Android 12 に含まれる機能を確認し、アプリの動作をテストするために必要なすべてのものが含まれています。
Pixel 3 / 3 XL、Pixel 3a / 3a XL、Pixel 4 / 4 XL、Pixel 4a / 4a 5G、Pixel 5 デバイスにシステム イメージを書き込むか、Android Emulator を使うと、すぐに利用を開始できます。既に Pixel デバイスにプレビュー ビルドをインストールしている方は、自動的にこのアップデートを受け取ります。今後のベータ版のアップデートも無線（OTA）で提供されます。Android 12 を使う方法の詳細は、こちらをご覧ください。
すべての情報は、Android 12 デベロッパー Web サイトでご覧いただけます。
Reviewed by Yuichi Araki - Developer Relations Team and Tamao Imura - Developer Marketing Manager, Google Play
この記事は Rohit による Android Developers Blog の記事 "Using DataStore With Kotlin Serialization" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
過去公開したブログ記事では、Protos や Preferences で DataStore を使う方法について解説してきました。どちらのバージョンの DataStore も内部的に Protos を使ってデータをシリアル化します。Kotlin のシリアル化を使えば、DataStore とカスタムのデータクラスを併用することもできます。この方法を使うと、データにスキーマを提供しつつ、ボイラープレート コードを減らすことができます。Protobuf ライブラリを学習したり、利用したりする必要はありません。Kotlin のシリアル化を使うには、次の作業が必要です。
Kotlin のデータクラスは Kotlin のシリアル化とシームレスに連携できるので、DataStore との相性は抜群です。データクラスでは equals と hashCode が自動生成され、DataStore はこれを利用します。データのデバッグや更新に便利な toString 関数と copy 関数も生成されます。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */data class UserPreferences( val showCompleted: Boolean, val sortOrder: SortOrder)
SPDX-License-Identifier: Apache-2.0 */
data class UserPreferences(
val showCompleted: Boolean,
val sortOrder: SortOrder
)
DataStore は可変型には対応していないので、クラスを確実に不変にすることがとても重要です。DataStore で可変型を使うと、バグや競合状態を捕捉するのが難しくなります。データクラスは、必ずしも不変である必要はありません。
var は可変なので、代わりに val を利用します。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- var num: Int+ val num: Int)- myObj.num = 5 // Fails to compile when num is val+ val newObj = myObj.copy(num = 5)
data class MyData(
- var num: Int
+ val num: Int
- myObj.num = 5 // Fails to compile when num is val
+ val newObj = myObj.copy(num = 5)
配列は可変なので、公開しないようにします。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- var num: IntArray)- myObj.num = 5 // This would mutate your object
- var num: IntArray
- myObj.num = 5 // This would mutate your object
データクラスのメンバーとして読み取り専用の List を使う場合でも、それが可変であることは変わりません。そうするのではなく、不変/永続コレクションを使うことを検討してください。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- val nums: List<Int>+ val nums: PersistentList<Int>)- val myInts = mutableListOf(1, 2, 3, 4)- val myObj = MyData(myInts)- myInts.add(5) // Fails to compile with PersistentList, but mutates with List+ val newData = myObj.copy(+ nums = myObj.nums.mutate { it += 5 } // Mutate returns a new PersistentList+ )
- val nums: List<Int>
+ val nums: PersistentList<Int>
- val myInts = mutableListOf(1, 2, 3, 4)
- val myObj = MyData(myInts)
- myInts.add(5) // Fails to compile with PersistentList, but mutates with List
+ val newData = myObj.copy(
+ nums = myObj.nums.mutate { it += 5 } // Mutate returns a new PersistentList
+ )
データクラスのメンバーに可変型を使うと、データクラスが可変になります。そうするのではなく、すべてのメンバーを確実に不変型にしてください。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- val mutableType: MutableType)- val myType = MutableType()- val myObj = MyData(myType)- myType.mutate()
- val mutableType: MutableType
- val myType = MutableType()
- val myObj = MyData(myType)
- myType.mutate()
Kotlin のシリアル化は、JSON やプロトコル バッファなどの複数のフォーマットをサポートしています。ここでは JSON を使います。ごく一般的で、使いやすく、クリアテキストで保存できるのでデバッグも簡単です。Protobuf も優れた候補です。小さく高速で protobuf-lite と互換性があるためです。
Kotlin のシリアル化を使って JSON でデータクラスの読み取りや書き込みを行うには、データクラスに @Serializable アノテーションを追加し、Json.decodeFromString<YourType>(string) と Json.encodeToString(data) を使用する必要があります。次に示すのは、UserPreferences による例です。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */@Serializabledata class UserPreferences( val showCompleted: Boolean = false, val sortOrder: SortOrder = SortOrder.None)object UserPreferencesSerializer : Serializer<UserPreferences> { override val defaultValue = UserPreferences() override suspend fun readFrom(input: InputStream): UserPreferences { try { return Json.decodeFromString( UserPreferences.serializer(), input.readBytes().decodeToString()) } catch (serialization: SerializationException) { throw CorruptionException("Unable to read UserPrefs", serialization) } } override suspend fun writeTo(t: UserPreferences, output: OutputStream) { output.write(Json.encodeToString(UserPreferences.serializer(), t).encodeToByteArray()) }}
@Serializable
val showCompleted: Boolean = false,
val sortOrder: SortOrder = SortOrder.None
object UserPreferencesSerializer : Serializer<UserPreferences> {
override val defaultValue = UserPreferences()
override suspend fun readFrom(input: InputStream): UserPreferences {
try {
return Json.decodeFromString(
UserPreferences.serializer(), input.readBytes().decodeToString())
} catch (serialization: SerializationException) {
throw CorruptionException("Unable to read UserPrefs", serialization)
}
override suspend fun writeTo(t: UserPreferences, output: OutputStream) {
output.write(Json.encodeToString(UserPreferences.serializer(), t).encodeToByteArray())
⚠️ DataStore で Parcelable を使用するのは Android のバージョンによってデータ形式が変わる可能性があるため安全ではありません。
DataStore を作成する際に、作成したシリアライザを DataStore に渡します。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */val Context.dataStore by dataStore("my_file.json", serializer = UserPreferencesSerializer)
val Context.dataStore by dataStore("my_file.json", serializer = UserPreferencesSerializer)
データの読み取りは、Protos を使う場合と同様です。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */suspend fun getShowCompleted(): Boolean { context.dataStore.data.first().showCompleted}
suspend fun getShowCompleted(): Boolean {
context.dataStore.data.first().showCompleted
データの更新には、生成された .copy() 関数を利用します。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */suspend fun setShowCompleted(newShowCompleted: Boolean) { // This will leave the sortOrder value untouched: context.dataStore.updateData { it.copy(newShowCompleted = showCompleted) }}
suspend fun setShowCompleted(newShowCompleted: Boolean) {
// This will leave the sortOrder value untouched:
context.dataStore.updateData { it.copy(newShowCompleted = showCompleted) }
DataStore、Kotlin のシリアル化、データクラスを併用すると、ボイラープレートを減らしてコードをシンプルにすることができます。ただし、可変性によるバグが紛れ込まないように注意しなければなりません。必要な作業は、データクラスを定義してシリアライザを実装することだけです。ぜひ実際に試してみてください。
DataStore についてさらに知りたい方は、ドキュメントをご覧ください。また、Proto DataStore や Preferences DataStore の Codelab もご確認ください。
Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC
この記事は Caren Chang による Android Developers Blog の記事 "MAD Skills WorkManager : Wrap-Up" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
WorkManager についての MAD Skills ミニシリーズが終わりました。初めてこのライブラリを使う方のために WorkManager を紹介し、WorkManager のコードのテストやデバッグを行う方法など、高度な使い方へと話を進めました。シリーズ最後のエピソードでは、GCMNetworkManager や FirebaseJobDispatcher を使った古いコードの代わりに WorkManager を使う方法を説明しました。
この記事では、紹介した内容について簡単にまとめます。
最初のエピソードでは、WorkManager Codelab を題材に WorkManager の基本について説明しました。まずは、必要な作業を定義する方法と、その作業をスケジュールする方法について学びました。次に、種類の異なる作業（重複しない作業と定期的な作業）を実現する方法に進みました。WorkManager がどのように作業をスケジュールするかについて理解を深めるため、エピソードの最後では App Standby Bucket について説明しました。
初めて WorkManager を使う方には、以下の記事（英語）も確認することをお勧めします。
続いて、WorkManager がマルチスレッドをどう扱うかについて Ben が詳しく説明しました。スレッドを使う場合は、Executor、コルーチン、RxJava のいずれかを使うことができます。Ben は、WorkManager でそれぞれのアプローチを利用する方法についてデモを行いました。エピソードの最後では、作業が完了したときに結果を返し、UI を更新できるようにする方法を紹介しました。
WorkManager とコルーチンを組み合わせて使いたい方には、Florina が公開したこちらのブログ記事（英語）もご覧ください。
エピソード 3 では、WorkManager の初期化をカスタマイズする方法と、複数のプロセスにまたがるアプリをサポートする方法について説明しました。デベロッパーの皆さんから、テストやデバッグに関するたくさんの質問が寄せられたので、Ben はワーカーをテストする方法や役に立つデバッグ テクニックも紹介しました。
最後のエピソードでは、古いジョブ スケジュール ライブラリ（GCMNetworkManager と FirebaseJobDispatcher）から WorkManager に移行する方法を取り上げました。ターゲット API レベルが 30 以上のアプリでは、Android Marshmallow（6.0）以降を実行しているデバイスで GCM NetworkManager と FirebaseJobDispatcher が動作しなくなります。まだどちらかのライブラリを使っている方は、WorkManager を使うようにアプリをアップデートしてください。
Android GDE の Hugo Visser さんが、最近携わった変更管理アプリで WorkManager を使うことにした理由と、開発プロセスでこのライブラリがどう役立ったかについて話してくれました。
シリーズの最後は、私たちが皆さんから寄せられた WorkManager 関連の質問に答えるリアルタイム Q&A セッションを行いました。WorkManager の今後の計画や、重複した作業の扱い、失敗した作業の再試行などの質問に対する回答をご覧ください。
この記事は Chet Haase による Android Developers - Medium の記事 "Now in Android #37"を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は Android 12、MAD Skills WorkManager、AndroidX、最新のポッドキャスト エピソードなどをご紹介します。
今回の Now in Android は、動画とポッドキャストでもお届けします。内容は同じですが、読む量は少なくて済みます。この記事版には、取り上げているすべてのコンテンツへのリンクが掲載されていますので、ぜひご覧ください。
下のリンクをクリックするか、お気に入りのクライアント アプリでポッドキャストをサブスクライブしてください。
Android 12 の 2 回目のデベロッパー プレビュー が公開されています。また、4 月 7 日（日本時間 4 月 8 日）にはパッチ リリース の DP 2.2 を公開しました。
デベロッパー プレビュー 2 でリリースした新機能の概要は、ブログ記事でご紹介しています。ピクチャー イン ピクチャーの改善、ぼかしや色フィルタなどの強力なグラフィック効果を簡単に実現できる新しい RenderEffect API などが含まれています。
また、デベロッパー ドキュメントにもいくつか改善を加えました。
Android 12 プレビュー の Web サイトには、動作の変更点、新機能と新しい API などの情報を掲載しています。新しくリリースしたバージョンでぜひ皆さんのアプリのテストをお願いします。何か問題があればフィードバックをお送りください。デベロッパー プレビューをリリースすることで、皆さんからのフィードバックをより多く集め、最終プロダクトの公開までに完成度を上げていきます。
最終リリースに向けて作業が進むにつれて、機能や修正が増えていきます。今後のリリースにもご期待ください。
最先端の Android 開発に関する技術コンテンツを扱う MAD Skills シリーズが続いています。ミニシリーズとして取り上げてきた WorkManager から今回も最新情報をお知らせします。
Firebase JobDispatcher や GCMNetworkManager API をまだ使っている場合は、どちらも非推奨となってますので、今こそ移行のタイミングです。このエピソードでは、WorkManager を使うようにコードを移行する方法について、Caren Chang が解説しています。動画に加えて、Firebase JobDispatcher と GCMNetworkManager から移行する方法についてのガイドも忘れずにご覧ください。
Hugo Visser さんが、健康管理アプリで WorkManager を使ってスケジュールを設定し、定期的にデータをダウンロードして処理する方法について解説しています。さらに、いくつかのデバイスで問題を発見し、その問題を送信したところ、最新リリースの WorkManager でバグが修正されたことにも触れています。
WorkManager シリーズの最後のエピソードでも、WorkManager のエキスパートを招いてリアルタイム Q&A を行いました。私のほかに、Ben Weiss とこのシリーズの進行役である Caren Chang、そして Sumir Kataria と WorkManager の担当エンジニア Rahul Ravikumar が参加しました。この API について、できる限り多くの質問にお答えしています。
連載中のコンテンツは、YouTube の MAD Skills プレイリスト、Medium の記事、またはすべてのリンクが掲載されているランディング ページからご覧いただけます。
Fragment 1.3.2、Activity 1.2.2、Lifecycle 2.3.1 など、いくつかの AndroidX のバグ修正版を安定版としてリリースしました。最初のアルファ版リリースになったばかりですが、いくつかの新ライブラリも登場しました。
Oboe は、さまざまな Android リリースやデバイスで高パフォーマンス、低レイテンシ（遅延）のオーディオを実現するネイティブ ライブラリです。昨年 4 月には、ADB ポッドキャストで Oboe のエンジニアから話を聞きました。そして現在、Oboe は Games SDK に統合されています。Daniel Galpin が Android Developers ブログに新しい記事（英語）を投稿しました。プロジェクトに Oboe を追加してコードから利用する方法について詳しく説明しています。
Manuel Vivo が、Lifecycle 2.4.0-alpha01 の新しい API を紹介するブログ記事（英語）を公開しました。この API を使うと、UI レイヤーから安全に Kotlin Flow を使用できます。
Nicole Borrelli が、PendingIntent を正しく使う方法と、これを使うべきタイミングについてのブログ記事（英語）を投稿しました。これはタイムリーな話題です。次のリリースで行われるセキュリティ関係の変更により、Android 12 をターゲットとしたアプリで PendingIntent の可変性についての宣言が必須になるからです。
ユニット 4 が始まります。他のコースもご覧ください！
Android 開発の基本と Kotlin プログラミングを学びたい方向けのコース、Android Basics in Kotlin で、ユニット 4: インターネットへの接続が公開されました。この新しいコンテンツでは、Kotlin コルーチンのコードを書きつつ、ネットワーク データを扱う Retrofit や Coil などの重要なライブラリの使い方を学習します。
今まで Blogger で公開していた ADB が終了しました。そして、Android Developers Backstage の新しい Web サイトを公開し、新しいフィード、そして素敵な新しいロゴを作成しました。この変更は現在の ADB サブスクライバには影響しません。フィードはリダイレクトされるので、再度サブスクライブする必要はありません。しかし、今後のエピソードのメモを参照したい場合は、adbackstage.libsyn.com をご確認ください。
新しいサイトとフィードに投稿された最初のエピソードは、長年にわたり独立系の Android アプリ デベロッパーとして活躍している Chris Lacy さんへのインタビューです。Chris さんがアプリをどのように実装したのか、またその過程で Android のプログラミングや API についてどのようなことを学んだのか、Romain と私が話を聞きました。
次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。
この記事は Eric Bahna による Android Developers Blog の記事 "Start Your Engines: Launch New Android Auto Apps to Production!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
本年 3 月、Jetpack の一部として Android for Cars App Library を公開しました。ほとんどのデベロッパーは、既に実装をこのライブラリに移行しています。パートナー デベロッパーの素晴らしいアプリが登場し、ドライバーの満足度も高く、クオリティの高いアプリとなっています。
この度、2021 年 4 月 5 日（日本時間 4 月 6 日）より、Android Auto のナビゲーション、駐車場、充電スポットのアプリを製品版として公開できるようになったことをお知らせします。このマイルストーンに到達するために、Android Auto ライブラリの開発と公開プロセスを安定させる作業を続けてきました。
製品版として公開すると、ドライバーはベータ版プログラムに登録しなくても、Android Auto 対応自動車のスクリーンで Android Auto アプリを利用できるようになります。製品版として公開する方法は以下のとおりです。
Android for Cars App Library 1.0 に関する、デベロッパーの皆さんからのご協力とフィードバックに感謝しております。
Android Auto ユーザーから特に多く寄せられたリクエストは、アプリのカテゴリを増やしてほしいというものでした。このライブラリの目的は、アプリの品質ガイドラインを満たしつつ、アプリを 500 モデル以上の Android Auto 対応自動車へ、簡単に配信できるようにすることです。ライブラリが複雑な画面のフォーム ファクタや入力モードを抽象化してくれるので、デベロッパーのみなさんはアプリの魅力を高める作業に集中して取り組むことが可能になりました。
ナビゲーション、駐車場、充電スポットのアプリを製品版として公開できるようになったことは、大きな一歩であるとともに、さらに長い道のりの始まりでもあります。より多くのデベロッパーのみなさんが開発した自動車用アプリが作成されることをとても期待しています。また、皆さんと協力してすばらしい車内体験を提供することを楽しみにしています。
2018 年より開催している Google Play 主催の Indie Games Festival は、インディー ゲームとそのデベロッパーの革新性や独自性を称えるイベントです。
2021 年に 4 年目を迎える インディー ゲーム フェスティバルの開催が今年も決定しました！募集開始時期や詳細なスケジュールおよびルールは、今後順次お知らせします。
今年は、新しく「学生部門賞」も加わります！（13 歳以上の学生の方が対象です）
ゲーム開発者を目指す学生の皆さんの沢山のご応募をお待ちしています。
どうぞご期待ください。
Tamao Imura - Developer Marketing Manager, Google Play
この記事は Meghan Mehta による Android Developers - Medium の記事 "Working with Package Visibility" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android では、ユーザーのプライバシーとプラットフォームのセキュリティを高め、ユーザーに安全な体験を提供するための変更を行っています。Android 11（API レベル 30）以降をターゲットとしたアプリは、ユーザーがデバイスにインストールしているアプリのうち、フィルタによって絞り込まれた一部のアプリのみしか参照できないようになっています。それ以外のアプリにアクセスしたい場合は、Android マニフェストで<queries> 要素を使い、直接連携するアプリを宣言しなければなりません。このブログ投稿では、この機能に対応する際のベスト プラクティスについて解説します。
アプリに対するクエリや連携を行うには、いくつかの方法があります。
<!-- Copyright 2019 Google LLC. SPDX-License-Identifier: Apache-2.0 --><manifest package="com.example.game"> <queries> <package android:name="com.example.store" /> <package android:name="com.example.services" /> </queries> …</manifest>
SPDX-License-Identifier: Apache-2.0 -->
<manifest package="com.example.game">
<queries>
<package android:name="com.example.store" />
<package android:name="com.example.services" />
</queries>
…
</manifest>
!-- Copyright 2019 Google LLC. SPDX-License-Identifier: Apache-2.0 --><manifest package="com.example.game"> <queries> <intent> <action android:name="android.intent.action.SEND" /> <data android:mimeType="image/jpeg" /> </intent> </queries> ...</manifest>
<intent>
<action android:name="android.intent.action.SEND" />
<data android:mimeType="image/jpeg" />
</intent>
...
<!-- Copyright 2019 Google LLC. SPDX-License-Identifier: Apache-2.0 --><manifest package="com.example.suite.enterprise"> <queries> <provider android:authorities="com.example.settings.files" /> </queries> …</manifest>
<manifest package="com.example.suite.enterprise">
<provider android:authorities="com.example.settings.files" />
連携する場合、必要なパッケージのみに対してクエリを実行し、データを最小限にとどめることを推奨します。 QUERY_ALL_PACKAGES や、同じく広範な <intent> 要素は、そのレベルの情報が必要になるアプリでのみ利用してください。また、新しい Package Visibility ポリシーでは、デバイスにインストールされているアプリの一覧が参照できる QUERY_ALL_PACKAGES パーミッションを新たに使用する場合、承認プロセスを通していただく必要があります。詳しくは、こちらをご覧ください。
ほとんどの一般的なユースケースでは、広範囲にわたってインストールされているアプリの情報を得る必要はありません。多くのシナリオでは、startActivity() で十分目的は果たせます。インテントを実行できるアプリがない場合は、例外をキャッチします。
<!-- Copyright 2019 Google LLC. SPDX-License-Identifier: Apache-2.0 -->try { val intent = Intent(ACTION_VIEW, Uri.parse(url)).apply { addCategory(CATEGORY_BROWSABLE) } startActivity(intent)} catch (e: ActivityNotFoundException) { Snackbar.make(it,"Activity Not Found",Snackbar.LENGTH_LONG).show()}
val intent = Intent(ACTION_VIEW, Uri.parse(url)).apply {
addCategory(CATEGORY_BROWSABLE)
startActivity(intent)
} catch (e: ActivityNotFoundException) {
Snackbar.make(it,"Activity Not Found",Snackbar.LENGTH_LONG).show()
ターゲットが見えなかったとしても、アクティビティを開始できます。ただし、これは暗黙的インテントなので、アクティビティが利用できるかどうかを開始前に問い合わせたり、起動する具体的なアプリを確認したりすることはできません。インテントを実行できなかった場合は、起動時に通知されます。この問題には、フラグを使って対処することができます。
このフラグを使うと、インテントがブラウザ以外の結果として解決できる場合のみ、インテントが起動されます。そのような結果が存在しない場合は、ActivityNotFoundException が投げられ、アプリはカスタムタブで URL を開きます。
<!-- Copyright 2019 Google LLC. SPDX-License-Identifier: Apache-2.0 -->val intent = Intent(ACTION_VIEW, Uri.parse(url)).apply { // The URL should either launch directly in a non-browser app (if it's // the default), or in the disambiguation dialog. addCategory(CATEGORY_BROWSABLE) flags = FLAG_ACTIVITY_NEW_TASK or FLAG_ACTIVITY_REQUIRE_NON_BROWSER}
// The URL should either launch directly in a non-browser app (if it's
// the default), or in the disambiguation dialog.
flags = FLAG_ACTIVITY_NEW_TASK or FLAG_ACTIVITY_REQUIRE_NON_BROWSER
インテントにこのフラグが含まれていると、startActivity() の呼び出しでブラウザアプリが直接起動される、または確認ダイアログ（オプションはブラウザアプリのみ）がユーザーに表示される場合、ActivityNotFoundException が投げられます。フラグの詳細については、ユースケースに基づいてパッケージの公開設定を設定するをご覧ください。
フラグがよく使われる例として、カスタムタブがあげられます。カスタムタブを使うと、ブラウザの見た目をカスタマイズできます。ブラウザ以外のアプリでも、リンクはカスタムタブで正しく開きます。しかし、どのブラウザのカスタムタブを使うかをデベロッパーが選びたいような高度な事例では、フラグが役立ちます。
カスタムの共有シートではなく、システムの共有シートを使うことをお勧めします。システムの共有シートは、アプリが見えなくてもカスタマイズできます。詳しくはこちらのドキュメントをご覧ください。
マニフェストを調べれば、含まれているすべてのクエリを簡単に確認できます。これを行うには、マニフェスト ファイルに移動して [Merged Manifest] を選択します。
パッケージ フィルタリングのログ メッセージを有効にして、デフォルトの Package Visibility がアプリに与える影響を確認することもできます。
<!-- Copyright 2019 Google LLC. SPDX-License-Identifier: Apache-2.0 -->$ adb shell pm log-visibility - enable YOUR_PACKAGE_NAME
$ adb shell pm log-visibility - enable YOUR_PACKAGE_NAME
パッケージの可視性の詳細については、以下の情報をご覧ください。
それでは、コーディングをお楽しみください。
Google Play にとって、ユーザーとデベロッパーの皆さんのプライバシーと安全が、最も重要です。
そのため、大きなポリシーの改定に伴いデベロッパーの皆さんに対応いただくことが必要となる場合に、その情報を広くお伝えするためのウェビナーを開催しています。
次回は、4 月 16 日に 2021 年 3 月末に適用となったポリシー変更の内容を中心にお伝えする「 Google Play デベロッパー ポリシー ウェビナー 2021 年 4 月」の開催を予定しています。本ウェビナーは、Google Play ストアに向けたアプリの開発やパブリッシングを担う企業や個人の皆さまを対象にした、オンライン ウェビナーです。同じ会社・組織から何人でもご参加可能です。皆さまお誘い合わせの上、ご参加ください。
なお、質問はこちらの Google フォームで事前に受け付けております。こちらの動画をウェビナーに参加される前にご視聴いただき、ウェビナーの前に内容に関する質問をフォームから記入ください。ご協力をお願いします。
【開催概要】
イベント名：Google Play デベロッパー ポリシー ウェビナー 2021 年 4 月開催日時：2021 年 4 月 16 日 16 時 00 分 - 16 時 50 分開催形式：オンライン ウェビナー対象：Google Play ストアに向けたアプリの開発やパブリッシングを担う開発者*開始10 分前から入場可能です
【参加方法】
こちらのイベントページよりご登録・ご視聴ください。当日でも参加登録は可能ですが、事前に登録を完了いただくと、スムーズです。なるべく登録をお済ませの上お待ち下さい。
多数のご参加をお待ちしています。
Posted by Konosuke Ogura - Trust & Safety - Play & Android, Global Policy & Operations Lead and Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Manuel Vivo による Android Developers - Medium の記事 "Now in Android #36" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は MAD Skills のミニシリーズ WorkManager、AndroidX、オーディオ、UX、Wear OS タイル、Jetpack Compose、コルーチン、#AndroidDevChallenge、最新のポッドキャスト エピソードなどをご紹介します。
今回の Now in Android は、動画とポッドキャストでもお届けします。内容は同じですが、読む量は少なくて済みます。この記事版（そのままお読みください！）には、取り上げているすべてのコンテンツへのリンクが掲載されていますので、ぜひご覧ください。
最先端の Android 開発に関する技術コンテンツを扱う MAD Skills シリーズが続いています。
WorkManager についてのミニシリーズには、2 つのエピソードが追加されました。
バックグラウンド処理: Android アプリでやってはいけないことがあるとすれば、それは UI スレッドのブロックです。このエピソードでは、Ben Weiss が WorkManager を使ってバックグラウンド処理を行う方法について、さまざまなアプローチを取り上げています。
WorkManager では、Executor、コルーチン、RxJava のどれを使うかによって、利用する API が違います。このエピソードでは、作業が完了したときに結果を返す方法についても説明しています。さらに Ben は、これまでの MAD 動画の中で最高級の “Let’s go” を披露しています。
高度な設定とテスト: さらに Ben は、WorkManager の初期化をカスタマイズする方法、複数のプロセスにまたがるアプリをサポートする方法、Worker をテストする方法について解説し、便利なデバッグ テクニックもご紹介しています。
今回の、 AndroidX リリースは、ほとんどがバグの修正です。
ご存知の通り、私は Hilt を担当しています。今回は広く、Hilt のベータ版をリリースしたことをお伝えしたいと思います！ViewModel、WorkManager、Navigation をサポートする Hilt の API と AndroidX 固有の API は、すべて安定版です。Hilt は Android で依存関係の注入を行う際の Jetpack の推奨ソリューションです。今回は、クイック リファレンスを公開しました。Hilt と Dagger のさまざまなアノテーションが行う処理の内容と、それを使う方法をすばやく調べることができます。
また、Jetpack Compose や Navigation コンポーネントを使い始めた方のために、hilt-navigation-compose ライブラリを新しくリリースしています。これを使うと、Navigation Compose で作成したナビゲーション グラフの遷移先がスコープになった ViewModel が Hilt から提供され、それを取得できます。詳しくは、こちらのドキュメントをご覧ください。
Don Turner が、Android のオーディオ レイテンシの改善と、それがリアルタイム オーディオ アプリに与える影響について解説しています。このブログ記事では、エコシステムでの変更内容と今後の計画、そして Oboe ライブラリを使って低レイテンシ オーディオ アプリを構築する方法を取り上げています。
Jetpack Compose は、常にユーザーを念頭に置いて開発されています。一番のユーザーは、デベロッパーの皆さんです。Android Studio の Compose プレビュー機能がどのように設計され、さまざまな UX の研究がそのデザインや機能にどのような影響を与えたのか、Preethi Srinivas と Paris Hsu がこちらのブログ記事（英語）で解説しています。
Wear OS Tiles が刷新されました。まだアルファ版ですが、カスタムタイルを作成できる新しい Jetpack Tiles ライブラリをリリースしました。Wear OS でタイルを使うと、アプリを開かずに情報やアクションにすばやくアクセスできます。なお、対応する Wear OS プラットフォームのアップデートが今春にロールアウトされた後、ユーザーはカスタムタイルを利用できるようになります。
Jetpack Compose チームが API ガイドラインを公開しました。Jetpack Compose API を使いこなすためのパターンやベスト プラクティス、スタイルのガイドラインがまとまっています。このガイドは Compose らしいコードを書くために参考になりますので、ぜひご確認ください。Compose API 全体の背景にある考え方を詳しく知りたい方もご一読ください。
Caren Chang と私が、Android でコルーチンを使う方法についてリアルタイム セッションで解説しました。コルーチンのドキュメントや基本の Codelab をご紹介しつつ、チャットで寄せられる質問に回答しました。
コルーチンについての学習をスタートする方は、Android Studio にアクセスし、この動画を見ながらコーディングしてみましょう。
数週間前に Jetpack Compose がベータ版になり、デベロッパー チャレンジが始まりました。その結果、1 週目には子犬の里親探しアプリが、2 週目にはカウントダウン タイマーがインターネットにあふれました。続いて 3 週目はスピード勝負、最終週の第 4 週はお天気アプリの課題にチャレンジしていただきました。
参加する時間がなかった方も、このチャレンジを活用して、ご自分のペースで Compose を試してみてください。
前回の Now in Android 以降、Android Developers Backstage に新しいエピソードが投稿されています 。以下のリンクまたはお気に入りのポッドキャスト クライアントでご確認ください。
ADB 158: Jetpack Compose… C’est bêta !
Chet Haase、Romain Guy、Tor Norbye が、Jetpack Compose チームから 4 名のゲスト Nick Butcher、Clara Bayarri、Leland Richardson、Adam Powell と「Compose がベータ版になったこと」の意味、コルーチン、マテリアル デザインの実装、ConstraintLayout などの Jetpack が提供する機能について話を聞きました。
今回は以上です。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。
この記事は Jolanda Verhoef による Android Developers Blog の記事 "Creating custom Tiles on Wear OS by Google with the Jetpack Tiles library" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Wear OS by Google スマートウォッチのタイルは、2019 年に導入されてから、特に便利で有用な機能になっています。タイルは高速にアクセスでき、使い勝手が良く、手首から必要な情報や作業にスワイプでアクセスできるように設計されています。さらに、ユーザーは確認したい情報やアクションを自由に操作できます。
2021 年 3 月 12 日（日本時間 3 月 13 日）に、Jetpack Tiles ライブラリがアルファ版になったことをお知らせします。このライブラリを使うと、デベロッパーは Wear OS スマートウォッチでカスタムタイルを作成できます。なお、対応する Wear OS プラットフォームのアップデートが今春にロールアウトされた後、ユーザーはカスタムタイルを利用できるようになります。
タイルは、日々の活動の進捗状況をトラッキングする、すばやくワークアウトを始める、最近聴いた曲を再生する、お気に入りの連絡先にメッセージを送信するなど、たくさんのユースケースに利用できます。アプリが没入的な体験を提供できる一方、タイルは高速に読み込めるので、ユーザーはすぐに行いたいことに集中できます。ユーザーがさらに情報を必要としているなら、タイルをタップしてスマートウォッチやスマートフォンで関連するアプリを開き、細かい処理を行うことができます。
タイルは Wear OS アプリの一部として、Android Studio で作成できます。最初に Wear OS Tiles への依存関係を追加します。
dependencies { implementation "androidx.wear:wear-tiles:1.0.0-alpha01" debugImplementation "androidx.wear:wear-tiles-renderer:1.0.0-alpha01" }
1 つ目の依存関係には、タイルの作成に必要なライブラリが含まれています。2 つ目の依存関係は、アクティビティでタイルをプレビューするためのものです。
次に、TileProviderService を使ってタイルの表示に必要な情報を提供します。
TileProviderService
class MyTileService : TileProviderService() { override fun onTileRequest(requestParams: RequestReaders.TileRequest) = Futures.immediateFuture(Tile.builder() .setResourcesVersion("1") .setTimeline(Timeline.builder().addTimelineEntry( // For more information about timelines, see the docs TimelineEntry.builder().setLayout( Layout.builder().setRoot( Text.builder().setText("Hello world!") ) ) ) ).build()) override fun onResourcesRequest(requestParams: ResourcesRequest) = Futures.immediateFuture(Resources.builder() .setVersion("1") .build() ) }
このコードには、重要な部分が 2 つあります。
onTileRequest()
TimelineEntry
onResourcesRequest()
タイルをプレビューするには、簡単なアクティビティを作成します。このアクティビティは、デバッグおよびプレビューのみに利用するので、src/main ではなく、src/debug に追加します。
src/main
src/debug
class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val rootLayout = findViewById<FrameLayout>(R.id.tile_container) TileManager( context = this, component = ComponentName(this, MyTileService::class.java), parentView = rootLayout ).create() } }
以上でタイルを公開する準備が整います。さらに詳しい手順を知りたい方や、タイルについてのさらに詳しい情報を確認するには、新しいガイドと、サンプルタイルの実例をご覧ください。
Jetpack Tiles ライブラリはアルファ版なので、API を改善するためのフィードバックをお待ちしています。それでは、コーディングをお楽しみください。
Reviewed by Yuichi Araki - Developer Relations Team and Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Ashnil Dixit による Android Developers Medium の記事 "Collaborating with local payment partners to drive awareness and conversion" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年、1 ドル未満の価格や現地価格に対する効率的なアプローチを探す上で役立つヒントについてのブログ記事（英語） を公開しました。今年は、インドと東南アジアでユーザーのコンバージョンを推進するベスト プラクティスについて、記事とケーススタディから成る 4 部構成のシリーズを連載します。今回はその 1 回目です。
Google Play を使うと、ユーザーは Play Billing が提供するさまざまな決済方法（クレジットカード、携帯通信会社の課金、Google Play ギフトカードなど）を選択できるようになります。その中には、インドの UPI、タイの TrueMoney、インドネシアの GoPay など、現地特有の決済方法も多く含まれています。
しかし、最近の調査（Google Consumer Survey、Ipsos 2020）によると、大半のユーザーは現地特有の決済方法が使用できるということに気づいていません。この点は、ユーザーを課金ユーザーにコンバージョンする上で障壁になる可能性があります。
現地のエコシステム パートナーは、巨大な取引ユーザーを保持しています。そのため、ゲームのリリースや主要な LiveOps（ゲーム内イベント） のタイミングにおいて、非常に魅力的な共同マーケティング パートナーになります。こういった現地エコシステム パートナーと連携することで、ゲームの認知度を上げて高品質なユーザーを獲得できる可能性があります。
通常、決済パートナーは、さまざまなチャンネル（アプリ内およびオンライン メディア）を通してゲームの特典や LiveOps（ゲーム内イベント）、リリースをプロモーションするため、デベロッパーが新しいユーザーを獲得する上で役立ちます。
現地の決済パートナーと共同でマーケティングやキャンペーンを行うことで、デベロッパーの初回購入者数、合計消費額、インストール数などが増加します。
インドや東南アジアで支払者へのコンバージョンを推進する上で、デベロッパーができることはたくさんあります。現地の決済パートナーとのコラボレーションもその戦略の 1 つです。決済パートナーは大規模な取引ユーザーのベースを保持しているので、ここぞというタイミングでプロモーション効果を増幅させ、認知度を高めて、支払者へのコンバージョンを推進する上で役立ちます。これらの地域でビジネスの拡大を検討している方は、コラボレーションの機会を探してみるのもいいかもしれません。
さらに詳しい情報は、アプリ開発を成功させるためのアカデミーのゲームビジネス基礎コースで提供しています。価格の差別化やモバイルゲーム製品に関するレッスンをご覧ください。
この記事のインフォグラフィック版は、簡単に共有できます。こちらからご覧ください。
Reviewed by Hidenori Fujii - Google Play Developer Marketing APAC
