Android Oの挙動の変更点 抄訳と共にポイントをまとめてみた (全API level targetでの変更点編)

Android O Behavior Changes

Android Oの挙動の変更点についての説明ページが出てきたので、
抄訳と共にポイントをまとめてみた。

Oをtargetにするアプリでの挙動変更編はこちらです。

Most of these changes affect all apps, regardless of what version of Android they target. However, several changes only affect apps targeting Android O. To maximize clarity, this page is divided into two sections: Apps targeting all API levels and Apps targeting Android O.

抄訳(+補足):
これらの多くの変更は、Android OをtargetSdkVersionにする・しないに限らず、全てのアプリに影響がある。
しかしながら、幾つかの変更はtargetSdkVersionをOにしたアプリだけに影響するものもある。
クリアに説明するために、このページは2つのsectionにわけて説明する。
すなわち、全API levelに影響するものと、OにtargetSdkversionを設定するものの２つにわけて説明する。

targetが全APIレベルに影響のあるアプリ (Apps targeting all API levels)

These behavior changes apply to all apps when they run on the Android O platform, regardless of the API level that they are targeting. All developers should review these changes and modify their apps to support them properly, where applicable to the app.

抄訳(+補足):
これらの挙動変更は、target API levelによらず、Anroid O platformで動かす全アプリに影響のあるものです。
全ての開発者はこれらの変更をreviewし、あなたのアプリに適用可能なものは適切に本挙動変更をサポートするように変更してください。

バックグラウンド実行の制限 (Background execution limits)

As one of the changes that Android O introduces to improve battery life, when your app enters the cached state, with no active components, the system releases any wakelocks that the app holds.

抄訳(+補足):
バッテリーライフを向上させるために導入されるAndroid Oの変更の１つで、アプリがcached状態に入り、activeなコンポーネントがない(foregroundのactivityやserviceがないの意と思われる)ならば、システムはそのアプリが保持しているwakelockを開放するというものです。(結果、systemはsleepする)。

• 対象: (partial) wakelockを確保するbackground serviceなど
• 確認・対策: wakelockが解放される＝基本的に継続的に裏で動くことが許されないということなので、JobSchedulerで定期的な実行に切り替えるなどを検討すること

backgroundでの位置情報に関する制限 (Android background location limits)

In order to preserve battery, user experience, and system health, background apps receive location updates less frequently when used on a device running Android O. This behavior change affects all apps that receive location updates, including Google Play services.

抄訳(+補足):
バッテリー、ユーザー体験、システムの健康保全のため、Android Oが動作するデバイスでは、backgroundのアプリは、位置情報の更新通知頻度が少なくなります。
この変更は、Google Play serviceを含む全ての位置情報更新通知を受けるアプリに影響します。
(Android素APIのlocation manager経由のものだけでなく、Google Playのfused location provider等でもという意味かと思います)

These changes affect the following APIs:

• Fused Location Provider (FLP)
• Geofencing
• GNSS Measurements
• Location Manager

抄訳:略

• 対象: 位置情報を取得し、snapshotではなく、継続して位置をログするようなアプリ
• 確認・対策: 位置ログ的なアプリは、精度の検証が必要。システムが通知してくれる頻度と自分のアプリが求める頻度がマッチしているのか？後述のFused Location Providerへの移行も検討 (LocationManagerを直接使っている場合。また、頻度を低めるために、同じ位置にいるかどうかをシステム側で確認してくれるGeoFence APIの利用も検討)

Android O also includes the following changes to specific methods:

• The NotificationManager.startServiceInForeground() method starts a foreground service. The old way to start a foreground service no longer works.
• The startService() method now throws an IllegalStateException if an app targeting Android O tries to use that method in a situation where the service will be restricted.

抄訳:

Android Oは、以下の特定のmethodでの変更も含みます：

• NotificationManager.startServiceInForeground() methodで、foreground serviceを開始するようになります。過去のforeground serviceを開始する方法は動作しなくなります。

• startService() methodは アプリがAndroid O向けであり、該当サービスが制限される状況下で呼ぶとIllegalStateException を発行するようになります。

• 対象: startService()を使っているアプリ

