Android 12 デベロッパー プレビューへようこそ。早い段階から頻繁にフィードバックをお送りいただき、Android 12 をさらに優れたリリースにするためにご協力ください。

動作の変更点: すべてのアプリ

Android 12 プラットフォームには、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、targetSdkVersion に関係なく、Android 12 上で稼働するすべてのアプリに適用されます。該当する場合は、アプリをテストし、必要に応じて修正して、適切に対応してください。

Android 12 をターゲットとするアプリにのみ影響する動作変更のリストも必ずご確認ください。

ユーザー エクスペリエンス

ジェスチャー ナビゲーションの没入モードの改善

Android 12 では、没入モードが簡素化されてジェスチャー ナビゲーションがより簡単になりました。また、動画の視聴や書籍の閲覧といった他のアクティビティのエクスペリエンスとの一貫性が向上しました。アプリは、引き続き全画面表示のゲーム エクスペリエンスで偶発的なジェスチャーから保護されるため、ユーザーがプレイ中に誤ってゲームを終了することはありません。また、他のすべての全画面表示または没入型のエクスペリエンスでは、ユーザーが 1 回のスワイプでスマートフォンをナビゲートできるようになりました。

これを可能にするため、Android 12 以降、非スティッキー没入型エクスペリエンス(BEHAVIOR_SHOW_BARS_BY_TOUCHBEHAVIOR_SHOW_BARS_BY_SWIPE)の既存の動作はサポートされなくなります。それらはデフォルトの動作(BEHAVIOR_DEFAULT)で置き換えられました。これにより、システムバーを非表示にする際に 1 回のスワイプでジェスチャーを行うことが可能になります。このフラグにより、モードに応じてさまざまな視覚的および機能的な動作が有効になります。

  • 3 ボタンモードでは、視覚的および機能的な動作は、Android 12 より前のバージョンの没入モードと同じです。
  • ジェスチャー ナビゲーション モードの動作は次のとおりです。
    • 視覚的には、Android 11 以下の没入モードと同じです。
    • 機能的には、バーが非表示のときもジェスチャーを使用できます。Android 11 ではシステムの「戻る」ナビゲーションを呼び出すのに 2 回のスワイプが必要でしたが、1 回のスワイプで足りるようになりました。通知バーを下にスワイプするときやホームに移動するときに、追加のスワイプは必要はありません。

Android 12 のスティッキー没入モード(BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE)に変更はありません。この機能には、次に示す下位互換性があります。

  • Android 11 以下をターゲットとする、Android 12 で動作するアプリの場合:
    • BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE は、機能的にも視覚的にも同様に動作します。
    • デフォルトの動作は BEHAVIOR_SHOW_BARS_BY_SWIPE にマッピングされています。
  • Android 12 をターゲットとする、Android 11(API レベル 30)以下で動作するアプリの場合:

フォアグラウンド サービス通知の遅延

Android 12 では、短時間実行されるフォアグラウンド サービスのエクスペリエンスを簡素化するため、特定のフォアグラウンド サービスについて、システムはフォアグラウンド サービス通知の表示を 10 秒間遅らせることができます。この変更により、通知が表示される前に存続時間の短いタスクを完了する機会が与えられます。

フォアグラウンド サービスに次の特性の少なくとも 1 つがある場合、サービスが開始されるとすぐに、関連する通知が表示されます。

  • サービスがアクション ボタンを含む通知に関連付けられている。
  • サービスの foregroundServiceTypeconnectedDevicemediaPlaybackmediaProjection または phoneCall である。
  • サービスが、通知の category 属性の定義に応じて、通話、ナビゲーション、またはメディア再生に関連するユースケースを提供している。

  • サービスが、通知の設定時に setShowForegroundImmediately() を呼び出すことにより、動作変更をオプトアウト済みである。

プライバシー

Netlink MAC アドレスの制限

Android 12 では、ターゲット API レベルと無関係に、システムアプリ以外のすべてのアプリに対して、デバイスの MAC アドレス(再設定不可の識別子)へのアクセスがさらに厳格に制限されます。

関連する API は、アプリのターゲット SDK バージョンに応じて、空の値またはプレースホルダ値を返します。

  • Android 12 をターゲットとするアプリの場合、API は null を返します。
  • Android 11 以下をターゲットとするアプリの場合、API はハードコードされたプレースホルダ値 02:00:00:00:00:00 を返します。

デベロッパーは、NetworkInterface などの下位レベル API、getifaddrs()、または Netlink ソケットではなく、ConnectivityManager を使用するようにしてください。デベロッパーがコード内で NetworkInterface.getHardwareAddress() を呼び出すと、logcat の出力は次のようになります: CompatibilityChangeReporter: Compat change id reported: 170188668;

