🐑
[Google I/O 2021 メモ]Top 12 tips to get ready for Android 12
動画
互換フレームワーク
- 本題に入る前に互換性フレームワークについて説明
- テストを特定の動作の変更ごとに分離できると便利
- Developer OptionsやADBコマンドから新機能を個別にON/OFFできる
ForegroundService
- スマートフォンユーザーにとってマルチタスクを実行するのは一般的。ポッドキャストを聞きながら食事注文、道案内をしながらメールチェックなど
- フォアグラウンドサービスも使っているはず
- マルチタスク環境でユーザーアクションを完了させるために使う
- フォアグラウンドサービスの46%がバックグラウンドからの起動
- フォアグラウンドサービス通知が予期せず表示されるとユーザーは驚き、迷惑に感じる
- フォアグラウンドサービスはシステムリソースを消費する
- Android12ではフォアグラウンドサービスのバックグラウンドからの起動を認めないことにした
- targerをAndroid12にしたら
- なるべく早く実行する必要がある短いバックグラウンドタスクのためにExpeditedJobsを導入
- 低レイテンシのJob
- フォアグラウンドからもバックグラウンドからも呼び出せ、すぐに実行される
- 詳細はEffective background tasks on Androidで
マイクとカメラの切り替え
- ユーザーがマイクやカメラへのアクセスを無効にすることができる
- アプリが権限のベストプラクティスに従っていれば変更はいらない
- アプリは引き続きマイク/カメラにアクセスしているとみなすが、無効になっている場合は空のフィードを受け取る
- システムは現在の切り替え状態をユーザーに通知する
- targetSdkに関係なくアプリに影響する
アプリの休止状態
- インストールされたアプリはストレージなどのシステムリソースを消費する
- ユーザーがアプリでPermissionを取得しているかもしれない
- Android11での権限の自動リセット機能を拡張
- 未使用のアプリを休止状態にする
- 休止状態のアプリでは次のことが起こる
- 以前に付与されたPermissionの取り消し
- アプリのキャッシュがクリアされストレージが開放
- Jobとプッシュメッセージが停止
- アプリはユーザーがアプリを強制停止したかのように動作する
- 詳細はWhat's New in Android Privacyで
Bluetooth
- Bluettothスマートウォッチ/ヘッドセットなどの近くのデバイスを検出するための、もっときめ細かいPermissionモデルがほしいという意見が多くあった
- Android12をターゲットとしたアプリには、デバイス検出を位置情報権限から切り離すオプションが追加された
- デバイスペアリングのユースケース
- 新しいBLUETOOTH_SCAN権限を使う際に、usesPermissionFlagsを使うとビーコンなどのBluetoothデバイスから、位置情報を取得しないことを宣言できる
- デバイスがペアリングされると、BLUETOOTH_CONNECT権限を使って接続できる
- プライバシーに配慮したアプリ設計が重視されるだけでなく、ユーザーの不安も軽減される。Bluetoothは必要だけど、位置情報が不要な時に許可を求められなくなるから。
- アプリをコンパニオンデバイスとペアリングしている場合のベストプラクティスは変わらず、CompanionDeviceManager APIの利用
- 今回の変更の利点は効率的なUX
NetworkのMACアドレス
- Android12でNetwork MACアドレスへのアクセスを更に制限
- targer API Level がAndroid12のアプリでは、getHardwareAddress APIはnullを返す
- targer API Level他のAPIレベルでAndroid12端末では固定のプレースホルダ値を返す
- target12でも、Compatibility Flagを付けると一時的にプレースホルダ値を返させることができる。移行期間稼ぎ。
- 低APIレベルのAPIは避け、常にConnectivityManagerクラスの利用を推奨
- identifierに関しては、ユーザーがリセット可能なIDを使うのが最善
- ユースケースによってはSSAIDなどのオプションの使用も検討に入れる
exported attribute
- targerがAndroid12のアプリではintent-filterのあるコンポーネントでexported属性を明示的に指定する必要がある
- コンポーネントを共有するかどうかを意思的に示す
- そうしないとコンパイルできない
- AndroidStudioでlint警告してるので、検出に役立つ
- コンポーネントを共有するかどうかを意思的に示す
Notification
- フルカスタムしているNotificationは影響を受ける
- setCustomContentViewしているアプリ
- targetがAndroid12のアプリはシステムが標準テンプレートを使う
- 一貫したUXのため
- targetをAndroid12にして、Notificationのレイアウトの確認を行うことを強く推奨する
- 展開/折りたたみ/上部表示通知を含む
App Links
- http URLをインストール済みアプリにリンクさせるもの
- App Linkを構成する際にデベロッパーが間違いを犯しやすいことがわかった
- そうするとアプリを選択させるダイアログが必要以上に表示されて鬱陶しい
- そうするとアプリを選択させるダイアログが必要以上に表示されて鬱陶しい
- Android12では問題検出ツールを提供する
- リンクごとにApp Linksの検証をきめ細かくした
- サーバーサイド側に問題がある場合、エラーの原因は検証を通らないリンクに限定される
- adbコマンドがテストに役立つ
- adb shell pm verify-app-links --re-verify PACKAGE_NAME
- Andorid12では、デフォルトアプリが未インストールの場合は、直接ブラウザを開く
- Android12では、 ドメインの検証状態を確認できるAPI(デフォルトアプリに設定してるかどうか確認するAPI)と、設定に移動し承認を求めるAPIができた
- リンクごとにApp Linksの検証をきめ細かくした
- このツールを利用してApp Linksの準備ができているか確認してほしい
WebView
- Android12のWebViewでフローをテストすることを推奨
- WebViewはChromiumがベースでサードパーティーのCookieの処理に変更があった
- SameSiteという属性が変更され、ユーザーのセキュリティとプライバシーが向上している
- targetを12に設定するとテストできる
- またはWebView Dev Toolsで切り替えを行い、新しい動作を有効化することもできる
- テストではログインと支払いに関する問題に注意
- 安全でないページで始まり、安全でないページに移動するフローにも注意
Overscroll
- ユーザーがコンテンツの境界に達してもスクロールするエフェクトのこと
- 現在は、コンテンツの境界にグロー効果が表示されるが、Android12ではストレッチするようになる
- 目的は、既存のUXの改善とスクロールの停止を自然に表現すること
- テストするにはtargetをAndroid12にして、スクロール時に新しい挙動が適用されていることを確認
その他いろいろ
- 他にもまだまだある
- 多すぎてスライド一枚にはまとめきれない。ノートの余白にもかけない
- 特に力を入れたのは、
- タッチイベントの処理
- 通知トランポリン
- 正確なアラーム
- すべての変更やその他詳細は↓
Discussion