• 確認・対策: startServiceInForeground を使いましょう

To ensure that your app runs as expected, complete the following steps:

• Review your app's logic and ensure that you're using the latest location APIs.
• Test that your app exhibits the behavior that you expect for each use case.
• Consider using the Fused Location Provider (FLP) or geofencing to handle the use cases that depend on the user's current location.
  For more information about these changes, see Background Location Limits.

抄訳:
あなたのアプリを期待どおりに動かすために、以下の手順を踏んでください：

• アプリケーションのロジックをreviewし、最新の位置情報APIをあなたのアプリを使っていることを確認してください。
• アプリケーションの各ユースケースで期待した挙動をしているかどうかをtestしてください。
• 現在位置に依存したユースケースの処理に、Fused Location Providerかgeogencingの利用を検討してください。
  詳細は、バッググラウンドでの位置情報に関する制限参照のこと。

補足:
FLPは、バッテリー消費量を考慮し、かつ、高精度な位置情報の提供を可能としていますし、その位置にいるか、別の位置に移動したか？は、geo fencingで、対応可能で、独自で個々のアプリがロジックを組むよりも、Google Playの実装を皆で利用するほうが、バッテリー消費の観点でより良い結果が得られるので推奨していると思われる。

Bluetooth

Android O makes the following changes to the length of the data that the ScanRecord.getBytes() method retrieves:

• The getBytes() method makes no assumptions as to the number of bytes received. Therefore, apps should not rely on any minimum or maximum number of bytes returned. Instead, they should evaluate the length of the resulting array.
• Bluetooth 5-compatible devices may return data length exceeding the previous maximum of ~60 bytes.
• If a remote device does not provide a scan response, fewer than 60 bytes may be returned as well.

抄訳:

Android Oでは、 ScanRecord.getBytes() methodでのdata取得の長さに関して、以下の変更があります。

• getBytes() methodは、受信できるバイトの長さに仮定がありません。それ故、アプリは戻り値に関して、最小サイズ・最大サイズを信用してはなりません。代わりに、結果のarrayの長さを評価すべきです。

• Bluetooth 5互換デバイスは、以前の最大値である60 bytesまでを超える長さのdataを返すかもしれません。

• リモートデバイスがscanのresponseを返さないときは、60byte未満を返すかもしれません。

• 対象: ScanRecord.getBytes()を使っているアプリ

• 確認・対策: getBytes()の戻り値のarrayのlengthを確認。

入力デバイスとナビゲーション (Input and navigation)

With the advent of Android apps on Chrome OS and other large form factors, such as tablets, we're seeing a resurgence of keyboard navigation use within Android apps. Within Android O, we've re-addressed using the keyboard as a navigation input device, resulting in a more reliable, predictable model for arrow- and tab-based navigation.
To learn how to improve support for keyboard navigation within your app, read the Supporting Keyboard Navigation guide.

抄訳(+補足):
Chrome OS上でのAndroidアプリケーションサポートや大きなフォームファクターの出現により、Androidアプリケーションにおいて、キーボードナビゲーションの活用の復活の兆しがある。Android Oにおいては、ナビゲーションインプットデバイスとしてキーボードの利用について再対処し、より信頼性が向上し、カーソルやタブベースのナビゲーションに対して、よりpredictable(わかりやすいの意)になります。

アプリにおけるキーボードナビゲーションサポートの改善に関する詳細は、キーボードナビゲーションサポートガイド参照のこと。

• 対象: カスタムviewを使っているアプリ
• 対策: 上に従ってkeyboard navigationに対応する、あるいは、標準のUI componentを利用する

アクセシビリィ (Accessibility)

Accessibility services are now aware of all ClickableSpan instances within your app's TextView objects.
To learn more about how to make your app more accessible, see Accessibility.

抄訳:
アクセシビリィサービスは、あなたのアプリのTextView オブジェクトにおいて、ClickableSpan のインスタンスを知るようになります。
よりよいアクセシビリティサポート手法に関しては、アクセシビリティ参照のこと。

Security

Android O includes the following security-related changes:

