このページは Cloud Translation API によって翻訳されました。

Android 5.0 での動作の変更点

API レベル: 21

Android 5.0 では、新機能のほか、さまざまなシステム変更や API の動作変更が行われています。このドキュメントでは、アプリで把握しておくべき主な変更点について説明します。

以前に Android 向けのアプリを公開したことがある場合は、アプリが Android 5.0 におけるこれらの変更の影響を受ける可能性があることに注意してください。

新しいプラットフォーム機能の概要については、Android Lollipop のハイライトをご覧ください。

動画

Dev Byte: Android 5.0 の新機能

Dev Byte: 通知

Android ランタイム（ART）

Android 5.0 では、Dalvik の代わりに ART ランタイムがプラットフォームのデフォルトになりました。ART ランタイムは、Android 4.4 で試験運用版として導入されました。

ART の新機能の概要については、ART の概要をご覧ください。主な新機能は次のとおりです。

事前（AOT）コンパイル
ガベージコレクション（GC）の改善
デバッグサポートの改善

ほとんどの Android アプリは、何も変更しなくても ART で動作します。ただし、Dalvik で機能する一部の手法は ART では機能しません。最も重要な問題については、Android ランタイム（ART）でのアプリの動作確認をご覧ください。次の場合は特に注意してください。

アプリは Java Native Interface（JNI）を使用して C/C++ コードを実行しています。
標準以外のコードを生成する開発ツール（難読化ツールなど）を使用している。
ガベージコレクションの圧縮と互換性のない手法を使用している。

通知

この Android 5.0 の変更点を通知で考慮してください。 Android 5.0 以降向けの通知の設計について詳しくは、通知の設計ガイドをご覧ください。

マテリアルデザインスタイル

通知は、新しいマテリアルデザインウィジェットに合わせて、白い（または非常に明るい）背景の上に暗いテキストで描画されます。新しいカラーパターンですべての通知が適切に表示されることを確認してください。通知が正しく表示されない場合は、修正します。

setColor() を使用して、アイコン画像の背後にある円の中にアクセントカラーを設定します。
色を含むアセットを更新または削除します。アルファ版以外のチャンネルはすべて、アクションアイコンとメインの通知アイコンから無視されます。これらのアイコンはアルファ版専用であると想定してください。通知アイコンは白色、アクションアイコンは濃いグレーで描画されます。

音とバイブレーション

現在、Ringtone クラス、MediaPlayer クラス、または Vibrator クラスを使用して通知に音やバイブレーションを追加している場合は、このコードを削除して、優先モードで通知を正しく表示できるようにします。代わりに、Notification.Builder メソッドを使用して音やバイブレーションを追加します。

デバイスを RINGER_MODE_SILENT に設定すると、デバイスは新しい優先モードに切り替わります。RINGER_MODE_NORMAL または RINGER_MODE_VIBRATE に設定すると、デバイスは優先モードを終了します。

これまで Android では、タブレットデバイスの音量を調整するためのマスターストリームとして STREAM_MUSIC を使用していました。Android 5.0 では、スマートフォンデバイスとタブレットデバイスのマスターボリュームストリームが統合され、STREAM_RING または STREAM_NOTIFICATION によって制御されるようになりました。

ロック画面の表示

Android 5.0 では、デフォルトでユーザーのロック画面に通知が表示されるようになりました。ユーザーは機密情報が漏洩しないように保護できます。その場合、通知に表示されるテキストはシステムによって自動的に秘匿化されます。この秘匿化された通知をカスタマイズするには、setPublicVersion() を使用します。

通知に個人情報が含まれていない場合、または通知でのメディア再生コントロールを許可する場合は、setVisibility() メソッドを呼び出して、通知の表示レベルを VISIBILITY_PUBLIC に設定します。

メディア再生

