Android Pでの挙動の変更について

# Overview

https://developer.android.com/preview/behavior-changes.html

にAndroid Pの挙動の変更に関するdocumentが出てきたので、抄訳です。

(まだ全部訳が完了しているわけではありません)

# Android Pでの挙動の変更(Android P Behavior Changes)

## Android Pで動くすべてのアプリ (All apps running on Android P)

> These behavior changes apply to all apps when they run on the Android P 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.

これらの挙動の変更は、どのAPIレベルをtargetにするかによらず、Android Pのプラットフォーム上において、アプリケーションを動かすときに、全てのアプリに適用されるものです。

### バックグラウンド動作時の、Inputとデータのプライバシーについて (Input and data privacy in background apps)

> Android P strengthens privacy by limiting the ability of background apps to access user input and sensor data. If your app is running in the background on a device running Android P, the system applies the following restrictions to your app:

Android Pは、バックグラウンドのアプリについて、ユーザー入力とセンサーデータへのアクセスを制限することで、プライバシーを強化しています。もしあなたのアプリがAndroid Pが動作するデバイスでバッググラウンドで動作するときには、Android Pシステムは、あなたのアプリに対し、以下の制限を適用します：

* あなたのアプリはマイクやカメラへアクセスできません (Your app cannot access the microphone or camera.)
* 加速度センサーやジャイロセンサーなどのセンサーは、継続レポートモードで、イベントの受信ができません。(Sensors that use the continuous reporting mode, such as accelerometers and gyroscopes, don't receive events.)
* センサーは、変化通知やone shot (単一トリガー)モードで、イベントを受信できません
 (Sensors that use the on-change or one-shot reporting modes don't receive events.)

> If your app needs to detect sensor events on devices running Android P, use a foreground service.

もしあなたのアプリが、Android Pで動作するデバイス上で、センサーイベントの検出が必要であれば、foreground serviceを利用してください。

> Note: Apps that call flush() on an instance of SensorManager aren't affected by this change.

注意： センサーマネージャーのインスタンス上で、'''flush()''' を呼び出すアプリは、この変更の影響を受けません。

### デバイスのセキュリティーに関する変更 (Device security changes)

> Devices running Android P provide key rotation and system call protection. These changes enhance app security, no matter what API level your app targets. For more details, see changes to all apps on the Security Behavior Changes page.

Android Pが動作するデバイスは、鍵のrotationとsystem callの保護を提供します。これらの変更は、アプリのtarget APIレベルアプリによらないものであり、セキュリティを強化します。詳細に関しては、[すべてのアプリに対するセキュリティに関する挙動の変更のページ](https://developer.android.com/preview/features/security-behav.html#all-apps)を参照のこと。

### 暗号に関する変更 (Cryptographic changes)

>Android P introduces several changes to the implementation and handling of cryptographic algorithms.

Android Pは、暗号アルゴリズムの処理やその実装に関していくつか変更があります。

#### Conscryptにおける暗号アルゴリズムに関するパラメータ (Conscrypt implementations of parameters and algorithms)

> Android P provides additional implementations of algorithm parameters in Conscrypt. These parameters include: AES, DESEDE, OAEP, and EC. The Bouncy Castle versions of these parameters and many algorithms have been deprecated in Android P.

Android P は、Conscryptで、アルゴリズムのパラメータに関する追加の実装を提供します。これらの追加パラメーターには、AES, DESEDE, OAEP, ECが含まれます。これらのパラメータや多くのアルゴリズムのBouncy Castleバージョンとは、Android Pで、deprecatedになります。

> Note: Conscrypt's implementation of the EC parameter only supports named curves.

注意: Conscryptでは、ECパラメータの実装は、名前付curveだけがサポートされます。

> If your app targets Android 8.1 (API level 27) or lower, you receive a warning when requesting the Bouncy Castle implementation of one of these deprecated algorithms. If you target Android P, however, these requests each throw a NoSuchAlgorithmException.

あなたのアプリがAndroid 8.1 (API level 27)やそれよりも下をtargetにしているならば、Bouncy Castleのそれらのdeprecatedされたアルゴリズム実装をリクエストすると、warningを受け取るでしょう。もし、Android Pをtargetにしているばらば、これらのリクエストは、 '''NoSuchAlgorithmException''' をthrowします。

### その他の変更 (Other changes)

> Android P introduces several other cryptographic changes:

Android Pは、暗号に関して幾つかの他の変更があります。

> * When using PBE keys, if Bouncy Castle is expecting an initialization vector (IV) and your app doesn’t supply one, you receive a warning.
> * The Conscrypt implementation of the ARC4 cipher allows you to specify either ARC4/ECB/NoPadding or ARC4/NONE/NoPadding.
> * The Crypto Java Cryptography Architecture (JCA) provider has been removed. As a result, if your app calls SecureRandom.getInstance("SHA1PRNG", "Crypto"), a NoSuchProviderException occurs.
> * If your app parses RSA keys from buffers that are larger than the key structure, an exception no longer occurs.

* PBE keysを使う上で、Bouncy Castleは、初期ベクターを期待しますが、あなたのアプリがそれを提供しないと、警告が受けるでしょう。
* ARC4暗号に関するConscryptの実装は、ARC4/ECB/NoPaddingだけなく、 ARC4/NONE/NoPaddingをも指定することが許されます。
* Crypto Java Cryptography Architecture (JCA) providerは、削除されました。結果、もし、あなたのアプリが '''SecureRandom.getInstance("SHA1PRNG", "Crypto")''' を呼ぶと、 '''NoSuchProviderException''' が発生します
* もしあなたのアプリが、鍵の構造よりも大きなバッファーからRSAをパースしても、''' exception''' はもう発生しません。

## アプリケーションの互換性の変更 (App compatibility changes)

> To help ensure app stability and compatiblity, the platform restricts the use of some non-SDK methods and fields; these restrictions apply whether you attempt to access these methods and fields directly, via reflection, or using JNI. In Developer Preview 1, your app can continue to access these restricted interfaces; the platform uses toasts and log entries to bring them to your attention. If your app shows such a toast, it is important that you pursue an implementation strategy other than the restricted interface. If you feel that no alternative strategy is feasible, you may file a bug to request reconsideration of the restriction.

アプリの安定性と互換性の確保を助けるために、Android Pは、いくつかのSDK外のメソッドやフィールドに関する利用を制限する。これらの制限は、あなたのアプリが、これらのメソッドやフィールドに直接やreflection経由やJNIを使ってアクセスを試みる家によらず適用されます。開発者プレビュー1においては、あなたのアプリがこれらの制限されたインターフェイスへのアクセスを継続できますが、Android Pは、toastやlogを通して、あなたに注意を促します。もしあなたのアプリ上でそのようなtoastが表示されたら、それらの制限されたインターフェイス以外で実装する戦略を取ることが重要です。もし代替手段（訳者注：SDKの公開APIのみで実現する、の意味）を取れないと感じた場合は、そのインターフェイスに関する制限に関して再検討のリクエストを[bug](https://issuetracker.google.com/issues/new?component=328403&template=1027267)から登録してください。

> Restrictions on Non-SDK Interfaces contains further important information. You should review it to ensure that your app continues to function.

非SDKインターフェイスへの制限は、さらなる重要な情報があります。あなたのアプリが機能し続けられるように、ぜひreviewしてください。


### ICUライブラリに関するアップデート (Updates to the ICU libraries)

> The version of the ICU library used in the platform has been updated from ICU 58, used in Android 8.0 (API level 26) and 8.1 (API level 27), to ICU 60.

Android Pプラットフォーム内のICUライブラリは、Android 8.0 (API level 26)や8.1 (API level 27)で使われていた58から60に更新されました。

> ICU is used to provide public APIs beneath the android.icu package and is used internally in the Android platform for internationalization support. For example, it is used to implement Android classes in java.util, java.text and android.text.format. This release contains many small but useful changes like Emoji 5.0 data support and improved date/time formats, as documented in the ICU 59 and ICU 60 release notes. You should take particular note of the following points:

ICUは、android.icuパッケージとして公開APIとして提供されており、Androidプラットフォーム内部で国際化サポートのために利用されています。たとえば、java.utilやjava.text内や android.textformatの実装として利用されています。このリリースでは、多くの小さな役に立つ変更を含んでいます。たとえば、Emoji 5.0データサポートや改善されたdate/timeのフォーマットです。これらは、ICU 59と60のリリースノートに書かれているものです。以下の点の特記事項について注意してください。

* タイムゾーンの変更に関するプラットフォーム対応について (The way the platform handles time zones has changed.)
  * プラットフォームはGTMやUTCをよりよく対応します。UTCじゃもうGMTの同義語ではありません。この変更により、android.icuのフォーマット処理や、"GMT",
 "Etc/GMT", "UTC", "Etc/UTC"や"Zulu"のパース処理の挙動が影響を受けます。 <br> (The platform handles GTM and UTC better; UTC is no longer a synonym for GMT.
ICU now provides translated zone names for GMT and UTC. This change affects android.icu formatting and parsing behavior for zones like "GMT", "Etc/GMT", "UTC", "Etc/UTC", and "Zulu".)
  * Anroid Pでは、java.text.SimpleDateFormatは、ICUを使って、UTC/GMTに関する表示名を提供します。これの意味するところは、 <br> (java.text.SimpleDateFormat now uses ICU to provide display names for UTC /GMT, meaning:)
         * zzzzに関するformat処理は、多くのローケールにおいて、長いローカライズされたも時列を生成します。以前は、UTCに対しては"UTC"、GMTに対しては、"GMT+00:00"のような文字列を生成していました。 <br> (Formatting zzzz generates a long localized string for many locales. Previously, it produced produced "UTC" for UTC and strings like "GMT+00:00" for GMT).)
         * zzzzのパース処理では、ユニバーサルに調整された時刻として、また、グリーニッジを意味する時刻として処理されます。 <br> (Parsing zzzz recognizes strings like "Universal Coordinated Time", and "Greenwich Mean Time".)
         * "UTC"や"GMT+00:00"は、全ての言語においてzzzzと出力されると仮定しているアプリは互換性の問題が発生するかもしれません。 <br> (Apps may encounter compatibility problems if they assume that "UTC" or "GMT+00:00" are output for zzzz in all languages.)
    * ```java.text.DateFormatSymbols.getZoneStrings()```の挙動の変更について <br> (The behavior of java.text.DateFormatSymbols.getZoneStrings() has changed):　
        * ```SimpleDateFormat```において、UTCとGMTはAndroid Pでは、ロング名を持ちます。UTCゾーンに対するタイムゾーン名のDST変数、例えば、"UTC"やEtc/UTC"や"Zulu"は、名前が有効ではないとき、ハードコードされたUTC文字列としてではなく、標準のフォールバックとしてGMT+00:00になります。 <br> (As with SimpleDateFormat, UTC and GMT now have long names. DST variants of time zone names for the UTC zone, such as "UTC", "Etc/UTC", and "Zulu", become GMT+00:00, which is the standard fallback when there are no names available, rather than the hard-coded string UTC.) 
        * ゾーンIDのいくつかは、他のゾーンの同義語として正常に認識されるため、Androidは、レガシーなゾーンIDの文字列を探索します。それは例えば、Eireのようなものです。なお、これは、以前は探索解決できなかったものです。 <br> (Some zone IDs are correctly recognized as synonyms for other zones, so that Android finds strings for archaic zone IDs, such as Eire, that previously could not be resolved. )
    * Asia/Hanoiは、もう認識されないゾーンです。この理由から```java.util.TimeZones.getAvailableIds()``` は、この値を返しません。そして、``java.util.TimeZone.getTimeZone()``` は、それを認識しません。この挙動は、既存のandroid.icuの挙動と一貫性を持たせたものです。 <br> (Asia/Hanoi is no longer a recognized zone. For this reason ```java.util.TimeZones.getAvailableIds()``` does not return this value, and ``java.util.TimeZone.getTimeZone()``` does not recognize it. This behavior is consistent with the existing android.icu behavior.
 * ```android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String)```メソッドは、正当な通貨のテキストをパースする場合であっても、```ParseException```をスローするかもしれません。この問題の回避には、```PLURALCURRENCYSTYLE-style```の通貨テキストには、```NumberFormat.parseCurrency```を使ってください。これはAndroid 7.0 (API level 24)から有効です。 <br> (The android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) method may throw a ParseException even when parsing legitimate currency text. Avoid this problem by using NumberFormat.parseCurrency, available since Android 7.0 (API level 24), for PLURALCURRENCYSTYLE-style currency text.)

### Androidのセキュア暗号ファイル (ASECs)の非サポート (Android secure encrypted files are no longer supported)

> Android secure encrypted files (ASECs) were originally introduced in Android 2.2 (API level 8) to support the original apps-on-SD-card feature. Android 6.0 (API level 23) replaced and deprecated ASECs, introducing in their place an “adoptable SD card” feature.

Androidセキュア暗号化ファイル (ASECs)は、Android 2.2 (API level 8)で初めて導入され、apps-on-SD-cardとしてのサポートで知られていました。Android 6.0 (API level 23)で、ASECsはdeprecatedになり、「アダプタブルストレージ」が導入され、その機能は代替されました。

> Android 8.0 (API level 26) blocked the ability to install new apps into ASECs. The Developer Preview removes the ASEC functionality completely.

Android 8.0 (API level 26)では、新しいアプリがASECsにinstallされるをブロックするようになりました。開発者プレビューでは、ASECの機能が完全に取り除かれました。

### テストスイートビルダーの変更 (Test suite build changes)

> The addRequirements() method in the TestSuiteBuilder class has been removed, and the TestSuiteBuilder class itself been deprecated. The addRequirements() method had required developers to supply arguments whose types are hidden APIs, making the API invalid.

[TestSuiteBuilder](https://developer.android.com/reference/android/test/suitebuilder/TestSuiteBuilder.html)のクラスの```addRequirements()```メソッドが削除され、TestSuiteBuildクラス自体がdeprecatedになりました。```addRequirements()```メソッドは、開発者に非公開APIのtypeの引数を要求しており、そのAPIを不正にしていました。

### フレームワークからテストのためのライブラリの削除 (Testing libraries removed from framework)

> In Android 8.1 (API level 27) and lower, the Android framework provides several classes, such as ActivityInstrumentationTestCase2, that you can use to create tests in your app. At compile time, these classes are available when building against android.jar. This built-in testing architecture, although convenient, requires you to test against the version of JUnit that android.jar provides, which makes it difficult to build and test dependencies that rely on a different version of JUnit.

Android 8.1 (API level 27)以下では、Android frameworkは、```ActivityInstrumentationTestCase2```のようなクラスを提供しており、あなたのアプリで、testの作成のために利用できます。コンパイル時に、これらのクラスは、android.jarに対して利用可能になります。このビルトインのテストアーキテクチャはandroid.jarが提供するJUnitのバージョンに対してテストすることになり便利ですが、異なるバージョンのJUnitに依存したテストをビルドし、テストするのが困難です。

> To give you more flexibility in building and testing custom or third-party logic, Android P removes test classes from the framework. The testing libraries are still available as optional dependencies, though. The Legacy testing libraries page describes how to use them in Android P.

カスタムまたはサードパーティのロジックを構築してテストする際の柔軟性を高めるため、Android Pはフレームワークからテストクラスを削除します。テストライブラリーはオプショナルな依存としては引き続き利用可能です。[レガシーテストライブラリ](https://developer.android.com/preview/features/legacy-testing-libs.html)のページには、Android P向けの使い方が記述されています。

> To learn more about how to test Android apps, see Testing Apps on Android.

Androidアプリのテストの仕方に関しては、[Android上でのアプリテスト](https://developer.android.com/training/testing/index.html)についてをご参照ください。

### JavaでのUTFデコーダー(Java UTF decoder)

> UTF-8 is the default charset in Android. A UTF-8 byte sequence can be decoded by a String constructor, such as String(byte[] bytes). The UTF-8 decoder is stricter in Android P and follows the Unicode standards, namely:

UTF-8は、Androidのデフォルトのキャラクタセットです。UTF-8のバイトシーケンスは、```String(byte[] bytes)``` のように、Stringのコンストラクタによりデコードできます。

> * The non-shortest form of UTF-8, such as <C0, AF>, is now treated as ill-formed.

* ```<C0, AF>```のような最短形式ではないUTF-8形式は、不正な文法として扱われます。

> * The surrogate form of UTF-8, such as ```U+D800..U+DFFF```, is now treated as ill-formed.

* ```U+D800..U+DFFF``` のようなUTF-8のサロゲート形式は、Android Pでは、不正な文法として扱われます。

> * The maximal subpart is replaced by a single U+FFFD. For example, in the byte sequence "41 C0 AF 41 F4 80 80 41," the maximal subparts are "C0," "AF," and "F4 80 80." "F4 80 80" can be the initial subsequence of "F4 80 80 80", but "C0" can't be the initial subsequence of any well-formed code unit sequence. Thus, the output should be "A\ufffd\ufffdA\ufffdA."

* 単一の```U+FFFD```により、最大のサブパートは置換されます。たとえば、```"41 C0 AF 41 F4 80 80 41,"```のバイトシーケンス中で、最大のサブパートは、```"C0," "AF,"``` と ```"F4 80 80"```になります。```"F4 80 80"``` は、```"F4 80 80 80"```の初期シーケンスになりますが、```"C0"```は、どの文法的に正しいコードユニットシーケンスの初期シーケンスになりません。すなわち、出力は、```"A\ufffd\ufffdA\ufffdA"```になるでしょう。

> * To decode a modified UTF-8 / CESU-8 sequence in Android P, use the DataInputStream.readUTF() method or the NewStringUTF() JNI method.

* Android Pでは、変更されたUTF-8 / CESU-8のデコードのために、```DataInputStream.readUTF()``` メソッドまたは```NewStringUTF()```のJNIメソッドを使います。

### 証明書を用いたホスト名の検証 (Hostname verification using a certificate)

> RFC 2818 describes two methods to match a domain name against a certificate—using the available names within the subjectAltName (SAN) extension, or in the absence of a SAN extension, falling back to the commonName (CN).

RFC 2818では、ドメイン名が、subjectAltName (SAN)エクステンション内の有効な名前を用いて、証明書とマッチするのか、もしくは、SANエクステンション内で、commonName (CN)へフォールバックするのかの2つの方法が記載されています。

> However, the fallback to the CN was deprecated in RFC 2818. For this reason, Android no longer falls back to using the CN. To verify a hostname, the server must present a certificate with a matching SAN. Certificates that don't contain a SAN matching the hostname are no longer trusted.

しかし、そのCNへのフォールバックは、RFC 2818でdeprecatedです. この理由により、Android Pでは、CNを用いたフォールバックをしません。ホスト名の検証には、そのサーバーは、SANにマッチする証明書がなければなりません。SANにマッチするホスト名を持たない証明書は、信用されなくなります。

### ネットワークアドレスのルックアップは、ネットワークの違反になり得る (Network address lookups can cause network violations)

> Network address lookups that require name resolution can involve network I/O and are considered blocking operations. Blocking operations on the main thread can cause pauses or jank.

名前解決を必要とするネットワークアドレスのルックアップは、ネットワークでの入出力を介することがあり、ブロッキング処理として扱われます。メインスレッドでのブロッキング処理は、ポーズあるいはジャンクを発生し得ます。

> The StrictMode class is a development tool that helps developers to detect problems in their code. StrictMode now detects network violations caused by network address lookups that require name resolution.

StrictModeクラスは、開発ツールとして、開発者に問題の検出を助けてくれます。Android Pでは、StrictModeは、名前解決を必要とするネットワークアドレスののルックアップにおいて、ネットワークでの違反としてを検出します。

> Developers should not ship their apps with StrictMode enabled. Otherwise, their apps can experience new exceptions, such as NetworkOnMainThreadException when using the detectNetwork() or detectAll() methods to get a policy that detects network violations.

開発者は、StrictModeを有効にしたまま、出荷すべきではありません。さもなくば、そのアプリは、例えば、```detectNetwork()``` や ```detectAll()```で、networkの違反を検出するポリシーにより、```NetworkOnMainThreadException ```例外を経験することになるでしょう。 

> Resolving a numeric IP address isn't considered a blocking operation. Numeric IP address resolution works the same way as in platform versions lower than Android P.

数字でのIPアドレスの名前解決は、ブロッキング処理として扱われません。数字でのIPアドレスの名前解決は、Android Pよりも低いバージョンと同じように扱われます。

### ソケットのタグ付け (Socket tagging)

> In platform versions lower than Android P, if a socket is tagged using the setThreadStatsTag() method, the socket is untagged when it's sent to another process using binder IPC with a ParcelFileDescriptor container.

Android Pよりも古いバージョンでは、ソケットは、```setThreadStatsTag()``` メソッドを使うことによりタグづけられても、binder IPCの ```ParcelFileDescriptor``` コンテナで別のプロセスに送られると、そのソケットは、タグ付けが外れています。

> Starting in Android P, the socket tag is kept when it’s is sent to another process using binder IPC. This change can affect network traffic statistics, for example, when using the queryDetailsForUidTag() method. You can keep the previous behavior by calling the untagSocket() before sending the socket to another process.

Android Pからは、別のプロセスへbinder IPCで送られても、そのソケットのタグは継続されます。この変更は、ネットワークのトラフィックの統計情報に影響します。例えば、```queryDetailsForUidTag()``` メソッドを使うときです。以前の挙動を維持したければ、```untagSocket()```を、他のプロセスに送る前に呼び出してください。

### ソケットにおける利用可能なbyte量のレポートについて (Reported amount of available bytes in socket)

> The available() method returns 0 when it's called after invoking the shutdownInput() method.

```shutdownInput()``` メソッドを呼び出した後、```available()``` メソッドは0を返します。

### More detailed network capabilities reporting for VPNs

In platform versions lower than Android P, the NetworkCapabilities class only reported a limited set of information for VPNs, such as TRANSPORT_VPN but omitting NET_CAPABILITY_NOT_VPN. This situation made it difficult for app developers to determine if using a VPN would result in charges to the user. For example, checking NET_CAPABILITY_NOT_METERED would not determine whether the underlying networks are metered or not.

Starting in Android P, when a VPN calls the setUnderlyingNetworks() method, the Android system merges the transports and capabilities of any underlying networks and returns the result as the effective network capabilities of the VPN network.

App developers that already check for NET_CAPABILITY_NOT_METERED receive the network capabilities of the VPN and the underlying networks starting in Android P.

### Files in xt_qtaguid folder are no longer available to apps

Direct read access to files in the /proc/net/xt_qtaguid folder is no longer allowed to apps. The reason is to ensure consistency with some devices running Android P at launch that don't have these files at all.

The public APIs that rely on these files, TrafficStats and NetworkStatsManager, continue to work as intended. However, the unsupported cutils functions, such as qtaguid_tagSocket(), may not work as expected—or at all— on different devices.

### FLAG_ACTIVITY_NEW_TASK requirement is now enforced

With Android P, you cannot start an activity from a non-activity context unless you pass the intent flag FLAG_ACTIVITY_NEW_TASK. If you attempt to start an activity without passing this flag, the activity does not start, and the system prints a message to the log.

Note: The flag requirement has always been the intended behavior, and was enforced before Android N. A bug in Android N temporarily kept the flag requirement from being enforced.

## Apps targeting Android P

These behavior changes apply exclusively to apps that are targeting the P platform or higher. Apps that compile against Android P or higher or set targetSdkVersion to Android P or higher must modify their apps to support these behaviors properly, where applicable to the app.

### Foreground Services

> Apps that target Android P or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app.

Android Pをtargetにするアプリで、foreground serviceを利用する場合は、FOREGROUND_SERVICE permissionが必須になります。これはnormal permissionなので、これを要求するアプリは自動的にsystemにより受理されます。

> If an app that targets Android P attempts to create a foreground service without requesting FOREGROUND_SERVICE, the system throws a SecurityException.

Android Pをtargetにするアプリが、FOREGROUND_SERVICEパーミッションをリクエストせずにforeground serviceを作ろうとすると、システムは、SecurityExceptionをthrowします。

### デバイスのシリアルへのアクセス制限 (Device serial access restrictions)

> The Build.SERIAL field was deprecated in Android 8.0 (API level 26). In Android P, Build.SERIAL is always set to "UNKNOWN". This change protects users' privacy.

Android 8.0 (API level 26)で、Build.SERIALは、deprecatedになりました。Android Pでは、Build.SERIALは常にUNKNOWNがセットされています。この変更はユーザーのプライバシーを守るためです。

> If your app needs to access a device's hardware serial number, you should request the READ_PHONE_STATE permission, then call getSerial().

もしあなたのアプリがハードウェアのシリアル番号が必要なのであれば、READ_PHONE_STATEパーミッションをリクエストし、その後、getSerial()を呼び出してください。

### フレームワークのセキュリティの変更 (Framework security changes)

> If your app targets Android P, the system enforces stricter network and file system security. For more details, see changes to apps targeting Android P on the Security Behavior Changes page.

Android Pをtargetにしている場合、システムは、より厳格なネットワークとファイルシステムセキュリティを実施します。詳細に関しては、[Android Pをtargetにしたアプリのセキュリティに関する挙動の変更](https://developer.android.com/preview/features/security-behav.html#p-apps)のページを参照のこと。

### View focus

Views with 0 area (either a width or a height is 0) are no-longer focusable.

Additionally, activities no-longer implicitly assign initial focus in touch-mode. Instead, it is up to you to explicitly request initial focus, if desired.

Android P apps enable the draft CSS Color Module Level 4 behaviour for handling 4 and 8 hex digit CSS colors.

CSS Color Module Level 4 has been supported by Chrome since release 52, but WebView currently disables the feature because existing Android applications were found to contain 32 bit hex colors in the Android ordering (ARGB), which would cause rendering errors.

For example, the color #80ff8080 is currently rendered in WebView as opaque light red (#ff8080) for apps targeting pre-Android P SDKs. The leading component (which would be interpreted by Android as the alpha component) is currently ignored. If an app targets P or above, this will be interpreted as 50% transparent light green (#80ff80).

### Document scrolling element

Previously to Android P, scrolling position was set on the body element, and the root element had zero scroll values. Android P enables the standards-compliant behaviour where the scrolling element is the root element.

Furthermore, directly accessing document.body.scrollTop, document.body.scrollLeft, document.documentElement.scrollTop or document.documentElement.scrollLeft will behave differently depending on target SDK. To access viewport scroll values, use document.scrollingElement, if available.

### Screen rotation changes

Users in Android O can toggle between auto-rotate and portrait rotation modes using a Quicksettings tile or Display settings. In Android P there are significant changes to the portrait rotation mode. The portrait mode has been renamed rotation lock and it is active when auto-rotate is toggled off. There are no changes to auto-rotate mode.

When the device is in rotation lock mode, users can lock their screen to any rotation supported by the top, visible Activity. An Activity should not assume it will always be rendered in portrait. If the top Activity can be rendered in multiple rotations in auto-rotate mode, the same options should be available in rotation locked mode, with some exceptions based on the Activity's screenOrientation setting (see the table below).

Activities that request a specific orientation (for example, screenOrientation=landscape) ignore the user lock preference and behave the same way as in Android O.

The screen orientation preference can be set at the Activity level in the Android Manifest, or programmatically with setRequestedOrientation().

The rotation lock mode works by setting the user rotation preference which the WindowManager uses when handling Activity rotation. The user rotation preference might be changed in the following cases. Note that there is a bias to return to portrait mode:

When the user accepts a rotation suggestion the rotation preference changes to the suggestion.
When the user switches to a forced portrait app (including the lock screen or the launcher) the rotation preference changes to portrait.

The following table summarizes rotation behavior for the common screen orientations:

| Screen Orientation | Behavior|
| :--- | :--- |
| unspecified, user | In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts. |
| userLandscape	| In auto-rotate and rotation lock the Activity can be rendered in either landscape or reverse landscape. Expect to support only landscape layouts. |
| userPortrait | In auto-rotate and rotation lock the Activity can be rendered in either portrait or reverse portrait. Expect to support only portrait layouts. |
| fullUser | In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts. <br> Rotation lock users will be given the option to lock to reverse portrait, often 180º. |
| sensor, fullSensor, sensorPortrait, sensorLandscape | The rotation lock mode preference is ignored and is treated as if auto-rotate is active. Only use this in exceptional circumstances with very careful UX |