• The platform no longer supports SSLv3.
• When establishing an HTTPS connection to a server that incorrectly implements TLS protocol-version negotiation, HttpsURLConnection no longer attempts the workaround of falling back to earlier TLS protocol versions and retrying.
• Android O applies a Secure Computing (SECCOMP) filter to all apps. The list of allowed syscalls is restricted to those exposed through bionic. Although there are several other syscalls provided for backwards compatibility, we recommend against their use.
• Your app's WebView objects now run in multiprocess mode. Web content is handled in a separate, isolated process from the containing app's process for enhanced security.
• For information about security enhancements related to use of native libraries, see Native Libraries.
  For additional guidelines on making your app more secure, see Security for Android Developers.

抄訳(+補足):
Android Oは、以下のsecurityに関する変更があります。

• SSLv3サポートの削除
• 間違ったTLSプロトコルバージョンのネゴシエーションが実装されたHTTPS接続において、HttpsURLConnection は、古いTLSプロトコルバージョンへのフォールバック再試行をしなくなります。
• Android Oでは、Secure Computing (SECCOMP) filterが全てのアプリに適用されます。 bionicを通して公開されているsyscall (system call)に限定して利用が可能です。バックワードコンパチビリティのために、幾つかのsyscallが提供されていますが、それは非推奨です。
• WebView オブジェクトは、マルチプロセスモードで動作します (これまでdeveloper optionでmulti processを有効にしない限りそうではなかった)。ウェブコンテンツは、アプリケーションのプロセスからプロセスが分離されて動作するので、セキュリティが向上します。
• ネイティブライブラリに関して、セキュリティ強化のための変更がありますので参照のこと.
  他、アプリのセキュリティ強化ガイドラインに関しては、Android開発者向けセキュリティを参照のこと。

確認ポイント:

• SSLv3に依存したサービスへのアクセスがないか?
• サービス側のOpenSSLなどのライブラリで古いものはないか?
• bionicで用意されているsystem callだけに依存しているか?
• 利用するnative libraryがwritable/executableなsectionを含んでいないか?

Privacy

Android O makes the following privacy-related changes to the platform.

• The platform now handles identifiers differently.
  • Values of ANDROID_ID are now scoped per-app instead of per-user. The value of ANDROID_ID is unique for each combination of application package name, signature, user, and device. Two apps running on the same device no longer see the same Android ID, and so cannot correlate.
  • The value of ANDROID_ID does not change on package uninstall or reinstall, as long as the package name and signing key are the same.
  • The value of ANDROID_ID does not change if the package signing key changes due to an update.

Widevine ID is scoped per app.
For apps that were installed prior to the OTA, the value of ANDROID_ID remains the same unless uninstalled and then reinstalled.
If you wish to continue using Android ID for device-bound free trial protection, you can do so. Make sure that the package name and signature match.
For a simple, standard system to monetize apps, use Advertising ID. Advertising ID is a unique, user-resettable ID for advertising, provided by Google Play services.

• Querying the net.hostname system property produces a null result.
• You can no longer assume that APKs reside in directories whose names end in -1 or -2. Apps should use sourceDir to get the directory, and not rely on the directory format directly.

抄訳:
Android Oでは、以下のプライバシー関連の変更があります。

• Android Oプラットフォームは、identifiers (識別子(ID))を異なったものとして扱います。
  • ANDROID_ID の値は、アプリ毎、ユーザー毎に管理されるようになります。ANDROID_ID は、パッケージ名、アプリ署名、ユーザー、デバイス毎にユニークになります。同じデバイスで２つのアプリが動作する時、もう同じANDROID_IDの値ではなく、紐付けはできなくなります。
  • ANDROID_ID の値は、アプリ署名が同じであれば、アンインストール・再インストールで変わりません。
  • ANDROID_ID の値は、アップデートにおいて、署名が変わったとしても、変わりません。
  • Widevine IDは、アプリ毎に管理されます。

OTA前にインストールされたアプリに関しては、ANDROID_ID の値は、アンインストールしても、再インストールしても(OTA前と)同じ値がとれます。
もし、あなたがANDROID_IDを、デバイス単位でのフリートライアル保護に使いたければ、使えます。ただし、同じパッケージ名とアプリ署名が一致するようにしてください。