メディアの再生ステータスやトランスポートコントロールを表示する通知を実装する場合は、カスタムの RemoteViews.RemoteView オブジェクトではなく、新しい Notification.MediaStyle テンプレートの使用を検討してください。いずれの方法を使用する場合でも、通知の表示を VISIBILITY_PUBLIC に設定して、ロック画面からコントロールにアクセスできるようにしてください。Android 5.0 以降では、ロック画面に RemoteControlClient オブジェクトが表示されなくなります。詳細については、アプリで RemoteControlClient を使用する場合をご覧ください。

ヘッドアップ通知

デバイスがアクティブなとき（つまり、デバイスがロック解除されていて画面がオンになっているとき）に、小さなフローティングウィンドウ（ヘッドアップ通知とも呼ばれます）に通知が表示されるようになりました。これらの通知は、ヘッドアップ通知にアクションボタンも表示されることを除けば、コンパクトな通知形式と同じように表示されます。ユーザーは、現在のアプリから移動することなく、ヘッドアップ通知に対して操作や非表示ができます。

ヘッドアップ通知がトリガーされる可能性のある状況の例を次に示します。

ユーザーのアクティビティが全画面モードになっている（アプリが fullScreenIntent を使用する）
通知の優先度が高く、着信音またはバイブレーションが使用されている

アプリがこれらのシナリオのいずれかで通知を実装している場合は、ヘッドアップ通知が正しく表示されることを確認してください。

メディアコントロールと RemoteControlClient

RemoteControlClient クラスのサポートが終了しました。できるだけ早く新しい MediaSession API に切り替えてください。

Android 5.0 のロック画面には、MediaSession または RemoteControlClient のトランスポートコントロールは表示されません。代わりに、アプリで通知を通じてロック画面からメディア再生コントロールを提供できます。これにより、アプリはメディアボタンの表示をより細かく制御でき、ロックされているデバイスとロック解除されているデバイスの両方で一貫したユーザーエクスペリエンスを実現できます。

Android 5.0 では、この目的のために新しい Notification.MediaStyle テンプレートが導入されています。Notification.MediaStyle は、Notification.Builder.addAction() で追加した通知アクションを、アプリのメディア再生通知に埋め込まれたコンパクトボタンに変換します。セッショントークンを setSession() メソッドに渡して、進行中のメディアセッションをこの通知が制御することをシステムに通知します。

通知の表示を VISIBILITY_PUBLIC に設定して、通知をロック画面に（セキュアかどうかに関係なく）表示しても安全であるとマークします。詳細については、ロック画面通知をご覧ください。

アプリが Android TV または Wear プラットフォームで実行されている場合にメディア再生コントロールを表示するには、MediaSession クラスを実装します。また、アプリが Android デバイスでメディアボタンイベントを受信する必要がある場合は、MediaSession も実装する必要があります。

getRecentTasks()

Android 5.0 で新しいドキュメントとアクティビティの同時タスク機能（後述の履歴画面の同時ドキュメントとアクティビティの同時実行を参照）が導入されたことに伴い、ユーザーのプライバシーを向上させるため、ActivityManager.getRecentTasks() メソッドのサポートが終了しました。下位互換性を確保するため、このメソッドは引き続き、呼び出し元アプリの独自のタスクと、場合によってはその他の機密性の低いタスク（Home など）を含むデータの小さなサブセットを返します。アプリがこのメソッドを使用して独自のタスクを取得している場合は、代わりに getAppTasks() を使用してその情報を取得します。

Android NDK での 64 ビットのサポート

Android 5.0 では、64 ビットシステムのサポートが導入されました。64 ビットの機能強化により、既存の 32 ビットアプリを完全にサポートしながら、アドレス空間が増え、パフォーマンスが向上します。また、64 ビットのサポートにより、OpenSSL の暗号化のパフォーマンスも向上しています。さらにこのリリースでは、新しいネイティブメディア NDK API とネイティブ OpenGL ES（GLES）3.1 サポートが導入されています。

Android 5.0 で提供されている 64 ビットサポートを使用するには、Android NDK のページから NDK リビジョン 10c をダウンロードしてインストールします。NDK の重要な変更とバグの修正について詳しくは、リビジョン 10c のリリースノートをご覧ください。

サービスにバインドする

