この記事は 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
この記事は 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 対応自動車へ、簡単に配信できるようにすることです。ライブラリが複雑な画面のフォーム ファクタや入力モードを抽象化してくれるので、デベロッパーのみなさんはアプリの魅力を高める作業に集中して取り組むことが可能になりました。
ナビゲーション、駐車場、充電スポットのアプリを製品版として公開できるようになったことは、大きな一歩であるとともに、さらに長い道のりの始まりでもあります。より多くのデベロッパーのみなさんが開発した自動車用アプリが作成されることをとても期待しています。また、皆さんと協力してすばらしい車内体験を提供することを楽しみにしています。
この記事は 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
パッケージの可視性の詳細については、以下の情報をご覧ください。
それでは、コーディングをお楽しみください。
この記事は 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
先月は、Android の次期バージョンの初期プレビューとして、Android 12 デベロッパー プレビューを公開しました。今月、2021 年 3 月 17 日（日本時間 3 月 18 日）に Android 12 デベロッパー プレビュー 2 をリリースしました。このビルドでは、アプリでテストできる新機能や変更点がさらに追加されています。
初期 プレビュー プログラムは、オープン性とコミュニティの皆さんとのコラボレーションで改善を行う、私たちの中核的な理念に基づいて進められています。皆さんから寄せられた情報を元に、Android をデベロッパーやユーザーにとって、よりよいプラットフォームにするために引き続き開発していきます。ぜひ今後もフィードバックをお寄せください。
Android 12 では、プライバシーとセキュリティを中核に据え、OS をよりスマートにし、使いやすさとパフォーマンスを向上させることを目指しています。また、ユーザーがスマートフォン、ノートパソコン、タブレット、TV、自動車のどれを使っていてもすばらしい体験を提供できるように、新しいツールの開発も進めています。デベロッパー プレビュー 2 で注目すべき機能は、新しい角丸画面 API、ピクチャー イン ピクチャー API の改善、コンパニオン デバイス管理の改善、ぼかしや色フィルタなどのエフェクトの使い勝手の向上、アプリ オーバーレイ コントロールなどです。
デベロッパー プレビュー 2 には、注目すべき機能がたくさん含まれています。ここでは、そのいくつかをご紹介します。詳しい情報を確認したい方や Pixel にダウンロードしたい方は、Android 12 デベロッパー ウェブサイトをご覧ください。既にデベロッパー プレビュー 1 または 1.1 を実行している方は、無線（OTA）アップデートで最新のリリース データを受信することもできます。
私たちは、デバイスやデータを安全に保ちつつ、ユーザーにとっての透明性と制御を向上させることに注力し続けています。このリリースでは、実際に確認してアプリでテストできる新機能をいくつか追加しました。
上記の詳細やその他のプライバシーやセキュリティの変更点については、こちらをご覧ください。
view.setRenderEffect(RenderEffect.createBlurEffect(radiusX, radiusY, SHADER_TILE_MODE))
新しいバージョンのプラットフォームをロールアウトするにあたって、アプリの互換性を優先し、迅速かつスムーズにアップデートできるように作業を行っています。皆さんが Android 12 に対応する時間を長くとれるように、Android 12 ではアプリに関連する変更のほとんどがオプトイン方式になっています。また、短時間で対応できるように、ツールやプロセスをアップデートしています。
リリースに一歩近づいたデベロッパー プレビュー 2 では、全般的な安定性を改善する作業を続けています。今が新機能や変更点をテストする良いタイミングです。特に、API に関するご意見や、プラットフォームの変更点がアプリに与える影響に関する詳しいフィードバックをお待ちしています。フィードバック ページから、問題の報告をお願いします。
また、今は互換性テストを行って必要な作業を洗い出し始めるべきタイミングでもあります。Android 12 Beta 1 までに互換性のあるアップデートをリリースできるように、早めにこの作業を開始することを推奨しています。現時点では、アプリの targetSdkVersion を変更する必要はありませんが、動作の変更点の切り替えを使うと作業がスムーズに行なえます。Android 12 の変更点をオプトインすることで、アプリがどのような影響を受ける可能性があるかについての予備知識を得ることができます。
2021 年 8 月に Platform Stability に到達すると、アプリに関連するすべてのシステム動作、SDK/NDK API、非 SDK リストが確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリをリリースできます。デベロッパー向けのタイムラインの詳細は、こちらをご覧ください。
このデベロッパー プレビューには、Android 12 の機能を確認し、アプリをテストしてフィードバックを私達にお送りいただくために必要なすべてのものが含まれています。Pixel 3 / 3 XL、Pixel 3a / 3a XL、Pixel 4 / 4 XL、Pixel 4a / 4a 5G、Pixel 5 のシステム イメージへダウンロードすると、すぐに利用を開始できます。Pixel デバイスをお持ちでない方は、Android Studio で 64 ビット システム イメージと Android Emulator を使うことができます。
今回のリリースでは、Android TV でアプリをテストしたり、まったく新しい Google TV エクスペリエンスを試したりすることもできます。詳細はこちらをご覧ください。開発を始めるには、ADT-3 デベロッパー キットを利用します。
開発に必要な詳細情報一式は、Android 12 デベロッパー ウェブサイトでご覧いただけます。
この記事は Jolanda Verhoef による Android Developers Blog の記事 "Android Dev Challenge Finale: Weather app" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
#AndroidDevChallenge の最終週は、皆さんの創造性を輝かせましょう！先週はスピードの勝負でしたが、最終週となる今回で全力を出し切ってください。
UI はすべて Compose で構築する必要があります。気象データはダミーのもので構いません。提出するアプリは、最低でも英語をサポートする必要があります。
皆さんの作品は、以下の 4 つのカテゴリに基づいて審査します。
レイアウト、テーマ、グラフィックに関する Compose ドキュメントを確認し、美しいデザインの実装の参考にしてみましょう。アニメーションやジェスチャーの斬新な使用法も考えてみてください。コードの質は、アーキテクチャとテストによって改善できます。また、動作全般については、ユーザー補助機能を忘れずに確認するようにしましょう。
回答は、パブリック GitHub リポジトリで実装する必要があります。Github リポジトリ テンプレートのコピーを作成し、README の手順に従ってください。テンプレートには、Compose による基本的な Hello World! と継続的インテグレーション設定が含まれています。
Hello World!
※1 応募に関する詳細は必ず公式ルールをご確認ください。
今週も究極の 5G Google スマートフォン、Google Pixel 5 を獲得するチャンスです！4 つのカテゴリそれぞれの勝者と、最も優秀な作品に、Google Pixel 5 を進呈します。
Jetpack Compose の中核はデベロッパー コミュニティです。プロダクトをさらに使いやすく改善するために、皆さんのフィードバックをお寄せください。
この記事は Neethi Thomas、Dafna Gal、Ashnil Dixit による Android Developers Blog の記事 "Sub-dollar pricing expansion in 20 markets" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google Play では、Android デベロッパーがアプリやゲームをできる限り広いマーケットに提供できるようにするために継続して対応を行ってきました。既に 165 以上のマーケットで無料と有料のアプリをサポートし、インドやブラジルなどの 20 のマーケットで、デベロッパーが設定できるプロダクトの最低価格を引き下げてきました。
このたび、2021 年 3 月 4 日（日本時間 3 月 5 日）に、新たにラテンアメリカ、ヨーロッパ、中東、アフリカ、アジア太平洋地域の 20 のマーケットでプロダクトの最低価格制限を引き下げたことをお知らせします。
この新しい下限額により、ほとんどの対象マーケットで 10-30 米セント相当の価格を設定できるようになります。この超低価格帯、すなわち「1 ドル未満」の価格設定を利用し、現地の購買力や需要を踏まえて価格を調整することで、新たな潜在購買層へのアプローチが可能になります。また、グローバルな価格戦略を柔軟に設定できるようになり、アプリやゲームで多くのユーザーを収益につなげるチャンスにもなります。
以下の新しいマーケットで、有料アプリ、アプリ内アイテム、定期購入の最低価格制限が引き下げられています。
バングラデシュ、ブルガリア、ボリビア、コスタリカ、チェコ共和国、デンマーク、クロアチア、ハンガリー、ヨルダン、カザフスタン、レバノン、スリランカ、ミャンマー、パキスタン、パラグアイ、ルーマニア、セルビア、タイ、タンザニア、ベトナム
これに加えて、以下のマーケットではすでに 1 ドル未満の価格設定が利用できます。
ブラジル、チリ、コロンビア、エジプト、インド、インドネシア、マレーシア、メキシコ、ナイジェリア、ペルー、フィリピン、ポーランド、ロシア、サウジアラビア、南アフリカ、トルコ、ウクライナ
Google Play Console で価格を調整する方法については、ヘルプセンターの記事をご覧ください。すべての価格帯が記載されたリストは、こちらからご覧ください。
2015 年にこの機能が導入されてから、Android デベロッパーは 1 ドル未満の価格設定を活用して、有料ユーザー数を拡大してきました。ここでは、1 ドル未満の価格設定を利用してビジネスを成長させる方法をいくつか紹介します。
期間限定の宣伝を行う：1 ドル未満の価格設定は、マーケティング活動によって新しいユーザーを獲得したり、低価格商品で熱心なユーザーに特典を提供するために活用できるツールです。たとえば、人気ゲーム Lords Mobile のデベロッパー IGG は、有料ユーザーのコンバージョンを増やすため、期間限定で 2-3 倍の価値があるスペシャル バンドルをわずか 3000 インドネシア ルピア（0.20 米ドル）で提供することがあります。これはスペシャル オファーなので、通常の売上を減らすことなく、支払者のベースを拡大できます。
シーズンごとの特典を提供する：1 ドル未満の価格設定は、シーズンごとの有償特典を提供するにも効果的です。ユーザーはこのようなアイテムを購入できる期間が限られていることを知っていなすので、さらに魅力を感じます。これを低価格設定と組み合わせることで、初回購入者にとっての魅力を高めることができます。Moonton は、Mobile Legends でそのシーズンで初めて購入を行ったユーザーに、レアなスキンを提供し、これは 1 ドル未満の購入の場合にも適用されます。
お試し価格を提供する：1 ドル未満の価格設定は、お試し価格で新しい有料ユーザーを惹きつけるために使うこともできます。たとえば、貴重なアイテムを購入したことがないユーザーに、1 ドル未満の価格を提示できます。先にも触れたデベロッパーの Moonton は Mobile Legends: Bang Bang で最初の購入を行ったユーザーが、お試し価格で人気のヒーローにアクセスできるようにしています。この戦略は、ゲーム全体の経済に大きな影響を与えることなく、新しい有料ユーザーにアプローチすることを可能にしています。
熱心なユーザーに特典を提供する：1 ドル未満の価格設定と、購入イベントの繰り返しを組み合わせて活用することもできます。たとえば、7 日間毎日購入したユーザーに特別なボーナスを提供し、ユーザーが納得できる購入額を超えないようにすることができます。
ガチャを提供する：1 ドル未満の価格設定は、チャンスベースのアイテム、たとえば「ガチャ」とも相性がよく、新規ユーザーへ効果的にアピールできます。価値のあるゲーム内アイテムを 5 ドルだと購入しないユーザーでも、0.15 ドルなら、中のアイテムが欲しくて宝箱を開けてくれるかもしれません。1 ドル未満の価格でガチャを提供すれば、多くのユーザーが運試しのために支払いをしてくれる可能性があります。
アプリやゲームの提供地域に合わせた 1 ドル未満の価格設定を活用する方法はたくさんあります。これらのベスト プラクティスは、あくまで一例です。皆さんのビジネスの拡大にこの機能をご活用ください。
この記事は Sameer Samat による Android Developer Blog の記事 "Boosting developer success on Google Play" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
デベロッパーが持続可能なビジネスを構築できるよう支援することは、Google Play の重要なミッションのひとつです。そのためにパートナーの声に日々注意深く耳を傾け、直面している問題点を理解し、創造性にあふれるアイデアの実現をサポートできるよう日々努めています。アプリを立ち上げ、軌道に乗せることは簡単ではありません！Google Play は、強力なマーケティング ツール、 Play Console 上の実用的なデータ、 Play Academy / ベスト プラクティス / ソート リーダーシップの様な教育コンテンツ、Indie Games Festival / Indie Corner / Accelerator Program のようなプログラムを通して、デベロッパーのサポートを世界中で行っています。そして私たちは成長をサポートする新しい形を常に模索しています。
そしてこのたび、2021 年 7 月 1 日より、すべてのデベロッパーを対象に、毎年の Google Play におけるアプリ内でのデジタル商品の販売による収益の合計が 100 万米ドルに達するまでの部分は、サービス手数料を 15% に引き下げることに致しました。これによりデベロッパーの皆さまが、エンジニアやマーケターの採用、サーバーのキャパシティの拡大など、ビジネスの成長にとって重要なフェーズに投資をしていくサポートができればと考えております。
こういった投資は、成長段階の早期にいるデベロッパーにとって特に重要ですが、アプリの事業拡大は年間収益 100 万米ドルを達成したからといって終わることはありません。年間 200 万ドル、500 万ドル、そして1000 万ドルの収益があるパートナーからも同様のお声を頂戴しています。そのため、ビジネスの大小に関わらず、すべての Google Play 上のデベロッパーに対し、年間合計収益が 100 万米ドルに達するまではサービス手数料の減額を適用します。この公平なアプローチは、すべてのデベロッパーの成功をサポートするという Google の大きなミッションに基づいています。本件の詳細に関しては、今後数か月をかけて共有させていただきます。
パートナーの皆さまの成功があってこそ、Google Play のプラットフォームとしての成功があります。Android と Google Play はパートナーである世界中のデベロッパーに常に耳を傾け、お寄せいただいたフィードバックをエコシステムの構築や運営に活用してきました。今後さらに多くのビジネスに Android 上で成長を遂げていただくこと、そしてその成長のため必要な新たな技術的、経済的なサポートの提供に関してデベロッパー コミュニティの皆さまと協議を重ねていくことを、今後も楽しみにしています。
この記事は Jolanda Verhoef による Android Developers Blog の記事 "Android Dev Challenge: Week 3 - Speed round" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
位置について... 用意… ちょっと待ってください！#AndroidDevChallenge 第 3 週の予定を空けておきましょう。本日 3 月 13 日に、同じタイムゾーンのデベロッパーとのスピード競争を開催します。日本の皆さんは、午前 10 時からのスタートです。Compose スキルが一番速い人が勝者ですので、ぜひチャレンジしてください。第 1 週と第 2 週の創造性あふれる作品はすべてすばらしいものでしたが、次に求められるのはスピードです。
UI はすべて Compose で構築する必要があります。また、課題のデザインで指定されるすべてのガイドラインに厳密に一致しなければなりません。実装にあたっては、テーマ、レイアウト、ナビゲーションに関する Compose ドキュメントを参考にしてください。ハンズオンの学習教材として Compose Pathway を試すこともできます。このチャレンジに役立つトピックを説明した Codelabs が含まれています。
回答は、GitHub リポジトリで実装する必要があります。こちらの Github リポジトリ テンプレートをコピーし、README に記載された手順に従ってください。テンプレートには、Compose による基本的な Hello World! と継続的インテグレーション設定が含まれています。
今週のチャレンジの賞品は、究極の 5G Google スマートフォン、Google Pixel 5 です。アジア太平洋地域タイムゾーンからの応募者の中で、課題のチャレンジを最速で実装して送信したデベロッパー 1 名に贈呈します。
この記事は Tom Grinsted による Android Developers Blog の記事 "Google Play Console powers better strategic decisions with new engagement metrics and unique benchmarks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 3 月 2 日（日本時間 3 月 3 日）、Google Play Console で、一連の新指標と独自の比較用ベンチマークをリリースしました。これらを使うと、最大 250 種類の類似アプリのグループと比較しながら、アプリやゲームのエンゲージメントと収益化のトレンドを評価できます。そのため、プロダクトのロードマップやビジネス機会について、情報に基づく優れた決定に役立てることができます。
新機能を活用してエンゲージメントを促進する、価格に関する実験を行う、維持率の向上を図るなど、目的にかかわらず、最適な投資を行うために重要なデータと分析結果を必要としている、すべてのデベロッパーの皆さんの声に私たちは耳を傾けています。
大規模なデベロッパーなら、ポートフォリオ間でデータを比較できる場合もありますが、常にそれが可能なわけではありません。たとえば、新しい国や地域にあなたのアプリをリリースして展開するとき、直接比較できるアプリを公開していない場合、あるいはそもそも 1 つか 2 つのアプリやゲームしか公開していない場合などです。そのような場合、アプリやゲームのパフォーマンスが よい かどうか、そしてそのパフォーマンスをどこで改善できるのかは、どのように判断すればよいでしょうか。
今回リリースした機能は、背景となる情報を整理してパフォーマンスを把握しやすくしたもので、あらゆるタイプのデベロッパーをサポートすることを目指したものです。新機能は以下のとおりです。
私たちは、モバイルアプリやゲームの成長戦略エキスパートと連携し、アプリやゲームのパフォーマンスを評価する実践的なベスト プラクティスを参考にしながら、エンゲージメントと収益化に関する一連の指標を新しく導入しました。たとえば、次のようなものがあげられます。
すべて合わせれば、15 個の正規化された新しい指標をベンチマークとともにリリースすることになります。また、分子と分母の絶対数も照会できるようになっています。これらはすべて、[統計情報] ページに新設された [類似アプリと比較] タブから利用できます。利便性を向上させるため、既存のストア掲載情報のコンバージョンデータなど、その他の正規化された重要指標もこの画面に含めています。
あなたのアプリの改善領域を見つけ、意思決定をサポートするため、正規化された新指標では、すべて類似アプリとのパフォーマンス比較が標準機能としてリリースされます。指標は時間で追跡したり、「パズルゲーム」「オーディオブック」「コミック」といった最大 250 種類のアプリやゲームのカテゴリと比較したりできます。
国フィルタを使うと、ビジネスニーズに合うように表示をカスタマイズできます。たとえば、似たようなゲームが日本のユーザーから多くの収益を上げているかどうかがわかります。また、インドでのロイヤルティに関して、チームが最新機能を提供したことが他の類似アプリを上回るパフォーマンスにつながっているかどうかを確認することもできます。
我々は開発プロセスの中で、実際に一部のパートナーと協力して、この一連の新指標を試しました。そのフィードバックは、私たちのアプローチを具体化するうえで役立っただけでなく、ポジティブなものでもありました。 「この新指標と比較情報は意思決定に役立ちます。現在のゲームに関してどのような対策をとるべきかだけでなく、将来のゲームに関する戦略的決定にも有効です。私たちにとっては、既に Google Play Console で最も価値のある機能の 1 つとなっています」Plarium Global Ltd. Guy Ulmer 氏
この新指標や知見を最大限に役立ててもらえるように、Google Play Academyに新しいコースを追加して短期間で習得できるようにもしました。ビジネスの成長を一気に加速させる方法をご説明しているマスタークラス ウェビナー（英語）もご覧ください。
今回の新指標の元になるデータは、アプリの利用状況を Google と共有することに同意したユーザーに由来し、全体数を適切に表せるようにモデリングされています。このデータは、アプリをフォアグラウンドで開いたかどうかの記録でしかありません。ユーザーは、データの制御や共有のオプトアウトが可能です。また、myactivity.google.com で個々のイベントを削除することもできます。
さらに、今回の新しいデベロッパー指標は初めて差分プライバシーを利用したものです。差分プライバシーは、さまざまなデータセット全体でプライバシー保護を強化する高度な技術です。このアプローチの詳細については、こちらのブログ記事（日本語）でご覧いただけます。
これまでのベンチマークのリリースと同じように、類似アプリとの比較指標は、すべてデベロッパーのプライバシーを保護する形で行われています。データは多数のアプリやゲームから生成され、個々のアプリのパフォーマンスが類似アプリのグループに共有されることはありません。この仕組みは、Google Play Store の高度なタグ付けシステムによって実現しています。つまり、高品質で信頼性が高く、有用な比較が可能ですが、皆さんが確認する類似アプリのグループでは、特定の競合他社のアプリのパフォーマンスは不明瞭化されており、それは皆さん自身のアプリのパフォーマンスに関しても同様です。
今回のリリースは、Google Play Console でさらに有用な知見を提供し、積極的なレコメンデーション機能を実現することを目指した複数年にわたるプロジェクトの最初のリリースです。多くの大規模なモバイルアプリ デベロッパーは、成長戦略コンサルタントによる情報を活用しながら、プロダクトに関する長期的、戦略的な決断を行っています。私たちは、コンソールを通して、このようなサポートや専門性を すべての Google Play デベロッパーに提供したいと考えています。今後もさらに機能をリリースする予定です。ご期待ください。
この記事は Florina Muntenescu による Android Developers Blog の記事 "Android Dev Challenge: Week 2 - Countdown timer" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
3...2...1… 次のチャレンジの時間です！#AndroidDevChallenge の第 2 週にようこそ。第 1 週は、創造性あふれるたくさんの作品が寄せられ、とても楽しく見せていただきました。第 2 週の作品も楽しみにしています。では早速、今週のチャレンジを出題します。
UI はすべて Compose で作成する必要があります。実装にあたっては、状態とアニメーションに関する Compose ドキュメントを参考にしてください。ハンズオンの学習教材として Compose Pathway を試すこともできます。このチャレンジに役立つトピックを説明した Codelabs が含まれています。
チャレンジに参加するためには、GitHub リポジトリで実装する必要があります。こちらの Github リポジトリ テンプレートをコピーし、README に記載された手順に従ってください。テンプレートには、Compose による基本的な Hello World! と継続的インテグレーション設定が含まれています。
2 週目の賞品は、皆さんと一緒に作り上げるアート作品です。このチャレンジを成功させた最初の 500 名の方に、Jetpack Compose ポスターと Android ペン一式を差し上げます。ストレス解消のために皆さんだけの塗り絵を作りましょう。さらに、チーム Jetpack が悪しき UI から宇宙を救う物語が描かれた Jetpack Compose の限定マンガポスターもついています。
この記事は Anna-Chiara Bellini、Nick Butcher による Android Developers Blog の記事 "Announcing Jetpack Compose Beta!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 2 月 24 日（日本時間 2 月 25 日）、Jetpack Compose のベータ版をリリースしました。新しい UI ツールキットである Jetpack Compose は、すべての Android プラットフォームでネイティブ アプリを高速かつ簡単に開発できるようにすることを目指して設計されています。Compose が提供するのは、最先端の宣言型 Kotlin API です。これにより、少ないコードで美しくレスポンシブなアプリを作ることができます。Compose は既存の Android アプリや Jetpack ライブラリに組み込めるので、Android のビューと Compose を組み合わせながら、自分のペースで採用できます。
今回のベータ版リリースで Compose の API は確定版になりました。これで本番向けのアプリを構築する際に必要な機能がすべてそろったことになります。ベータ版には、API が安定したという意味合いもあります。つまり、API が変更されたり、削除されたりすることはありません。Compose を学び始め、今後のプロジェクトや機能にどう活用するかについて計画を立てるには、今が絶好の機会です。Compose は今年中に 1.0 に到達する予定です。
Compose チームは、コミュニティの皆さんからのフィードバックも取り入れて、オープンに開発を進めています。2019 年に開発をオープンソース化して以来、30 回のパブリック リリースを行い、外部から寄せられた 700 個以上のバグに対応し、200 件以上の外部からのコントリビューションを受け入れました。皆さんに Compose を使ってアプリを開発していただくことはとても嬉しいことで、いただいたフィードバックや機能リクエストは API の微調整や作業の優先順位を付けることに役立っています。アルファ版リリース以降も、たくさんの機能を追加または改善しています。
ベータ版リリースでは、API の完全性を確保することに重点を置いています。つまり、1.0 やその先に向けて、土台となる API を提供することです。今後は、1.0 リリースに向けてこれらの API の機能を安定させる作業を進める予定です。アプリのパフォーマンスとユーザー補助機能には、特に重点を置いています。
最新の Android Studio Arctic Fox Canary 版は Compose ベータ版をサポートしており、たくさんの新しいツールも搭載しています。
🆕 ライブ リテラル: デバイスやエミュレータで、プレビューのリテラルをリアルタイムにアップデート🆕 アニメーション プレビュー: アニメーションの調査と再生🆕 Layout Inspector の Compose サポート🆕 インタラクティブ プレビュー: Composable を切り離して調査や操作が可能🆕 デプロイ プレビュー: アプリ全体をデプロイすることなく、デバイスに Composable をデプロイ
🆕 ライブ リテラル: デバイスやエミュレータで、プレビューのリテラルをリアルタイムにアップデート
🆕 アニメーション プレビュー: アニメーションの調査と再生
🆕 Layout Inspector の Compose サポート
🆕 インタラクティブ プレビュー: Composable を切り離して調査や操作が可能
🆕 デプロイ プレビュー: アプリ全体をデプロイすることなく、デバイスに Composable をデプロイ
Jetpack Compose は、Android ビューと共存してシームレスに動作するように設計されているので、自分のペースで採用できます。具体的には、Android ビューに Compose UI を埋め込んだり、Compose の中でビューを使ったりすることもできます。相互運用性に関するドキュメントに、たくさんの採用戦略をまとめました。
既存アプリに Compose を追加する際に役立つように、ビューとの相互運用性に加えて、よく使われるライブラリとの統合も行っています。そのため、アプリを書き直したり、アーキテクチャを変更したりする必要はありません。以下の統合が利用可能です。
MDC-Android Compose Theme Adapter ライブラリや Accompanist ライブラリを使えば Material および AppCompat のXML テーマとの統合機能を利用できるので、テーマを重複して定義する必要はありません。Accompanist は、よく使われるイメージ読み込みライブラリのラッパーも提供します。
Jetpack Compose は、 宣言型 UI ツールキットであり、現在のビューシステムからのパラダイム シフトです。つまり、記述するのは、アプリが特定の状態のときに UI がどのように見えるべきか であって、 どのように UI を生成するかではありません。アプリの状態が変わったときは、Compose によって UI がアップデートされるため、UI を操作して目的の状態に変更するという面倒でエラーが起こりやすい作業は必要なくなります。
また、Compose はすべて Kotlin で書かれているので、優れた言語機能を活用して、簡潔で強力かつ直感的な API を提供できます。たとえば、コルーチンを使うと、ジェスチャー、アニメーション、スクロールなど、はるかにシンプルな非同期 API を書くことができます。そのため、ジェスチャーに続いてアニメーションするなど、非同期イベントを組み合わせたコードを簡単に書けるようになります。キャンセルやクリーンアップはすべて構造化され、並列に行われます。
皆さんや皆さんのチームが Jetpack Compose に関するあらゆることを学習できるように、Jetpack Compose Pathway をアップデートしました。これは、動画やハンズオン Codelabs、重要なドキュメントを厳選した一覧であり、Compose を始める際に役立ちます。本日は、新しく作成またはアップデートしたガイド ドキュメントも公開します。たくさんのスクリーンキャストや新しい Animation Codelab を通じて、Compose で開発を始める方法を詳しく学ぶことができます。アーキテクチャ、ユーザー補助機能、テストに関するガイドから、アニメーション、リスト、Compose の思想に関する詳しい説明まで、作業をより早くするために役立つガイドも準備しました。
さらに、実際に動作する Compose をすぐに見てみたい方のために、8 つの公式サンプルアプリも提供しています。シンプルなものから複雑なものまで、すべて異なる API やユースケースを扱っています。詳しくは README をご覧ください。
Compose を始める準備ができ、賞品も獲得したい方は、#AndroidDevChallenge に挑戦してください。Jetpack Compose で優れたアプリをすばやく作成する技術を身につけられるよう、4 週間にわたって日本時間の木曜日朝、週単位のチャレンジを出題します。各チャレンジでは、「インサイトを開放する」をテーマに、アニメーションやマテリアル テーマ、Composable やリストなど、毎回 Compose の新しい領域を扱います。毎回のチャレンジの勝者に新しい賞品があり、Pixel 5 を含む 1000 個以上の賞品を準備しています*。2 月 25 日から始まっている第 1 週のチャレンジの詳細は、こちらをご覧ください。
Jetpack Compose はベータ版に到達し、1.0 に向けた確定版の API や機能が完成しています。アプリで Compose を採用した方は、ぜひフィードバックをお寄せください。Kotlin Slack の #compose チャンネルで行われているディスカッションへの参加もお待ちしています。
*毎週のチャレンジに新しい賞品が設定されています。Google Pixel 5 が賞品になる週で、Google Pixel 5 が利用できない国にお住まいの方には、同程度の価値がある電子ギフトカードをお送りします。詳しくは公式ルールをご覧ください。
この記事は Hoi Lam による Android Developers Blog の "Quality to match with your user’s expectations" を元に翻訳・加筆したものです。詳しくは元記事をご確認ください。
10 年以上前に Android がリリースされてから、このプラットフォームは成長を続け、ユーザーの期待も高まるばかりです。それに伴い、ユーザー エクスペリエンスから、マテリアル デザイン、プライバシーの重要性と進化に至るまで、さまざまな改善が行われてきました。その一方でデベロッパーの皆さんが、常にアプリでよりすばらしいユーザー エクスペリエンスを提供していきたいと考えていることは承知しています。同時に、どの領域に最初に取り組むべきかを判断するのが難しいことも、私たちは把握しています。そこで、Android Developers のウェブサイトにアプリの品質セクションを新たに設けて、アプリの品質の重要な内容についての最新情報や関連リソースを提供します。
今回の最初のリリースでは、Android の最新リリースや、アプリ エコシステムの現在のトレンドを踏まえて、アプリの中核品質チェックリストを更新しました。このアップデートのいくつかのポイントを示します。
常に最新の状態を保てるように、今後は四半期ごとにこのリストを更新したいと考えています。また、他のフォーム ファクタの品質チェックリストも更新する予定です。
現在は、Android で高品質なアプリを簡単に構築できるように、追加のツールやベスト プラクティスに関する作業を進めています。引き続き改善を続けていきます。ご期待ください。
この記事は Ting-Yuan Huang、David Winer による Android Developers Blog の記事 "Announcing Kotlin Symbol Processing (KSP) Alpha" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 2 月 10 日（日本時間 2 月 11 日）、Kotlin Symbol Processing（KSP）のアルファ版をリリースしました。このまったく新しいツールは、Kotlin で軽量コンパイラ プラグインを作成するためのものです。KSP は KAPT に似た機能を提供しますが、最大 2 倍高速に動作し、Kotlin コンパイラ機能に直接アクセスできます。さらに、マルチプラットフォームの互換性を考慮して開発されています。
KSP は、Kotlin 1.4.30 以降のリリースと互換性があります。オープンソースのコードとドキュメントは、KSP GitHub リポジトリでご確認ください。
Kotlin デベロッパーから最も多く寄せられるリクエストは、ビルド速度の高速化です。多くのデベロッパーは、毎日何十回もアプリのデプロイを繰り返しています。そのため、遅いビルドが終わるのをじっと待たなければならないのは、大きな時間の無駄になる可能性があります。Kotlin コードのコンパイルで特に難しい点は、Kotlin にネイティブのアノテーション処理システムがないことです。Android では Room などにアノテーション プロセッサが多用されていますが、これは Java のアノテーション処理との互換性に依存しており、Kotlin Annotation Processing Tool（KAPT）を通して行われます。しかし KAPT では、中間 Java スタブを生成し、それを Java アノテーション処理システムで処理しなければならないので、高速に実行できるとは限りません。
KSP を設計するにあたって、Kotlin のアノテーション処理を一から構築するとしたら、それはどのようなものになるかについて検討しました。KSP は、Kotlin コードを直接解析する強力でシンプルな API を提供します。そのため、KAPT のスタブ生成によって生じていたビルド速度の遅さを大幅に改善できます。実際に、Room ライブラリを使った初期のベンチマークでは、KSP は KAPT に比べてほぼ 2 倍高速であることが実証できています。
実際に動作する KSP がどのようなものかを確認するには、GitHub から KSP Playground プロジェクトをダウンロードしてください。以下の内容が含まれています。
test-processor
workload
ビルダーを実装するすべてのロジックは test-processor 内にあります。コンシューマー（workload）側で KAPT と KSP を使用する際の唯一の違いは、次のようにビルドファイルに 2 行分の差異があることだけです。
これが KSP の目指すところです。ほとんどの Android アプリのデベロッパーは、内部処理について心配する必要はありません。この 1 行を変更しさえすれば、KSP をサポートするライブラリは通常のアノテーション プロセッサのように見えます。違うのは、最大 2 倍高速になることだけです。ただし、KAPT と KSP を同じモジュールで利用すると、内部的にビルドが遅くなる可能性が高くなります。そのため、アルファ版の期間中は、KSP と KAPT は別々のモジュールで利用したほうがよいでしょう。
KSP に対応するアノテーション プロセッサが増えるにつれて、ほとんどのモジュールは KAPT の完全互換に近い形で KSP を利用できるようになるはずです。現在は、こちらの表でどのアノテーション プロセッサが KSP をサポートしているかを確認できます。KSP をサポートするライブラリや KSP のサポートを実装するライブラリがこの表にない場合は、提案と合わせてプルリクエストをお送りください。
現在アノテーション処理を利用しているライブラリ作成者の方は、ライブラリを KSP に対応させる方法がクイックスタートや README ガイドに掲載されていますので、ご覧ください。
KSP がアルファ版になったので、ライブラリ作成者にとっては、詳しい内容を確認して KSP Issue Tracker から API に関するフィードバックを送り始める絶好のタイミングです。リリースに関する最新情報は、Kotlin Slack の #ksp チャンネルに定期的に投稿しています。昨年 6 月のデベロッパー プレビュー以降、100 以上のバグや問題に対応してきました。その中には、Kotlin ライブラリ デベロッパーのすばらしいコミュニティの皆さんから報告いただいたものもたくさん含まれています。
Java は Oracle および/またはその関連会社の登録商標です。