シンプルにするため、アプリのマネタイズのためには、Advertising ID を使ってください。Advertising IDは、Google Play serviceから提供される広告のためのIDで、ユニーク、かつ、ユーザーがリセット可能なものです。

• net.hostname のシステムプロパティーは、常にnullが返されます。
• -1か-2などが末尾のdirectoryにapkが置かれることを仮定することはできません。(これまで/data/0/app/packagename-1みたいなところにはいっていました). アプリは、sourceDirを利用してパスを取得し、直接末尾-1とかのディレクトリーにあると思わないでください。(apkのバックアップアプリ対策か?)

確認ポイント:

• ANDROID_ID を利用しているアプリで、複数apkにわかれている場合で、そのapk間のデータにおいて、 ANDROID_ID の値をキーに紐付けを行っているケース
  --> ユーザーアカウントをキーにするなど、こういうIDへの依存をやめる。

• net.hostname を使わない。

ネットワークとHTTPの接続性 (Networking and HTTP(S) connectivity)

長いの逐次対抄訳します。

Android O includes the following behavior changes to networking and HTTP(S) connectivity:

抄訳:Android Oは、以下のnetworkとHTTP(S)の接続性に関する挙動変更があります。

• OPTIONS requests with no body have a Content-Length: 0 header. Previously they had no Content-Length header.

抄訳: bodyなしのリクエストは、Content-Length: 0 のheaderが付きます。これまで、Content-Lengthのheaderがありませんでした。

• HttpURLConnection normalizes URLs containing empty paths by appending a slash after the host or authority name with a slash. For example, it converts http://example.com to http://example.com/.

抄訳: HttpURLConnection は、hostや/を伴うauthority名の後に、/を追加することによって、URLを正規化します。なお、これは、空pathのケースも含みます。例としては、http://example.com は http://example.com/ に正規化されます。

• A custom proxy selector set via ProxySelector.setDefault() only targets the address (scheme, host and port) of a requested URL. As a result, proxy selection may only be based on those values. A URL passed to a custom proxy selector does not include the requested URL’s path, query parameters, or fragments.

抄訳: ProxySelector.setDefault()経由でのカスタムプロキシーセレクターは、リクエストされたURLのアドレスだけに限定されます。結果、プロキシーの選択は、これらの値を元にだけになるかもしれません。カスタムプロキシーセレクターに渡されるURLは、そのリクエストされたURLのパスや、query parameterや、フラグメントを含みません。

• URIs cannot contain empty labels.
  Previously, the platform supported a workaround to accept empty labels in host names, which is an illegal use of URIs. This workaround was for compatibility with older libcore releases. Developers using the API incorrectly would see an ADB message: "URI example..com has empty labels in the hostname. This is malformed and will not be accepted in future Android releases." Android O removes this workaround; the system returns null for malformed URIs.

抄訳:

• URIは空のラベルを含まない。
  以前は、本来はURIの御作法違反である空のラベルをワークアラウンドとして許容していました。このワークアラウンドは、古いlibcoreのリリースと互換の為でした。"URI example..com has empty labels in the hostname. This is malformed and will not be accepted in future Android releases.というADBメッセージが出ていたら、不適切にそのAPIを利用しているということです。Android Oではこのワークアラウンドが削除されますので、systemからは、そういう不正なURIに対し、nullを返すようになります。

• Android O’s implementation of HttpsURLConnection does not perform insecure TLS/SSL protocol version fallback.

抄訳: Android OでのHttpsURLConnectionの実装は、TLS/SSLプロトコルのフォールバックを実施しません。

• Handling of tunneling HTTP(S) connections has changed as follows:
  • When tunneling HTTPS connection over connection, the system correctly places the port number (:443) in the Host line when sending this information to an intermediate server. Previously, the port number only occurred in the CONNECT line.
  • The system no longer sends user-agent and proxy-authorization headers from a tunneled request to the proxy server.
    The system no longer sends a proxy-authorization header on a tunneled Http(s)URLConnection to the proxy when setting up the tunnel. Instead, the system generates a proxy-authorization header, and sends it to the proxy when that proxy sends HTTP 407 in response to the initial request.
    Similarly, the system no longer copies the user-agent header from the tunneled request to the proxy request that sets up the tunnel. Instead, the library generates a user-agent header for that request.