Context.bindService() メソッドで明示的な Intent が必要になり、暗黙的インテントが与えられた場合は例外をスローするようになりました。アプリの安全性を確保するには、Service の開始時またはバインド時に明示的インテントを使用し、サービスのインテントフィルタを宣言しないでください。

WebView

Android 5.0 では、アプリのデフォルトの動作が変更されました。

アプリが API レベル 21 以降をターゲットとしている場合:
- システムはデフォルトで、混合コンテンツとサードパーティの Cookie をブロックします。混合コンテンツとサードパーティ Cookie を許可するには、それぞれ setMixedContentMode() メソッドと setAcceptThirdPartyCookies() メソッドを使用します。
- システムは、HTML ドキュメントの一部を描画するインテリジェントに選択します。この新しいデフォルト動作により、メモリフットプリントの削減とパフォーマンスの向上が実現します。ドキュメント全体を一度にレンダリングする場合は、enableSlowWholeDocumentDraw() を呼び出してこの最適化を無効にします。
アプリが API レベル 21 未満をターゲットとしている場合: 混合コンテンツとサードパーティ Cookie が許可され、常にドキュメント全体が一度に表示されます。

カスタム権限の一意性の要件

権限の概要に記載されているように、Android アプリでは、プラットフォームにあらかじめ定義されたシステム権限を使用することなく、独自の方法でコンポーネントへのアクセスを管理する手段として、カスタム権限を定義できます。アプリは、マニフェストファイルで宣言された <permission> 要素でカスタム権限を定義します。

カスタム権限を定義することが合理的で安全なアプローチであるシナリオは、いくつかあります。ただし、カスタム権限の作成は不要なことがあり、権限に割り当てられた保護レベルによっては、アプリに潜在的なリスクをもたらす可能性があります。

Android 5.0 では、1 つのアプリのみが特定のカスタム権限を定義できるように動作が変更されています（権限を定義する他のアプリと同じ鍵で署名されている場合を除きます）。

重複するカスタム権限を使用しているアプリ

どのアプリも必要なカスタム権限を定義できるため、複数のアプリが同じカスタム権限を定義する可能性があります。たとえば、2 つのアプリが同様の機能を提供する場合、カスタム権限に対して同じ論理名が導出される可能性があります。アプリには、同じカスタム権限の定義が含まれている共通の公開ライブラリやコードサンプルを組み込むこともできます。

Android 4.4 以前では、最初にインストールされたアプリによって指定された保護レベルがシステムによって割り当てられたが、ユーザーは 1 台のデバイスに複数のこのようなアプリをインストールできました。

Android 5.0 以降では、異なる鍵で署名されたアプリに対して、新しいカスタム権限に一意性の制限が適用されます。特定のカスタム権限を定義できるのは、デバイス上の 1 つのアプリのみ（名前で決定されるとおり）になりました。ただし、権限を定義している他のアプリが同じ鍵で署名されている場合は除きます。重複するカスタム権限を使用してアプリをインストールしようとしたときに、その権限を定義している常駐アプリと同じ鍵で署名されていない場合、システムはインストールをブロックします。

アプリに関する考慮事項

Android 5.0 以降では、アプリはこれまでどおり独自のカスタム権限を定義でき、<uses-permission> メカニズムを通じて他のアプリにカスタム権限をリクエストすることもできます。ただし、Android 5.0 で導入された新しい要件により、アプリに及ぼす可能性がある影響を慎重に評価する必要があります。

次の点に注意してください。

アプリのマニフェストで <permission> 要素を宣言していますか？その場合、アプリやサービスの適切な機能に本当に必要か。または、システムのデフォルトの権限を使用できますか？
アプリに <permission> 要素がある場合、それらがどこから来たかを把握していますか。
実際に他のアプリが <uses-permission> を通じてカスタム権限をリクエストする予定はありますか？
<permission> 要素を含むボイラープレートまたはサンプルコードをアプリで使用していますか？それらの権限要素は実際に必要ですか？
カスタム権限で、シンプルな名前を使用しているか、または他のアプリが共有する可能性のある一般的な用語に基づく名前を使用しているか。

