https://developer.android.com/preview/behavior-changes-all
の抄訳です。
＃途中
挙動の変更 : 全アプリ (Behavior changes: all apps)
The Android Q platform includes behavior changes that may affect your app. The following behavior changes apply to all apps when they run on Android Q, regardless of 'targetSdkVersion'. You should test your app and then modify it as needed to support these properly, where applicable.
Android Qプラットフォームは、あなたのアプリに影響を与えるかもしれない挙動の変更を含みます。以下の挙動の変化は targetSdkversion によらず Android Q上で動作するすべてのアプリに適用されるものです。
Make sure to also review the list of behavior changes that only affect apps targeting Android Q.
Android Qをtargetにするアプリにだけ影響する挙動の変更のリストもレビューも行ってください。
Note: In addition to the changes listed on this page, Android Q introduces a large number of changes and restrictions to enhance user privacy. To learn more, see the Privacy page.
Non-SDK interface restrictions
注意：このページの変更のリストに加え、Android Qは、多くの変更や制限を、ユーザーのプライバシーの拡張のために導入します。詳細は、プライバシーのページのNon-Sdkインターフェイスの制限を参照してください。
To help ensure app stability and compatibility, the platform started restricting which non-SDK interfaces your app can use in Android 9 (API level 28). Android Q includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Our goal is to make sure that public alternatives are available before we restrict non-SDK interfaces.
アプリの安定性と互換性の担保のために、プラットフォームは、Android 9 (APIレベル29)上であなたがアプリを動作させるときに、非SDKインターフェイスへの制限を開始しました。Android Qは、Android開発者との協力と最新の内部テストに基づく、更新された非SDKインターフェイスのリストをもちます。私達のゴールは、非SDKインターフェイスの制限よりも前にだいたい公開インターフェイスを用意することです。
If you will not be targeting Android Q, some of these changes might not immediately affect you. However, while you can currently use non-SDK interfaces that are part of the greylist (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.
もしあなたがAndroid QをtargetSdkで指定しなければ、これらの変更のいくつかは、すぐには影響しないかもしれません。しかし、(targetSdkVersionに依存しますが)グレーリスト内の非Sdkインターフェースを現在利用している間は、どの非SDKメソッドやフィールドの利用は、常にあなたのアプリを壊すリスクがあります。
If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.
もしあなたが、あなたのアプリが非SDKインターフェイスの利用をしているのか不確かであれば、あなたはあなたのアプリをテストして見つけることができます。もしあなたのアプリが非SDKインターフェイスに依存しているのであれば、あなたはSDK代替インターフェースへの移行の計画をするのをはじめるべきです。もちろん、いくつかのアプリは、非SDKインターフェイスを正当な利用をしていることは知っています。もし、非SDKインターフェイスが提供している機能に対する代替を見つけることができないならば、新しい公開APIをリクエストすべきです。
To learn more, see Updates to non-SDK interface restrictions in Android Q and see Restrictions on non-SDK interfaces.
詳細は、Android Qでの非SDKインターフェイス制限やその更新を参照してください。
NDK
Android Q includes the following NDK changes.
Android Qは、以下のNDKの変更があります。
Shared objects cannot contain text relocations
共有オブジェクト(訳者:.so)は、text relocation (訳者:コードなどの再配置)を含むことはできません。
Android 6.0 (API level 23) disallowed use of the use of text relocations in shared objects. Code must be loaded as-is, and must not be modified. This change improves app load times and security.
Android 6.0 (API level 23)で、共有オブジェクトでのtext relocationの利用を禁止しました。 コードはそのままの形でloadされるべきで、変更は許されません。この変更は、アプリケーションのロード時間とセキュリティを改善します。
In Android Q Beta 1 and 2, SELinux enforces this restriction on apps targeting Android 8.0 (API level 26) and higher. If such apps continue to use shared objects that contain text relocations, they are at high risk of breaking.
Android Q Beta 1と2では、SELinuxにより、Android 8/0 (API level 26)をtargetにするアプリにおいて、この制限を強制(有効化)します。
Changes to Bionic libraries and dynamic linker paths (bionicライブラリーと動的リンクパスの変更について)
Starting in Android Q, several paths are no longer regular files but symbolic links. Apps that have been relying on the paths being regular files might break:
Android Qからは、いくつかのpathは、もう通常のファイルではなく、symbolic linkになります。
通常のファイルに頼っているアプリは、問題になりえます。
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
/system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
/system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
/system/bin/linker -> /apex/com.android.runtime/bin/linker
These changes apply to the 64-bit variants of the file as well, with lib/ replaced with lib64/.
これらの変更は、64bitのバリアントにも適用され、lib/の代わりにlib64/です。
For compatibility, new symlinks are provided at the old paths, for example /system/lib/libc.so is now a symlink to /apex/com.android.runtime/lib/bionic/libc.so, and so on. So dlopen(“/system/lib/libc.so”) continues to work, but apps will find the difference when they actually try to examine the loaded libraries by reading /proc/self/maps or similar, which is not usual but we’ve found that some apps do that as part of their anti-hacking process. If so, the new /apex/… paths should be added as valid paths for the Bionic files.
互換性のため、新しいsymlinkは、旧パスで提供されます。例えば、 /system/lib/libc.so は、/apex/com.android.runtime/lib/bionic/libc.so へのsymlinkになります。故に、dlopen("/system/lib/libc.so”)は継続して動作しますが、アプリは、/proc/self/mapsなどでロードされているライブラリーを確認すると、異なっていることがわかります。アンチハッキングプロセスなどでこれをしていることがわかっていますが、一般的な話ではありません。もしそういうことをする場合は、/apexのパスを正しいパスとして加えるべです。
System binaries/libraries mapped to execute-only memory (システムのバイナリーやライブラリーは実行のみ可能なメモリーにマップされる)
Starting in Android Q, executable segments of system binaries and libraries are mapped into memory execute-only (non-readable) as a hardening technique against code-reuse attacks. Intentional and unintentional reads into memory segments marked as execute-only will throw a SIGSEGV -- whether from bug, vulnerability, or intentional memory introspection.
You can identify whether a crash was caused by this change by examining the related tombstone file in /data/tombstones/. An execute-only related crash will contain the following abort message:
Cause: execute-only (no-read) memory access error; likely due to data in .text.
To work around this issue, developers may mark execute-only segments as read+execute by calling mprotect(), for example to perform memory inspection. However, we strongly recommend setting it back to execute-only afterwards as this provides better protection for your app and users.
Calls to ptrace are unaffected, so ptrace debugging is not impacted.
Security
Android Q includes the following security change.
Removed execute permission for app home directory
Untrusted apps that target Android Q can no longer invoke exec() on files within the app's home directory. This execution of files from the writable app home directory is a W^X violation. Apps should load only the binary code that's embedded within an app's APK file.
In addition, apps that target Android Q cannot in-memory modify executable code from files which have been dlopen()ed. This includes any shared object (.so) files with text relocations.
Wi-Fi Direct broadcasts
On Android Q, the following broadcasts related to Wi-Fi Direct are no longer sticky:
WIFI_P2P_CONNECTION_CHANGED_ACTION
WIFI_P2P_THIS_DEVICE_CHANGED_ACTION
If your app has relied on receiving these broadcasts at registration because they had been sticky, use the appropriate get() method at initialization to obtain the information instead.
Wi-Fi Aware capabilities
Android Q adds support to ease TCP/UDP Socket creation using Wi-Fi Aware datapaths. To create a TCP/UDP socket connecting to a ServerSocket, the client device needs to know the IPv6 address and port of the server. This previously needed to be communicated out-of-band, such as by using BT or Wi-Fi Aware layer 2 messaging, or discovered in-band using other protocols, such as mDNS. With Android Q, the information can be communicated as part of the network setup.
The server can do either of the following:
Initialize a ServerSocket and either set or obtain the port to be used.
Specify the port information as part of the Wi-Fi Aware network request.
The following code sample shows how to specify port information as part of the network request:
KOTLIN
JAVA
val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
.setPskPassphrase("some-password")
.setPort(ss.localPort)
.build()
val myNetworkRequest = NetworkRequest.Builder()
.addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
.setNetworkSpecifier(ns)
.build()
The client then performs a Wi-Fi Aware network request to obtain the IPv6 and the port supplied by the server:
KOTLIN
JAVA
val callback = object : ConnectivityManager.NetworkCallback() {
override fun onAvailable(network: Network) {
...
}
override fun onLinkPropertiesChanged(network: Network,
linkProperties: LinkProperties) {
...
}
override fun onCapabilitiesChanged(network: Network,
networkCapabilities: NetworkCapabilities) {
...
val ti = networkCapabilities.transportInfo
if (ti is WifiAwareNetworkInfo) {
val peerAddress = ti.peerIpv6Addr
val peerPort = ti.port
}
}
override fun onLost(network: Network) {
...
}
};
connMgr.requestNetwork(networkRequest, callback)
SYSTEM_ALERT_WINDOW on Go devices
Apps running on Android Q (Go edition) devices cannot receive the SYSTEM_ALERT_WINDOW permission. This is because drawing overlay windows uses excessive memory, which is particularly harmful to the performance of low-memory Android devices.
If an app running on a Go edition device running Android 9 or lower receives the SYSTEM_ALERT_WINDOW permission, the app retains the permission even if the device is upgraded to Android Q. However, apps which do not already have that permission cannot be granted it after the device is upgraded.
If an app on a Go device sends an intent with the action ACTION_MANAGE_OVERLAY_PERMISSION, the system automatically denies the request, and takes the user to a Settings screen which says that the permission isn't allowed because it slows the device. If an app on a Go device calls Settings.canDrawOverlays(), the method always returns false. Again, these restrictions do not apply to apps which received the SYSTEM_ALERT_WINDOW permission before the device was upgraded to Q.
Warnings for apps targeting older Android versions
In Android Q, the platform will warn users the first time they run any app that targets a platform version lower than Android 6.0 (API level 23). If the app requires the user to grant permissions, the user is also given an opportunity to adjust the app's permissions before the app is allowed to run for the first time.
Due to Google Play's target API requirements, a user would only see these warnings if they run an app that has not been updated recently. For apps that are distributed through other stores, similar target API requirements are also being introduced in 2019. For more information about these requirements, see Expanding target API level requirements in 2019.
SHA-2 CBC cipher suites removed
The following SHA-2 CBC cipher suites have been removed from the platform:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
These cipher suites are less secure than the similar cipher suites that use GCM, and most servers either support both the GCM and CBC variants of these cipher suites or support neither of them.
Note: Apps and libraries should intersect their desired set of cipher suites with the return value from getSupportedCipherSuites() to future-proof cipher suite selection against future removals.
App usage
Android Q introduces the following behavior changes related to app usage:
UsageStats app usage improvements -- Android Q now accurately tracks app usage with UsageStats when apps are used in split-screen or picture-in-picture mode. Additionally, Android Q can now track instant app usage.
Per-app grayscale -- Android Q can now set apps to a grayscale display mode.
Per-app distraction state -- Android Q can now selectively set apps to a "distraction state" where their notifications are suppressed and they will not appear as suggested apps.
Suspension and playback -- In Android Q, suspended apps are no longer able to play audio.
android.preference library is now deprecated
The android.preference library is now deprecated. Developers should instead use the AndroidX preference library, part of Android Jetpack. For additional resources to aid in migration and development, check out the updated Settings Guide along with our public sample app and reference documentation.
Camera changes
Many camera-using apps assume that if the device is in a portrait configuration, then the physical device is also in the portrait orientation, as described in Camera orientation. This was a safe assumption in the past, but that has changed with the introduction of new form factors, such as foldables. That assumption on these devices can lead to either incorrectly rotated or scaled (or both) display of the camera viewfinder.
Applications that target API level 24 or above should explicitly set android:resizeableActivity and provide necessary functionality to handle multi-window operation.
Battery usage tracking
Beginning with Android Q, SystemHealthManager resets its battery usage statistics whenever the device is unplugged after a major charging event. Broadly speaking, a major charging event is either: The device has been fully charged, or the device has gone from mostly depleted to mostly charged.
Before Android Q, the battery usage statistics reset whenever the device was unplugged, no matter how little change there had been to the battery level.