デベロッパーは、RETURN_NULL_HARDWARE_ADDRESS という互換性フラグを使用することにより NetworkInterface.getHardwareAddress() の動作を切り替えて、null(有効にした場合)または 02:00:00:00:00:00(無効にした場合)を返すことができます。

セキュリティ

信頼できないタッチイベントはブロックされる

システム セキュリティと優れたユーザー エクスペリエンスを維持するため、Android 12 は、オーバーレイが安全でない方法でアプリを覆い隠している場合にタッチイベントをアプリが使用することを許しません。つまり、少数の例外を除いて、特定のウィンドウをパススルーするタッチはシステムによってブロックされます。

影響を受けるアプリ

この変更は、たとえば FLAG_NOT_TOUCHABLE フラグを使用してタッチにウィンドウをパススルーさせているアプリに影響します。具体例の一部を以下に示します。

例外

次の場合は「パススルー」タッチが許可されます。

  • アプリ内の操作: アプリがオーバーレイを表示し、ユーザーがアプリを操作しているときにのみオーバーレイが表示されます。
  • 信頼済みのウィンドウ: 信頼済みのウィンドウの例の一部を次に示します。

  • 不可視のウィンドウ: ルートビューが GONE または INVISIBLE のウィンドウ。

  • 完全に透明なウィンドウ: alpha プロパティが 0.0 のウィンドウ。

  • 十分に透明なシステム アラート ウィンドウ: 不透明度の組み合わせの総和がタッチに対するシステムの最大隠蔽不透明度以下である場合、一連のシステム アラート ウィンドウは十分に透明であると見なされます。デベロッパー プレビュー 1 では、この最大不透明度は 0.8 ですが、この値は今後のデベロッパー プレビューで変更される可能性があります。

信頼できないタッチがブロックされたときに検出する

タッチ アクションがシステムによってブロックされると、logcat は次のメッセージを記録します。

Untrusted touch due to occlusion by PACKAGE_NAME

変更をテストする

Android 12 デベロッパー プレビュー 1 を搭載したデバイスでは、信頼できないタッチはデフォルトでブロックされます。信頼できないタッチを許可するには、ターミナル ウィンドウで次の adb コマンドを実行します。

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

動作をデフォルト(信頼できないタッチがブロックされる)に戻すには、次のコマンドを実行します。

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

アプリからシステム ダイアログを閉じるアクションが不可に

アプリとシステムを操作しているときのユーザー制御を改善するため、Android 12 では ACTION_CLOSE_SYSTEM_DIALOGS インテント アクションのサポートが終了しました。少数の特殊なケースを除いて、アプリがこのアクションを含むインテントの呼び出しを試みると、アプリのターゲット SDK バージョンに応じてシステムは次のいずれかを行います。

  • Android 12 をターゲットとするアプリの場合は、SecurityException をスローします。
  • Android 11(API レベル 30)以下をターゲットとするアプリの場合は、インテントを実行しません。logcat には次のメッセージが表示されます。

    E ActivityTaskManager Permission Denial: \
    android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
    com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
    dropping broadcast.
    

例外

次の場合、アプリは Android 12 で引き続きシステム ダイアログを閉じることができます。

  • アプリがインストルメンテーション テストを実行している。
  • アプリが Android 11 以下をターゲットとしており、通知ドロワーの上にウィンドウを表示している。

  • アプリが Android 11 以下をターゲットとしている。さらに、ユーザーが(おそらく通知のアクション ボタンを使用して)通知を操作し、アプリがそのユーザー アクションに応じてサービスまたはブロードキャスト レシーバを処理している。

非 SDK インターフェースの制限

Android 12 では、Android デベロッパーの協力と直近の内部テストに基づいて、制限を受ける非 SDK インターフェースのリストが更新されています。Google は、非 SDK インターフェースを制限する前に、可能な限り、その代わりとなる公開インターフェースを利用可能にしています。

Android 12 をターゲットとしないアプリでは、この変更の一部はすぐには影響しない可能性があります。ただし、現時点で(アプリのターゲット API レベルに応じて)一部の非 SDK インターフェースを利用できていても、非 SDK のメソッドまたはフィールドをそのまま使用し続けると、将来的にアプリが機能しなくなるリスクが高くなります。

アプリが非 SDK インターフェースを使用しているかどうか不明な場合は、アプリをテストして確認できます。アプリが非 SDK インターフェースに依存している場合は、SDK の代替インターフェースへの移行を計画してください。ただし Google も、一部のアプリには非 SDK インターフェースを使用する正当なユースケースがあると承知しています。アプリの機能で使用している非 SDK インターフェースの代替インターフェースが見つからない場合は、新しい公開 API をリクエストしてください。

Android の今回のリリースの変更について詳しくは、非 SDK インターフェースの制限に関する Android 12 での変更点をご覧ください。非 SDK インターフェース全般について詳しくは、非 SDK インターフェースの制限をご覧ください。