新規インストールとアップデート

前述のとおり、Android 4.4 以前を搭載したデバイスでのアプリの新規インストールとアップデートは影響を受けず、動作に変更はありません。Android 5.0 以降を搭載するデバイスで新規のインストールとアップデートを行う際、既存の常駐アプリですでに定義されているカスタム権限が定義されている場合、アプリのインストールが禁止されます。

Android 5.0 システムアップデートによる既存のインストール

アプリがカスタム権限を使用しており、広く配信、インストールされている場合、ユーザーがデバイスを Android 5.0 に更新すると、影響を受ける可能性があります。システムアップデートがインストールされると、システムはインストール済みのアプリを再検証し、アプリのカスタム権限の確認も行います。すでに検証済みの別のアプリですでに定義されているカスタム権限をアプリで定義し、そのアプリが他のアプリと同じ鍵で署名されていない場合、アプリは再インストールされません。

推奨事項

Android 5.0 以降を搭載したデバイスでは、アプリをすぐに調べて必要な調整を行い、更新版をできるだけ早くユーザーに公開することをおすすめします。

アプリでカスタム権限を使用している場合は、そのオリジンと、実際にその権限が必要かどうかを考慮してください。アプリからすべての <permission> 要素を削除します。ただし、アプリの適切な機能に必要であることが確実な場合を除きます。
可能であれば、カスタム権限をシステムのデフォルトの権限に置き換えることを検討してください。
アプリがカスタム権限を必要とする場合は、アプリの完全なパッケージ名に追加するなどして、カスタム権限の名前をアプリに固有の名前に変更します。
異なる鍵で署名されたアプリのスイートがあり、それぞれのアプリがカスタム権限を使用して共有コンポーネントにアクセスする場合、カスタム権限は共有コンポーネント内で 1 回だけ定義するようにしてください。共有コンポーネントを使用するアプリは、カスタム権限自体を定義するのではなく、 <uses-permission> メカニズムを通じてアクセスをリクエストする必要があります。
一連のアプリを同じ鍵で署名している場合、各アプリは必要に応じて同じカスタム権限を定義できます。システムは、アプリを通常の方法でインストールできます。

TLS/SSL デフォルト構成の変更

Android 5.0 では、アプリが HTTPS やその他の TLS/SSL トラフィックに使用するデフォルトの TLS/SSL 構成が変更されました。

TLSv1.2 プロトコルと TLSv1.1 プロトコルが有効になりました。
AES-GCM（AEAD）暗号スイートが有効になりました。
MD5、3DES、エクスポート、静的鍵 ECDH 暗号スイートが無効になりました。
前方秘匿性暗号スイート（ECDHE と DHE）が推奨されます。

これらの変更により、以下に挙げる少数のケースで HTTPS または TLS/SSL 接続の障害が発生する可能性があります。

なお、Google Play 開発者サービスのセキュリティ ProviderInstaller はすでに、Android 2.3 以降の Android プラットフォームバージョン間でこうした変更を提供しています。

有効な暗号スイートのいずれもサーバーがサポートしていない

たとえば、サーバーが 3DES または MD5 暗号スイートのみをサポートしている場合があります。推奨される修正方法は、サーバーの構成を改善して、より強力で最新の暗号スイートとプロトコルを有効にすることです。理想的には、TLSv1.2 と AES-GCM を有効にし、前方秘匿暗号スイート（ECDHE、DHE）を有効にして優先します。

別の方法として、アプリを変更して、カスタムの SSLSocketFactory を使用してサーバーと通信することもできます。ファクトリは、デフォルトの暗号スイートに加えて、サーバーに必要な暗号スイートの一部が有効にされた SSLSocket インスタンスを作成するように設計する必要があります。

サーバーへの接続に使用される暗号スイートについて、アプリが誤った想定をしている

たとえば、一部のアプリにはカスタム X509TrustManager が含まれています。これは、authType パラメータが RSA であると想定されているものの、ECDHE_RSA または DHE_RSA を受け取るために動作しなくなることがあります。

