Android 11 Labs Day1 のまとめです。
デベロッパーアドボケイト
- 松内 良介
- 清水 智公
- ロドリゲス オスカル
の3名の方が登壇されました。
ご挨拶
全体のスケジュール
- 2020年2月 Developer Preview 1 を公開済み
- 2020年5月 Beta Release の予定
- 2020年Q3 Final Release の予定(7月〜9月)
今日の話題
Privacy
- プライバシー保護機能と近年の進化
- Android 10 の振り返り
- Android 11 での強化
Permission Changes
- パーミッションについての最新技術情報
- One-time permission
- Background Permission Flow
- New Foreground Service Types
Package Visibility
- 端末上の他のアプリの情報取得の制限
- New query API
- New Permission
Other Changes
- MACアドレスの利用制限
- System Alert Window 利用制限
Privacy changes
プライバシー保護機能の近年の進化
Android 10 の振り返り
Android 10 では、50件以上のプライバシー向けの機能を追加しました。 その中の Permissions, Device IDs, Background Activity について、詳細を申し上げます。
Permission
- プライバシーと位置情報についてのメニューを、設定画面のアクセスしやすい場所に配置しました。
- 位置情報について、新しいパーミッションを追加しました。
- 運動センサーについて、新しいパーミッションを追加しました。
- 画面に表示されているコンテンツを取得するための、新しいパーミッションを追加しました。
Device IDs
- ユーザーによってリセットすることが出来ない、 Permanent Device IDs の取得を制限しました。
- MAC アドレスをランダム化しました。
Background Activity
- バックグラウンドからの Activity の起動を制限しました。
位置情報の Permission に追加した「アプリ使用中のみ許可」は、半分以上のユーザーが利用していることが分かりました。 つまり、ユーザーは、様々なアプリに対して、共有するデータを制限したいという事が分かりました。
また、「このアプリはバックグラウンドで位置情報を取得している」というダイアログについて、30%のユーザーがクリックし、その内の65%以上のユーザーが位置情報の Permission を変更している事が分かりました。
Android 11 での強化
One-time Permission の追加
位置情報、カメラ、マイクのアクセスについて、パーミッションの許可ダイアログに「1回のみ許可」が追加されます。
ユーザーにどのようなデータが大事か聞いたところ、位置情報、カメラ、マイクに関しては、（アプリにデータを共有するのを）非常に気を遣う、という事が分かってきたため。
One-time Permissionへの対応について、開発者側での（今までの実装からの）変更は、基本的に必要ありません。
Foreground access と Background access の分離の必須化
Android 10 で、位置情報の Permission が以下のように Foreground access と Background access に分かれました。
Android 10 ではこれらの対応は必須ではありませんでしたが、 Android 11 からは必須になります。
Foreground access(アプリがフォアグラウンドの時 or Foreground Service の利用)
- ACCESS_COARSE_LOCATION
- ACCESS_FINE_LOCATION
Background access（WorkManager や AlarmManager の利用によるバックグラウンドアクセス）
- ACCESS_BACKGROUND_LOCATION
バックグラウンドでの位置情報の許可について
Android 10 では、フォアグラウンドの位置情報のアクセス要求と、バックグラウンドの位置情報のアクセス要求を同時に行う事が出来ました。
ですが、Android 11 からは、この2つの権限を同時に要求する事が出来なくなりました。
※フォアグラウンドのアクセス許可は「アプリの使用中のみ許可 / 今回のみ許可 / 許可しない」という選択肢になる。
その後、アプリ内でバックグラウンドで位置情報を取得する事をユーザーに説明した上で、設定画面にリダイレクトする。そこからユーザー自身の手で「アプリに位置情報の利用を許可する」を設定してもらう。
Rate limit
ユーザーがアクセス権限を拒否した場合、許可を貰うまで確認ダイアログを出し続けるアプリは良くありますが、それが出来なくなります。
2回拒否した場合、アクセス権限の確認画面はもう出なくなります。
このため、位置情報へのアクセスが無くても、アプリが動くように作っていただく必要があります。
位置情報が必須の場合は、なぜ位置情報の取得が必要なのかをユーザーにちゃんと説明してあげてください。
Geo-fencing
Geo-fencingとは：ユーザーが特定のエリアに入った時に処理を行う機能。 この機能を利用するには、位置情報のバックグラウンドでの取得が必要になります。
New Foreground Service Types
Android 10 で Foreground Service Type が導入されましたが、新しい Service として、カメラとマイクが追加されました。
<manifest>
<service ... android:foregroundServiceType="camera|microphone" />
</manifest>Package Visibility
他のアプリの情報取得の制限について
今まではPackageManagerを利用することにより、アプリに入っている他のアプリの情報を取得する事が出来ました。
しかし、全てのアプリの情報を取得できる事はプライバシー上の問題があるため、Manifestの <queries> に書かれたアプリのみ、情報を取得できるように修正しました。
現状： packageManager.getInstalledPackages(0) によって、端末上にインストールされているアプリの情報が取得できる。 使われ方としては、
- 自社アプリのインストールを促すマーケティング目的
- アプリケーション機能の一部として、他アプリの機能を利用する場合（カメラなど）
変更が無い点：
getPackageInfo(getPakageName(), 0)で自分自身のアプリ情報を取る事は従来通り可能getPackageInfo(0)で自身と system packages の情報が返ってくるのも従来通り- Implicit intent の振る舞いも変わらない（
IMAGE_CAPTUREなど） - ContentsProvider などを利用して自身のアプリから結果を他アプリに送っている場合も振る舞いは変わらない
変更点：
getPackageInfo("{他アプリのパッケージ名}", 0)を指定すると、インストールの有無に関わらずNameNotFoundExceptionが返ってくる
ただし、以下のようにManifestに明示的にパッケージ名（サービス名）を記述する事で、情報を取得可能になる
<manifest>
<queries>
<package android:name="com.example.store" />
<package android:name="com.example.service" />
</queries>
...
</manifest>intent-filterの書き方を利用して条件を指定することも可能。
用例2「アプリケーション機能の一部として、他アプリの機能を利用する場合」に使用できる。
<manifest>
<queries>
<intent>
<action android:name="android.intent.action.SEND" />
<data android:mimeType="image/jpeg" />
</intent>
</queries>
...
</manifest>実は、従来通り、全てのアプリの情報を取得することもできます。 ただし、特別な Permission をユーザーから取得する必要があります。
<uses-permission android:name="android.permission.QUERY_ALL_PACKAGES">この Permission についてはいずれガイドラインが策定され、公開される予定です。
Other Important Changes
MAC アドレスの新しい制限について
MAC アドレスの取得制限
Android 6–10 までは、ローカルの MAC アドレスを取得した場合、固定値が返されました。
他の端末の MAC アドレスを取得する場合は、毎回ランダムな値が返されました。
Android 11 では、システムアプリでは無い場合、MAC アドレスの取得が不可能になりました。
具体的には、
NetworkInterface#getHardwareAddressは常に null を返します。- C言語側から
getifaddrs()を呼んでも、Android 11 側からは MAC アドレスを返しません。 - NetLinkを利用している場合、
RTM_GETLINKリクエストはブロックされます。
Network Interfaces
Network Interface のリストを取得しようとした場合、今までは全てのNetwork Interface が返されました。
Android 11 からは、IPv4 のアドレスが設定されている Network Interface のみ返されます。
NetLink
NetLink を利用されている方は、 NETLINK_ROUTE のソケットには bind() 関数を呼び出す事が不可能になります。
System Alert Window の変更点
System Alert Window つまり全てのウィンドウより優先度が高い画面を表示するためには、ユーザーの許可が必要となります。
ユーザーに設定画面を開いて頂き、対象アプリを選択し、有効にしていただく必要があります。
質疑応答
Q: ユーザーが Android 10 から Android 11 にアップグレードした場合、 Android 10 で得られていたアプリ内の Permission は、 Android 11 では再度、要求し直しになるのでしょうか？
A: 再度要求される事はないです。
Q: Only-this-timeで許可された状態は、アプリのプロセスが生きている間、保持されるのでしょうか。それとも、Activityなど、別のスコープで許可されている状態が保持されるのでしょうか。
A: プロセスの状態とは対応していません。Activityのライフサイクルと対応していると思っていただければ分かりやすいと思いますが、（バックグラウンドに行った時にすぐ権限が消えてしまわないよう）いくつかの猶予期間が用意されているとは聞いています。猶予期間の具体的な内容は分かりません。
Q: （rate limitについて） 2回のカウントはいつクリアされますか。
A: クリアされません。
Q: 位置情報取得で、while-using-the-appを選択すると、アプリがバックグラウンドに移行した時に位置情報が取得できなくなるのでしょうか。
例えばカーナビアプリなどで、while-using-the-appでアプリを動かしている時、カーナビアプリから音楽アプリに移った時に、カーナビアプリは位置情報を取得できなくなるのでしょうか。
A: Foreground Serviceを使っていただければ位置情報は取得できると思います。
Q: One-time Permission は、カメラ、マイク、位置情報の3つのみに導入されるのでしょうか。
A: そうです。
Q: Bluetooth LE のスキャンにも位置情報パーミッションが必要ですが、One-time Permission や background 制限は Bluetooth LE にも影響しますか？
Bluetooth LE は Beacon や 落とし物タグで使われたりと、長時間スキャンし続けるユースケースが多いので、 background 制限が厳しくなると使いづらくなるかもしれません。
A: 事前のフィードバックでも同様のご意見は頂戴していて、問題は認識してます。ワークアラウンドを提供したいと考えています。
Q: MAC アドレスのランダム化については、アプリだけでなく、 Wi-Fi アクセスポイントへの接続に MAC アドレスフィルタリングを使っている環境についても、多大な影響を及ぼしそうですね。
A: MAC アドレスがランダム化されるのは、APIのレベルでのみという認識です。
API から MAC アドレスを取得しようとすると、MAC アドレスは毎回ランダムになりますが、端末の外に向けては MAC アドレスは変わっていません。ネットワーク・LAN環境内では実際の MAC アドレスが使われていますので問題ありません。ご安心ください。
Q: 得られた Permission が Only-this-time だったかどうかをコード上で調べる事はできないのでしょうか。
A： できません。
Q: バックグラウンドで2回戻した（2回アクセス権限を拒否した）時にユーザーは（Permissionを）取得したい時に許可する導線はあるのでしょうか？
A: ユーザーが設定アプリから権限を許可していただく事になると思います。
Q: rate limit ができて「今後表示しない」のチェックは無くなるのでしょうか？
A: まだ確定していません。
Q: MAC アドレスの取得は端末をユニークに特定するのに使用しているアプリが多いと思うのですが、このような目的の API は用意されますでしょうか？
A: ユースケースによりいくつかの API があります。 “Android Device ID” もしくは “Advertising ID” で検索してください。
Q: Android Enterprise で DPC(Device Policy Controller)は System Alert Window を出さずしてすべてを取得する事はできないのか？
A: わかりません。
Q: パーミッションダイアログの Rate Limit はアプリプロセスと同じスコープですか？それともインストールスコープでしょうか？ また拒否により Rate Limit にヒットした後、ユーザーが自分から許可できるような画面への導線取得 API は提供されますか？
A: インストールスコープです。設定画面での切り替えになるので、ユーザーにそちらに遷移して頂き、自分で設定いただく形になります。
Q: Android 11 からは、カメラの撮影で位置情報がONになっていても権限を許可していなければ、 GPS metadata は付与されないのでしょうか？
A: GPSがONになっている状態で権限をOFFにしていると metadata は付与されません。また、カメラを使う時に位置情報を付与するかどうか確認が出ます。
Q: （権限で）今回だけ、を選んだ場合、もう当該画面に遷移した場合には、またパーミッションダイアログが出るだけ。つまり、アプリ側での実装対応は必要ない。という理解であっていますでしょうか？
A: 必要ありません。（Google でベストプラクティスと説明している実装で実装されているのであれば、という前提）
Q: 音楽アプリがフォアグラウンドに来てもカーナビアプリがフォアグラウンドの権限で動き続ける事ができるように聞こえました。バックグラウンドでの権限が必要なのでは？
A: フォアグラウンドのアプリ、とフォアグラウンドの Service 、は分けて考えて頂く必要があり、僕が先ほど申し上げたのは Service の話です。
Service には2種類あり、Foreground Service と Background Service があります。 アプリがバックグラウンドに移行しても、 Foreground Service は Service として (これまでどおり) Foreground で動く事が可能です。
Q: OSのパーミッションを表示する際にアプリ側でテキストが指定できるように出来ないのでしょうか。一度拒否された際に後出しするよりUXが高いと思います。
A: （現状は出来ませんが）良いフィードバックだと思います。ありがとうございます。
Q: MAC アドレスの取得制限には、ローカルの Bluetooth デバイスアドレスも含まれますか？
A: わかりません。
Q: 全てのアプリ情報が欲しいユースケースの人なんですが、 REQUEST_INSTALL_PACKAGES Permission でも PackageInfo の取得が出来なくなるという事ですか？自アプリが Installer になっていても情報が引けないという事でしょうか？
A: まず、どのような使われ方をするのか興味がありますので是非ご連絡ください。
セッションの最後の方で申し上げましたが、全てのアプリ情報を取得する Permission があります。それを使っていただければ取れます。
Q: Android 11 の、Pixel端末へのOTAアップデートはいつ頃の予定でしょうか？ Android 11 リリースに向けて、 Chrome OS 上での Android 情報にアップデートはありますか？
A: 1つ目。Q3(7月〜9月)の後ろの方、9月付近になると予測しています。 Android のソースコードが固まった、早い段階でPixel端末へのOTA配信が始まります。
2つ目。 Chrome OS への直接の影響は無いと思います。
以上となります。