抄訳:

• トンネルHTTP(S)接続処理に関する以下の変更があります。
  • トンネルHTTP(S)接続では、中間サーバーに対しては、システムは正規のポート番号(443)で、情報を送信します。以前は、そのポート番号はそのCONNECTラインでのみ発生していました。
  • システムは、トンネルのリクエストから、プロキシーサーバーに、user-agentやproxy-authorizationヘッダーを送りません。
    システムは、トンネルが設定されると、トンネルのHttp(s)URLConnectionからプロキシーに対し、proxy-authorizationヘッダーを送りません。代わりに、初回のリクエストの応答で、HTTP 407をプロキシーが送る時に、システムは、proxy-authorizationヘッダーを生成し、それをそのproxyに送ります。
    似た話ですが、トンネルリクエストから、トンネルが設定されたプロキシーリクエストでは、システムは、user-agentをコピーしません。代わりに、そのライブラリーはそのリクエストからuser-agentヘッダーを生成します。

• The send(java.net.DatagramPacket) method throws a SocketException if the previously executed connect() method failed.
  • DatagramSocket.connect() sets a pendingSocketException if there is an internal error. Prior to Android O, a subsequent recv() call threw a SocketException even though a send() call would have succeeded. For consistency, both calls now throw a SocketException.

抄訳:

• もし、以前実行された connect() メソッドが失敗すると、java.net.DatagramPacketによる送信は、SocketException例外を投げます。
  • もし、内部エラーが起きると、DatagramSocket.connect()は、 pendingSocketException を設定します。Android Oより前では、 たとえ send() 呼び出しが成功したとしても、それに続くrecv() の呼び出しは、SocketException を投げていました。一貫性維持のため、両方の呼び出しは、 SocketException を投げるように変わります。

• InetAddress.isReachable() attempts ICMP before falling back to TCP Echo protocol.
  • Some hosts that block port 7 (TCP Echo), such as google.com, may now become reachable if they accept ICMP Echo protocol.
  • For truly unreachable hosts, this change means that twice the amount of time is spent before the call returns.

抄訳:

• InetAddress.isReachable() は、TCPエコープロトコルのフォールバックより前に、ICMPを試みます。
  • この変更は、google.comのようなTCPエコーのポート(ポート7)をブロックしているが、ICMPエコープロトコルは許可しているホストの為のものです。
  • 全く到達不可能なホストに関しては、この変更は、戻り値が戻るまで、2倍の時間掛かるようになります。

キャッチしていない例外に関するログ (Logging of uncaught exceptions)

If an app installs a Thread.UncaughtExceptionHandler that does not call through to the default Thread.UncaughtExceptionHandler, the system does not kill the app when an uncaught exception occurs. Starting from Android O, the system logs the exception stacktrace in this situation; in earlier versions of the platform, the system would not have logged the exception stacktrace.

We recommend that custom Thread.UncaughtExceptionHandler implementations always call through to the default handler; apps that follow this recommendation are unaffected by the change in Android O.

抄訳:
アプリが、Thread.UncaughtExceptionHandlerをinstallしていて、それがdefaultのThread.UncaughtExceptionHandlerを呼び出していない場合、systemは、例外がキャッチされていないときであっても、killしません。Android Oからは、システムは、例外のスタックトレースをログします。以前のバージョンでは、システムは例外のstacktraceをログしませんでした。

推奨としては、カスタムなThread.UncaughtExceptionHandlerは、常にdefaultのハンドラーを呼び出すことです。この推奨に従うアプリは、このAndroid Oでの変更の影響を受けません。

• 対象: Thread.UncaughtExceptionHandler を利用するアプリ
• 対策: defaultのThread.UncaughtExceptionHandlerを呼び出す。
• 確認: logに出てはいけないstack traceがないかを確認する。

コレクションの処理 (Collection handling)

AbstractCollection.removeAll() and AbstractCollection.retainAll() now always throw a NullPointerException; previously, the NullPointerException was not thrown when the collection was empty. This change makes the behavior consistent with the documentation.

抄訳:
AbstractCollection.removeAll() と AbstractCollection.retainAll() は、常に NullPointerException を投げるようになります。

