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

Android 5.0 の動作の変更点

API レベル: 21

Android 5.0 には、新機能や機能に加えて、さまざまなシステムの変更と API の動作の変更が含まれています。このドキュメントでは、アプリで理解し、考慮すべき主な変更点について説明します。

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

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

動画

デベロッパー向け情報: Android 5.0 の新機能

デベロッパー向け情報: 通知

Android ランタイム（ART）

Android 5.0 では、ART ランタイムがプラットフォームのデフォルトとして Dalvik に代わるランタイムになります。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 以前では、ユーザーは特定のデバイスに複数のこのようなアプリをインストールできましたが、システムは最初にインストールされたアプリで指定された保護レベルを割り当てました。

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 インスタンスを作成するように設計する必要があります。

アプリが、サーバーに接続するために使用される暗号スイートについて誤った前提を立てている

たとえば、一部のアプリには、authType パラメータが RSA であることを想定しているにもかかわらず ECDHE_RSA または DHE_RSA が検出されるカスタム X509TrustManager が含まれているため、破損します。

サーバーが 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 では、ロック画面ウィジェットのサポートが終了します。ホーム画面のウィジェットは引き続きサポートされます。