サーバーが TLSv1.1、TLSv1.2、または新しい TLS 拡張機能に寛容である

たとえば、サーバーとの TLS/SSL handshake が誤って拒否されるか、停止します。この問題を解決するには、TLS/SSL プロトコルに準拠するようサーバーをアップグレードすることをおすすめします。これにより、サーバーはこれらの新しいプロトコルとネゴシエーションを正常に行うか、TLSv1 または古いプロトコルとネゴシエートし、認識できない TLS 拡張機能を無視します。場合によっては、サーバーで TLSv1.1 と TLSv1.2 を無効にすることで、サーバーソフトウェアがアップグレードされるまでの暫定措置として機能することがあります。

別の方法として、アプリを変更して、カスタムの SSLSocketFactory を使用してサーバーと通信することもできます。ファクトリは、サーバーで正しくサポートされているプロトコルのみを有効にして SSLSocket インスタンスを作成するように設計する必要があります。

管理対象プロファイルのサポート

デバイス管理者は、デバイスに管理対象プロファイルを追加できます。このプロファイルは管理者が所有します。そのため、管理者は管理対象プロファイルを制御できます。ただし、ユーザーの個人用プロファイルとその保存容量は、ユーザーが制御できる状態のままになります。この変更は、既存のアプリの動作に次のような影響を与える可能性があります。

インテントを処理する

デバイス管理者は、管理対象プロファイルからシステムアプリへのアクセスを制限できます。この場合、通常はそのアプリによって処理されるであろうインテントが管理対象プロファイルから起動され、そのインテントに適したハンドラが管理対象プロファイルにない場合、インテントは例外を発生させます。たとえば、デバイス管理は、管理対象プロファイル上のアプリがシステムのカメラアプリにアクセスできないように制限できます。アプリが管理対象プロファイルで実行され、MediaStore.ACTION_IMAGE_CAPTURE に対して startActivityForResult() を呼び出し、インテントを処理できるアプリが管理対象プロファイルにない場合、ActivityNotFoundException が発生します。

これを防ぐには、インテントを呼び出す前に、任意のインテントにハンドラが 1 つ以上あることを確認します。有効なハンドラを確認するには、Intent.resolveActivity() を呼び出します。この処理の例については、単に写真を撮影する: カメラアプリで写真を撮影するをご覧ください。

プロファイル間でのファイルの共有

プロファイルごとに固有のファイルストレージがあります。ファイル URI はファイルストレージ内の特定の場所を参照するため、一方のプロファイルでは有効なファイル URI が、もう一方のプロファイルでは無効となります。これは通常、アプリが作成するファイルにアクセスするだけのアプリにとって問題ではありません。ただし、アプリがインテントにファイルを添付する場合、ファイル URI のアタッチは安全ではありません。状況によっては、インテントがもう一方のプロファイルで処理される可能性があるためです。たとえば、デバイス管理者が、画像キャプチャイベントを個人プロファイルのカメラアプリで処理するように指定する場合があります。管理対象プロファイル上のアプリによってインテントが呼び出された場合、カメラは、管理対象プロファイルのアプリが画像を読み取れる場所に画像を書き込むことができる必要があります。

安全のため、プロファイル間で共通するインテントにファイルを添付する必要がある場合は、ファイルのコンテンツ URI を作成して使用する必要があります。コンテンツ URI を使用してファイルを共有する方法については、ファイルを共有するをご覧ください。たとえば、デバイス管理者が、個人用プロファイル内のカメラによる ACTION_IMAGE_CAPTURE の処理を許可する場合があります。起動インテントの EXTRA_OUTPUT には、写真の保存場所を指定するコンテンツ URI を含める必要があります。カメラアプリは、その URI で指定された場所に画像を書き込むことができます。インテントを起動したアプリは、アプリが他のプロファイルにあっても、そのファイルを読み取ることができます。

Android 5.0 ではロック画面ウィジェットのサポートが削除されました。ホーム画面のウィジェットは引き続きサポートされます。