以前は、そのコレクションが空でも NullPointerException を投げませんでした。この変更はドキュメントとの整合性を保つためにもたらされます。

ローケールと国際対応 (Locales and internationalization)

長いの逐次対抄訳します。

Android 7.0 (API level 24) introduced the concept of being able to specify a default Category Locale, but some APIs continued to use the generic Locale.getDefault() method, without arguments, when they should have instead used default DISPLAY category Locale. In Android O, the following methods now use Locale.getDefault(Category.DISPLAY) instead of Locale.getDefault():

抄訳: Android 7.0 (API level 24)では、デフォルトのカテゴリローケールの指定ができる概念が導入されましたが、いくつかのAPIでLocale.getDefaultが引数なしで継続利用されていました(本来はCategory.DISPLAYを使うべきところ)。Android Oでは、以下のmethodで、Category.DISPLAYを使うようになります。

• Currency.getDisplayName()
• Currency.getSymbol()
• Locale.getDisplayScript()

抄訳略.

Locale.getDisplayScript(Locale) also falls back to Locale.getDefault() when the displayScript value specified for the Locale argument is not available.

抄訳: displayScript の値がそのローケールで利用できない時、 Locale.getDisplayScript(Locale) もまた、Locale.getDefault()にフォールバックされます。

Additional locale and internationalization-related changes are as follows:

抄訳: 追加のローケールと国際対応関係の変更は以下のとおりです。

• Calling Currency.getDisplayName(null) throws a NullPointerException, matching the documented behavior.

抄訳: Currency.getDisplayName(null)の呼び出しは、ドキュメントどおり、NullPointerExceptionを投げるようになります。

• Time zone name parsing has changed. Previously, Android devices used the system clock value sampled at boot time to cache the time zone names used for parsing date times. As a result, parsing could be negatively affected if the system clock was wrong at boot time or in other, rarer cases.
  Now, in common cases the parsing logic uses ICU and the current system clock value when parsing time zone names. This change provides more correct results, which may differ from earlier Android versions when your app uses classes like SimpleDateFormat.

抄訳: タイムゾーン名のパース処理が変更になります。以前は、Androidデバイスは、起動時にシステムクロックの値を読み取り、datetimeをパースするために、そのタイムゾーンをキャッシュしていました。結果、まれなケースかもしれませんが、起動時にシステムクロックが間違っていた時に、パース処理がマイナスに作用することが有りました。この変更はより正当性を高めることが期待され、あなたのアプリがSimpleDateFormatのようなクラスを使っていると、以前と違った挙動になり得ます。

• Android O updates the version of ICU to version 58.

抄訳: Android OのICUのバージョンが58に更新されます。

コンタクトプロバイダーと利用統計の変更 (Contacts provider usage stats change)

In previous versions of Android, the Contacts Provider component allows developers to get usage data for each contact. This usage data exposes information for each email address and each phone number associated with a contact, including the number of times the contact has been contacted and the last time the contact was contacted. Apps that request the READ_CONTACTS permission can read this data.

抄訳: 以前のAndroidでは、コンタクトプロバイダーを通して、開発者は、個々のコンタクトに対する利用データを取得できました。この利用データは、各Eメールアドレスや各電話番号に紐付いて、なんかそのコンタクトが利用されたか、最後にコンタクトしたのはいつかが提供されていました。アプリはREAD_CONTACTS パーミッションをリクエストしていれば、このデータが読めました。

Apps can still read this data if they request READ_CONTACTS permission. Starting in Android O, queries for usage data return approximations rather than exact values. The Android system maintains the exact values internally, so this change does not affect the auto-complete API.

抄訳: READ_CONTACTS パーミッションをリクエストするアプリは引き続きこのデータを読み出すことができます。Android Oから、利用データに対するクエリは、正確な値ではなく、概算値を返すようになります。Androidシステムは正確な値を内部的には管理します。なおこの変更は、auto-complete APIには影響しません。

This behavior change affects the following query parameters:

• TIMES_CONTACTED
• TIMES_USED
• LAST_TIME_CONTACTED
• LAST_TIME_USED

略

