page.title=動作の変更点 page.keywords=プレビュー,sdk,compatibility sdk.platform.apiLevel=MNC @jd:body
M Developer Preview には、新機能以外にもさまざまなシステムの変更点や API の動作の変更点が盛り込まれています。 このドキュメントでは、アプリ開発において把握しておくべき主な変更点について説明します。
過去に Android にアプリを公開したことがある場合は、アプリがこれらの変更による影響を受ける場合があることに注意してください。
このプレビューでは、アプリのパーミッションを実行時にユーザーが直接管理できる新しいパーミッション モデルが採用されました。 このモデルによって、ユーザーに対するパーミッションの可視性と制御性が向上し、アプリ開発者にとってはアプリのインストールや自動アップデート プロセスの効率が上がります。ユーザーはインストール済みアプリのパーミッションを個別に付与したり取り消したりできます。
M Preview を対象としたアプリでは、必ずパーミッションを実行時に確認、要求するようにします。 アプリにパーミッションが付与されているかどうかを確認するには、新しい {@code Context.checkSelfPermission()} メソッドを呼び出します。 パーミッションを要求するには、新しい {@code Activity.requestPermission()} メソッドを呼び出します。アプリが M を対象としていない場合でも、新しいパーミッション モデルでアプリをテストするようにしてください。
アプリで新しいパーミッションをサポートする際の詳細については、Developer Preview ページの Permissions をご覧ください。 アプリへの影響を評価する際のヒントについては、Testing Guide をご覧ください。
このプレビューでは、アイドル中の端末やアプリに対する新しい省電力の最適化機能が採用されています。
端末が電源に接続されておらず、画面が一定時間オフ状態の場合は Doze モードに入り、システムをスリープ状態に保ちます。 このモードでは、端末は定期的に通常の操作を短時間再開することで、アプリを同期したり、システムが保留中の操作を行ったりすることができます。
Doze 中は、アプリに次の制限が適用されます。
端末が Doze モードでなくなると、保留中のすべての同期とジョブが実行されます。
この機能をテストするには、M Preview を実行する端末を開発マシンに接続して、次のコマンドを呼び出します。
$ adb shell dumpsys battery unplug $ adb shell dumpsys deviceidle step $ adb shell dumpsys deviceidle -h
注: Google Cloud Messaging の次期リリースでは、高優先度のメッセージを指定できます。 アプリが高優先度の GCM メッセージを受信する場合は、端末が Doze 中でも短時間のネットワーク アクセスが付与されます。
アプリで Doze をテストする方法のヒントについては、 Testing Guide をご覧ください。
このプレビューでは、アクティブに使用されていないアプリをシステムがアイドル状態であるとみなす場合があります。 システムが次の信号を検出しない場合、一定時間の経過後にアプリはアイドル状態であるとみなされます。
端末が電源に接続されていない場合、アイドル中のみなされたアプリのネットワーク アクセスは無効になり、同期とジョブは保留されます。 端末が電源に接続されると、アプリのネットワーク アクセスは許可され、保留中のすべてのジョブと同期が実行されます。 端末が長時間アイドル状態の場合、アイドル中のアプリは 1 日 1 回程度ネットワーク アクセスが許可されます。
この機能をテストするには、M Preview を実行する端末を開発マシンに接続して、次のコマンドを呼び出します。
$ adb shell dumpsys battery unplug $ adb shell am set-idle <packageName> true $ adb shell am set-idle <packageName> false $ adb shell am get-idle <packageName>
注: Google Cloud Messaging(GCM)の次期リリースでは、高優先度のメッセージを指定できます。 アプリが高優先度の GCM メッセージを受信する場合は、アプリがアイドル 中でも短時間のネットワーク アクセスが付与されます。
アプリで App Standby をテストする方法のヒントについては、 Testing Guide をご覧ください。
このプレビューでは、SD カードなどの外部ストレージ端末を追加できます。外部ストレージ端末を追加すると、端末が内部ストレージのように動作するよう暗号化とフォーマットが行われます。 この機能によって、アプリとアプリの個人データをストレージ端末間で移動できるようになります。 アプリを移動する際、システムはマニフェストの {@code android:installLocation} を遵守します。
アプリが次の API やフィールドにアクセスする場合は、アプリが内部ストレージ端末と外部ストレージ端末間で移動する際に返されるファイルパスが動的に変化することに注意してください。ファイルパスの構築時は、これらの API を動的に呼び出すことを強くお勧めします。ハードコードされたファイル パスを使用したり、過去にビルドした完全修飾ファイルパスをそのまま使用したりしないでください。
Developer Preview のこの機能をデバッグするには、USB On-The-Go(OTG)ケーブルで Android 端末に接続された USB ドライブの追加を有効にして、次のコマンドを実行します。
$ adb shell sm set-force-adoptable true
このプレビューでは、Apache HTTP クライアントのサポートが削除されました。アプリでこのクライアントを使用していて、Android 2.3(API レベル 9)以上を対象としている場合は、代わりに {@link java.net.HttpURLConnection} クラスを使用します。 この API は透過的データ圧縮と応答のキャッシュによってネットワーク使用を軽減し、電源の消費を最小化するため、効率性が向上します。 Apache HTTP API を引き続き使用するには、まず {@code build.gradle} ファイルで次のコンパイル時の依存関係を宣言する必要があります。
android { useLibrary 'org.apache.http.legacy' }
Android は、OpenSSL から BoringSSL ライブラリに移行しています。 アプリで Android NDK を使用している場合は、{@code libcrypto.so} や {@code libssl.so} など、NDK API の一部でない暗号化ライブラリにリンクしないでください。 これらのライブラリは パブリック API ではなく、リリースや端末に対する通知なしで変更されたり、中断したりする可能性があります。また、セキュリティ上の脆弱性を露呈する場合もあります。 代わりに、ネイティブ コードを変更して JNI 経由で Java の暗号化 API を呼び出すか、希望の暗号化ライブラリに静的リンクします。
{@link android.media.AudioManager} クラスで音量を直接設定したり、特定のストリームをミュートにしたりする方法はサポートされなくなりました。 {@link android.media.AudioManager#setStreamSolo(int,boolean) setStreamSolo()} メソッドは廃止されたため、代わりに {@code AudioManager.requestAudioFocus()} メソッドを呼び出す必要があります。同様に、 {@link android.media.AudioManager#setStreamMute(int,boolean) setStreamMute()} メソッドも廃止され、代わりに {@code AudioManager.adjustStreamVolume()} メソッドを呼び出して、値に {@code ADJUST_MUTE} か {@code ADJUST_UNMUTE} を渡します。
ユーザーがアプリ内でテキストを選択するとき、 切り取り、コピー、貼り付けなどのテキスト選択のアクションを フローティング ツール バーに表示できるようになりました。 個別のビューに対してコンテキスト アクション モードを有効にするにあるように、コンテキスト アクションバーに関するユーザー操作の実装も同様です。
テキスト選択にフローティング ツール バーを実装するには、既存のアプリに次の変更を加えます。
Android Support Library revision 22.2 を使用している場合、フローティング ツール バーに下方互換性はなく、デフォルトで appcompat が代わりに {@link android.view.ActionMode} オブジェクトを制御することに注意してください。 これにより、フローティング ツール バーは表示されなくなります。 {@link android.support.v7.app.AppCompatActivity} で {@link android.view.ActionMode} がサポートされるようにするには、 {@code android.support.v7.app.AppCompatActivity.getDelegate()} を呼び出して、返された {@link android.support.v7.app.AppCompatDelegate} オブジェクトで {@code android.support.v7.app.AppCompatDelegate.setHandleNativeActionModesEnabled()} を呼び出し、 入力パラメータを {@code false} に設定します。 この呼び出して、{@link android.view.ActionMode} オブジェクトの制御がフレームワークに戻ります。 M Preview を実行する端末ではフレームワークによる {@link android.support.v7.app.ActionBar} やフローティング ツール バー モードのサポートが可能ですが、M Preview 以前の端末では {@link android.support.v7.app.ActionBar} モードのみがサポートされます。
このプレビューでは、 Android Keystore プロバイダによる DSA のサポートがなくなります。 ECDSA は引き続きサポートされます。
停止時に暗号化を必要としないキーが、ロック画面の(ユーザーや端末の管理者などによる)無効時やリセット時に削除されなくなりました。 停止時に暗号化を必要とするキーは、これらのイベント時に削除されます。
このプレビューでは、Wi-Fi API とネットワーク API の動作に次のような変更点が追加されました。
このプレビューでは、カメラ サービスの共有リソースへのアクセスモデルが、以前の "先着順" モデルから、"優先度順" に変更されました。 この動作の変更には、次のようなものがあります。
ART ランタイムで、 {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} メソッドに対するアクセスルールを正常に実装できるようになりました。この変更によって、以前のバージョンで Dalvik がアクセス ルールを正しく確認できなかった問題が解決しました。アプリで {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} メソッドを使用していて、アクセス チェックをオーバーライドしたい場合は、 {@link java.lang.reflect.Constructor#setAccessible(boolean) setAccessible()} メソッドを使って入力パラメータを {@code true} に設定します。 アプリで v7 appcompat ライブラリや v7 recyclerview ライブラリを使用する場合は、これらのライブラリの最新バージョンを使用するようアプリをアップデートする必要があります。 アップデートしない場合は、XML から参照するカスタム クラスがアップデートされていて、クラス コンストラクタがアクセス可能であることを確認しておく必要があります。
このプレビューでは、動的リンクの動作がアップデートされました。動的リンクでは、ライブラリの {@code soname} とそのパス( public bug 6670)の違いを認識でき、{@code soname} が実装されています。 以前動作していたアプリで間違った {@code DT_NEEDED} エントリを持つもの(ビルドマシンのファイル システムの絶対パスなど)は、読み込み時に失敗する場合があります。
{@code dlopen(3) RTLD_LOCAL} フラグは正常に実装されました。 {@code RTLD_LOCAL} はデフォルトのため、 {@code RTLD_LOCAL} を明示的に使用しない {@code dlopen(3)} への呼び出しは影響を受けます(アプリで明示的に {@code RTLD_GLOBAL} を使用している場合を除く)。 {@code RTLD_LOCAL} では、後に {@code dlopen(3)} への呼び出しで読み込まれたライブラリで記号は使用できません({@code DT_NEEDED} エントリによって参照された場合とは逆)。
プラットフォームでより厳しい APK の検証が行われるようになりました。APK がマニフェスト ファイルで宣言されているにもかかわらず、APK 自体に存在しない場合、その APK は破損しているとみなされます。 コンテンツが一部でも削除された場合は、APK の再署名が必要になります。
このプレビューには、次のような Android for Work に関する動作の変更点が含まれています。