• 対象: READ_CONTACTS パーミッションをリクエストするアプリで上を使っているもの
• 対策: 例えば、TIMES_CONTACTED値がシリアルにincrementされることを期待しない。

アプリショートカット (App shortcuts)

Android O includes the following changes to app shortcuts:

抄訳: Android Oは、アプリショートカットにおいて以下の変更があります。

• The com.android.launcher.action.INSTALL_SHORTCUT broadcast no longer has any effect on your app, because it is now a private, implicit broadcast. Instead, you should create an app shortcut by using the requestPinShortcut() method from the ShortcutManager class.

抄訳: 暗黙的なブロードキャストインテント com.android.launcher.action.INSTALL_SHORTCUT は、プライベートになるので、作用しません。代わりに、ShortcutManager クラスの requestPinShortcut() メソッドを使って、アプリケーションショートカットを作ってください。

• The ACTION_CREATE_SHORTCUT intent can now create app shortcuts that you manage using the ShortcutManager class. This intent can also create legacy launcher shortcuts that don't interact with ShortcutManager. Previously, this intent could create only legacy launcher shortcuts.

抄訳: ACTION_CREATE_SHORTCUTインテントで、ShortcutManagerクラスにより管理されるアプリケーションショートカットを生成できます。このインテントは、ShortcutManager に採用しないレガシーなのランチャーショートカットも作ることができます。以前は、このインテントはレガシーなランチャーショートカットのみ作ることができました。

• Shortcuts created using requestPinShortcut() and shortcuts created in an activity that handles the ACTION_CREATE_SHORTCUT intent are now fully-fledged app shortcuts. As a result, apps can now update them using the methods in ShortcutManager.
  Legacy shortcuts retain their functionality from previous versions of Android, but you must convert them to app shortcuts manually in your app.

抄訳: requestPinShortcut()により作られたショートカットと、ACTION_CREATE_SHORTCUTインテントにより処理されるアクティビティのショートカットは、ちゃんとした(fully-fledgedの意訳)アプリケーションショートカットです。結果、アプリは ShortcutManagerのメソッドを通して、それらの更新ができます。

To learn more about changes to app shortcuts, see the Pinning Shortcuts and Widgets preview feature guide.

抄訳：ピンされたショートカットとウイジットに関する詳細参照のこと。

アラートウインドウ (Alert windows)

If an app uses the SYSTEM_ALERT_WINDOW permission and uses one of the following window types to attempt to display alert windows above other apps and system windows:

抄訳: SYSTEM_ALERT_WINDOW パーミッションを利用するアプリで、以下のウインドウタイプを使って、アラートウインドウを他のアプリやシステムウインドウの上に表示をしたいケースについて

• TYPE_PHONE
• TYPE_PRIORITY_PHONE
• TYPE_SYSTEM_ALERT
• TYPE_SYSTEM_OVERLAY
• TYPE_SYSTEM_ERROR

...then these windows always appear beneath the windows that use the TYPE_APPLICATION_OVERLAY window type. If an app targets Android O, the app uses the TYPE_APPLICATION_OVERLAY window type to display alert windows.

抄訳：これらのウインドウは常に TYPE_APPLICATION_OVERLAY ウインドウタイプを使うウインドウの下に表示されます。Android Oをtargetにするアプリでは、そのアプリは、TYPE_APPLICATION_OVERLAY ウインドウタイプを使うことで、アラートウインドウを表示することができます。

For more information, see the Common window types for alert windows section within the behavior changes for Apps Built Against Android O.

抄訳: Android O向けのアプリのアラートウインドウに対する共通ウインドウタイプセクションを参照のこと。

Android Oにおけるエンタープライズ対応 (Android in the enterprise)

Android O contains changes that affect enterprise apps. If you're building apps for businesses, including DPCs (device policy controllers), you should review the changes described in the Android in the Enterprise page and modify your app accordingly.

抄訳: Android Oでは、エンタープライズ向けのアプリに影響があります。DPC(デバイスポリシーコントローラー)のようなビジネス向けのアプリを作っている場合は、Androidにおけるエンタープライズを参照して適切に変更対応してください。

Oをtargetにするアプリでの挙動変更編に、つづく。