機能と API

Android 17 では、デベロッパー向けに優れた新しい機能と API が導入されました。以下のセクションでは、これらの機能の概要を説明し、関連する API を試すための情報を提供します。

新しい API、変更された API、削除された API の一覧については、API 差分レポートをご覧ください。新しい API について詳しくは、Android API リファレンスをご覧ください。新しい API は、見つけやすいようにハイライト表示されています。

プラットフォームの変更がアプリに影響する可能性がある領域も確認してください。詳しくは次のページをご覧ください。

コア機能

Android 17 では、Android のコア機能に関連する次の新機能が追加されています。

新しい ProfilingManager トリガー

Android 17 では、パフォーマンスの問題をデバッグするための詳細なデータを収集できるように、ProfilingManager にいくつかの新しいシステムトリガーが追加されています。

新しいトリガーは次のとおりです。

TRIGGER_TYPE_COLD_START: アプリのコールドスタート時にトリガーが発生します。レスポンスでコールスタックサンプルとシステムトレースの両方が提供されます。
TRIGGER_TYPE_OOM: アプリが OutOfMemoryErrorをスローしたときにトリガーが発生し、レスポンスで Java ヒープダンプが提供されます。
TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: アプリが異常な CPU 使用率の高さにより強制終了されたときにトリガーが発生し、レスポンスでコールスタックサンプルが提供されます。
TRIGGER_TYPE_ANOMALY: バインダー呼び出しの過多やメモリ使用量の過多など、システムパフォーマンスの異常を検出します。

システムトリガーの設定方法については、トリガーベースのプロファイリングとプロファイリングデータの取得と分析に関するドキュメントをご覧ください。

アプリの異常のプロファイリングトリガー

Android 17 では、リソースを大量に消費する動作や互換性の低下の可能性をモニタリングするオンデバイス異常検出サービスが導入されています。ProfilingManager と統合されたこのサービスにより、アプリはシステムが検出した特定のイベントによってトリガーされるプロファイリングアーティファクトを受け取ることができます。

TRIGGER_TYPE_ANOMALY トリガーを使用して、バインダー呼び出しの過多やメモリ使用量の過多など、システムパフォーマンスの問題を検出します。アプリが OS で定義されたメモリ制限を超えると、異常トリガーにより、デベロッパーはアプリ固有のヒープダンプを受け取って、メモリの問題を特定して修正できます。また、バインダースパムが過剰な場合は、異常トリガーにより、バインダートランザクションのスタックサンプリングプロファイルが提供されます。

この API コールバックは、システムによって強制される前に発生します。たとえば、メモリ制限を超えたためにアプリがシステムによって強制終了される前に、デベロッパーがデバッグデータを収集するのに役立ちます。

val profilingManager =
    applicationContext.getSystemService(ProfilingManager::class.java)
val triggers = ArrayList<ProfilingTrigger>()
triggers.add(ProfilingTrigger.Builder(ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
val mainExecutor: Executor = Executors.newSingleThreadExecutor()
val resultCallback = Consumer<ProfilingResult> { profilingResult ->
    if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
        // upload profile result to server for further analysis
        setupProfileUploadWorker(profilingResult.resultFilePath)
    }
    profilingManager.registerForAllProfilingResults(mainExecutor,
                                                    resultCallback)
    profilingManager.addProfilingTriggers(triggers)
}

JobDebugInfo API

Android 17 introduces new JobDebugInfo APIs to help developers debug their JobScheduler jobs--why they aren't running, how long they ran for, and other aggregated information.

The first method of the expanded JobDebugInfo APIs is getPendingJobReasonStats(), which returns a map of reasons why the job was in a pending execution state and their respective cumulative pending durations. This method joins the getPendingJobReasonsHistory() and getPendingJobReasons() methods to give you insight into why a scheduled job is not running as expected, but simplifies information retrieval by making both duration and job reason available in a single method.

For example, for a specified jobId, the method might return PENDING_JOB_REASON_CONSTRAINT_CHARGING and a duration of 60000 ms, indicating the job was pending for 60000ms due to the charging constraint not being satisfied.

allow-while-idle アラームのリスナーサポートによりウェイクロックを削減

Android 17 introduces a new variant of AlarmManager.setExactAndAllowWhileIdle that accepts an OnAlarmListener instead of a PendingIntent. This new callback-based mechanism is ideal for apps that currently rely on continuous wakelocks to perform periodic tasks, such as messaging apps maintaining socket connections.

プライバシー

Android 17 には、ユーザーのプライバシーを強化するための次の新機能が搭載されています。

Encrypted Client Hello（ECH）プラットフォームのサポート

Android 17 introduces platform support for Encrypted Client Hello (ECH), a significant privacy enhancement for network communications. ECH is a TLS 1.3 extension that encrypts the Server Name Indication (SNI) during the initial TLS handshake. This encryption helps protect user privacy by making it more difficult for network intermediaries to identify the specific domain an app is connecting to.

The platform now includes the necessary APIs for networking libraries to implement ECH. This includes new capabilities in DnsResolver to query for HTTPS DNS records containing ECH configurations, and new methods in Conscrypt's SSLEngines and SSLSockets to enable ECH by passing in these configurations when connecting to a domain. Developers can configure ECH preferences, such as enabling it opportunistically or mandating its use, through the new <domainEncryption> element within the Network Security Configuration file, applicable globally or on a per-domain basis.

Popular networking libraries such as HttpEngine, WebView, and OkHttp are expected to integrate these platform APIs in future updates, making it easier for apps to adopt ECH and enhance user privacy.

For more information, see the Encrypted Client Hello documentation.

Android 連絡先選択ツール

Android 連絡先選択ツールは、ユーザーがアプリと連絡先を共有するための標準化されたブラウジング可能なインターフェースです。Android 17（API レベル 37）以降を搭載したデバイスで利用できるこの選択ツールは、広範な READ_CONTACTS 権限に代わるプライバシーの保護に配慮した選択肢となります。アプリは、ユーザーのアドレス帳全体へのアクセスをリクエストするのではなく、電話番号やメールアドレスなど、必要なデータフィールドを指定し、ユーザーが共有する特定の連絡先を選択します。これにより、アプリは選択したデータへの読み取りアクセスのみを許可され、UI を構築または維持することなく、組み込みの検索、プロファイルの切り替え、複数選択機能により、一貫したユーザーエクスペリエンスを提供しながら、きめ細かい制御を実現できます。

詳しくは、連絡先選択ツールのドキュメントをご覧ください。

セキュリティ

Android 17 では、デバイスとアプリのセキュリティを強化するための次の新機能が追加されています。

Android の高度な保護機能モード（AAPM）

Android の高度な保護モードは、Android ユーザーに強力な新しいセキュリティ機能を提供し、ユーザー（特にリスクの高いユーザー）を高度な攻撃から保護するうえで大きな進歩となります。オプトイン機能として設計された AAPM は、ユーザーがいつでもオンにできる単一の構成設定で有効になり、セキュリティ保護の意見の強いセットが適用されます。

これらのコア構成には、提供元不明のアプリのインストール（サイドローディング）のブロック、USB データシグナリングの制限、Google Play プロテクトのスキャン義務付けが含まれており、デバイスの攻撃対象領域を大幅に削減します。デベロッパーは AdvancedProtectionManager API を使用してこの機能と統合し、モードのステータスを検出できます。これにより、ユーザーがオプトインしたときに、アプリケーションが自動的にセキュリティ強化された状態に移行したり、リスクの高い機能を制限したりできるようになります。

PQC APK 署名

Android now supports a hybrid APK signature scheme to future-proof your app's signing identity against the potential threat of attacks that make use of quantum computing. This feature introduces a new APK Signature Scheme, which lets you pair a classical signing key (such as RSA or EC) with a new post-quantum cryptography (PQC) algorithm (ML-DSA).

This hybrid approach ensures your app remains secure against future quantum attacks while maintaining full backward compatibility with older Android versions and devices that rely on classical signature verification.

Impact on developers

Apps using Play App Signing: If you use Play App Signing, you can wait for Google Play to give you the option to upgrade a hybrid signature using a PQC key generated by Google Play, ensuring your app is protected without requiring manual key management.
Apps using self-managed keys: Developers who manage their own signing keys can utilize updated Android build tools (like apksigner) to rotate to a hybrid identity, combining a PQC key with a new classical key. (You must create a new classical key, you cannot reuse the older one.)

接続

Android 17 では、デバイスとアプリの接続を強化するための次の機能が追加されています。

制約付き衛星ネットワーク

Implements optimizations to enable apps to function effectively over low-bandwidth satellite networks.

ユーザーエクスペリエンスとシステム UI

Android 17 には、ユーザーエクスペリエンスを向上させるための次の変更が含まれています。

専用のアシスタント音量ストリーム

Android 17 では、アシスタントアプリ専用のアシスタント音量ストリームが導入され、 USAGE_ASSISTANTで再生できるようになりました。この変更により、アシスタントの音声が標準のメディアストリームから分離され、ユーザーは両方の音量を個別に制御できるようになります。これにより、アシスタントの応答の可聴性を維持しながらメディアの再生をミュートしたり、その逆の操作を行ったりできます。

新しい MODE_ASSISTANT_CONVERSATION 音声モードにアクセスできるアシスタントアプリは、音量制御の一貫性をさらに向上させることができます。アシスタントアプリはこのモードを使用して、アクティブなアシスタントセッションに関するヒントをシステムに提供できます。これにより、アクティブな USAGE_ASSISTANT 再生の外部または接続された Bluetooth 周辺機器を使用して、アシスタントストリームを制御できます。

引き継ぎ

Handoff は、Android 17 に搭載される新しい機能と API です。アプリデベロッパーは、この機能と API を統合して、ユーザーにクロスデバイスの継続性を提供できます。ユーザーは、1 つの Android デバイスでアプリアクティビティを開始し、別の Android デバイスに移行できます。Handoff は、ユーザーのデバイスのバックグラウンドで実行され、受信デバイスのランチャーやタスクバーなどのさまざまなエントリポイントを介して、ユーザーの近くにある他のデバイスで使用可能なアクティビティを表示します。

受信デバイスに同じネイティブ Android アプリがインストールされていて使用可能な場合、アプリは Handoff を指定してそのアプリを起動できます。アプリからアプリへのフローでは、ユーザーは指定されたアクティビティにディープリンクされます。または、アプリからウェブへの Handoff をフォールバックオプションとして提供するか、URL Handoff で直接実装することもできます。

Handoff のサポートは、アクティビティごとに実装されます。Handoff を有効にするには、アクティビティのメソッドを呼び出します。setHandoffEnabled()受信デバイスで再作成されたアクティビティが適切な状態を復元できるように、Handoff とともに追加のデータを渡す必要がある場合があります。Implement the onHandoffActivityDataRequested() コールバックを実装して、 HandoffActivityDataオブジェクトを返します。これには、Handoff が受信デバイスでアクティビティを処理して再作成する方法を指定する詳細情報が含まれます。

ライブアップデート - セマンティックカラー API

With Android 17, Live Update launches the Semantic Coloring APIs to support colors with universal meaning.

The following classes support semantic coloring:

Coloring

Green: Associated with safety. This color should be used for the case where it lets people know you are in the safe situation.
Orange: For designating caution and marking physical hazards. This color should be used in the situation where users need to pay attention to set better protection setting.
Red: Generally indicates danger, stop. It should be presented for the case where need people's attention urgently.
Blue: Neutral color for content that is informational and should stand out from other content.

The following example shows how to apply semantic styles to text in a notification:

  val ssb = SpannableStringBuilder()
        .append("Colors: ")
        .append("NONE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_UNSPECIFIED), 0)
        .append(", ")
        .append("INFO", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_INFO), 0)
        .append(", ")
        .append("SAFE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_SAFE), 0)
        .append(", ")
        .append("CAUTION", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_CAUTION), 0)
        .append(", ")
        .append("DANGER", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_DANGER), 0)

    Notification.Builder(context, channelId)
          .setSmallIcon(R.drawable.ic_icon)
          .setContentTitle("Hello World!")
          .setContentText(ssb)
          .setOngoing(true)
              .setRequestPromotedOngoing(true)

Android 17 用の UWB ダウンリンク TDoA API

Downlink Time Difference of Arrival (DL-TDoA) ranging lets a device determine its position relative to multiple anchors by measuring the relative arrival times of signals.

The following snippet demonstrates how to initialize the Ranging Manager, verify device capabilities, and start a DL-TDoA session:

Kotlin

class RangingApp {

    fun initDlTdoa(context: Context) {
        // Initialize the Ranging Manager
        val rangingManager = context.getSystemService(RangingManager::class.java)

        // Register for device capabilities
        val capabilitiesCallback = object : RangingManager.RangingCapabilitiesCallback {
            override fun onRangingCapabilities(capabilities: RangingCapabilities) {
                // Make sure Dl-TDoA is supported before starting the session
                if (capabilities.uwbCapabilities != null && capabilities.uwbCapabilities!!.isDlTdoaSupported) {
                    startDlTDoASession(context)
                }
            }
        }
        rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback)
    }

    fun startDlTDoASession(context: Context) {

        // Initialize the Ranging Manager
        val rangingManager = context.getSystemService(RangingManager::class.java)

        // Create session and configure parameters
        val executor = Executors.newSingleThreadExecutor()
        val rangingSession = rangingManager.createRangingSession(executor, RangingSessionCallback())
        val rangingRoundIndexes = byteArrayOf(0)
        val config: ByteArray = byteArrayOf() // OOB config data
        val params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes)

        val rangingDevice = RangingDevice.Builder().build()
        val rawTagDevice = RawRangingDevice.Builder()
            .setRangingDevice(rangingDevice)
            .setDlTdoaRangingParams(params)
            .build()

        val dtTagConfig = RawDtTagRangingConfig.Builder(rawTagDevice).build()

        val preference = RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
            .setSessionConfig(SessionConfig.Builder().build())
            .build()

        // Start the ranging session
        rangingSession.start(preference)
    }
}

private class RangingSessionCallback : RangingSession.Callback {
    override fun onDlTdoaResults(peer: RangingDevice, measurement: DlTdoaMeasurement) {
        // Process measurement results here
    }
}

Java

public class RangingApp {

    public void initDlTdoa(Context context) {

        // Initialize the Ranging Manager
        RangingManager rangingManager = context.getSystemService(RangingManager.class);

        // Register for device capabilities
        RangingManager.CapabilitiesCallback capabilitiesCallback = new RangingManager.RangingCapabilitiesCallback() {
            @Override
            public void onRangingCapabilities(RangingCapabilities capabilities) {
                // Make sure Dl-TDoA is supported before starting the session
                if (capabilities.getUwbCapabilities() != null && capabilities.getUwbCapabilities().isDlTdoaSupported()) {
                    startDlTDoASession(context);
                }
            }
        };
        rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback);
    }

    public void startDlTDoASession(Context context) {
        RangingManager rangingManager = context.getSystemService(RangingManager.class);

        // Create session and configure parameters
        Executor executor = Executors.newSingleThreadExecutor();
        RangingSession rangingSession = rangingManager.createRangingSession(executor, new RangingSessionCallback());
        byte[] rangingRoundIndexes = new byte[] {0};
        byte[] config = new byte[0]; // OOB config data
        DlTdoaRangingParams params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes);

        RangingDevice rangingDevice = new RangingDevice.Builder().build();
        RawRangingDevice rawTagDevice = new RawRangingDevice.Builder()
                .setRangingDevice(rangingDevice)
                .setDlTdoaRangingParams(params)
                .build();

        RawDtTagRangingConfig dtTagConfig = new RawDtTagRangingConfig.Builder(rawTagDevice).build();

        RangingPreference preference = new RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
                .setSessionConfig(new SessionConfig.Builder().build())
                .build();

        // Start the ranging session
        rangingSession.start(preference);
    }

    private static class RangingSessionCallback implements RangingSession.Callback {

        @Override
        public void onDlTdoaResults(RangingDevice peer, DlTdoaMeasurement measurement) {
            // Process measurement results here
        }
    }
}

Out-of-Band (OOB) Configurations

The following snippet provides an example of DL-TDoA OOB configuration data for Wi-Fi and BLE:

Java

// Wifi Configuration
byte[] wifiConfig = {
    (byte) 0xDD, (byte) 0x2D, (byte) 0x5A, (byte) 0x18, (byte) 0xFF, // Header
    (byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
    (byte) 0x02, (byte) 0x00, // Profile ID
    (byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
    (byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
    (byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
    (byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
    (byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
    (byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
    (byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
    (byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01  // Session ID
};

// BLE Configuration
byte[] bleConfig = {
    (byte) 0x2D, (byte) 0x16, (byte) 0xF4, (byte) 0xFF, // Header
    (byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
    (byte) 0x02, (byte) 0x00, // Profile ID
    (byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
    (byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
    (byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
    (byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
    (byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
    (byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
    (byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
    (byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01  // Session ID
};

If you can't use an OOB configuration because it is missing, or if you need to change default values that aren't in the OOB config, you can build parameters with DlTdoaRangingParams.Builder as shown in the following snippet. You can use these parameters in place of DlTdoaRangingParams.createFromFiraConfigPacket():

Kotlin

val dlTdoaParams = DlTdoaRangingParams.Builder(1)
    .setComplexChannel(UwbComplexChannel.Builder()
            .setChannel(9).setPreambleIndex(10).build())
    .setDeviceAddress(deviceAddress)
    .setSessionKeyInfo(byteArrayOf(0x01, 0x02, 0x03, 0x04))
    .setRangingIntervalMillis(240)
    .setSlotDuration(UwbRangingParams.DURATION_2_MS)
    .setSlotsPerRangingRound(20)
    .setRangingRoundIndexes(byteArrayOf(0x01, 0x05))
    .build()

Java

DlTdoaRangingParams dlTdoaParams = new DlTdoaRangingParams.Builder(1)
    .setComplexChannel(new UwbComplexChannel.Builder()
            .setChannel(9).setPreambleIndex(10).build())
    .setDeviceAddress(deviceAddress)
    .setSessionKeyInfo(new byte[]{0x01, 0x02, 0x03, 0x04})
    .setRangingIntervalMillis(240)
    .setSlotDuration(UwbRangingParams.DURATION_2_MS)
    .setSlotsPerRangingRound(20)
    .setRangingRoundIndexes(new byte[]{0x01, 0x05})
    .build();

機能と API コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

コア機能

新しい ProfilingManager トリガー

アプリの異常のプロファイリング トリガー

JobDebugInfo API

allow-while-idle アラームのリスナー サポートによりウェイクロックを削減

プライバシー

Encrypted Client Hello（ECH）プラットフォームのサポート

Android 連絡先選択ツール

セキュリティ

Android の高度な保護機能モード（AAPM）

PQC APK 署名

Impact on developers

接続

制約付き衛星ネットワーク

ユーザー エクスペリエンスとシステム UI

専用のアシスタント音量ストリーム

引き継ぎ

ライブアップデート - セマンティック カラー API

Coloring

Android 17 用の UWB ダウンリンク TDoA API

Kotlin

Java

Out-of-Band (OOB) Configurations

Java

Kotlin

Java

機能と API

アプリの異常のプロファイリングトリガー

allow-while-idle アラームのリスナーサポートによりウェイクロックを削減

ユーザーエクスペリエンスとシステム UI

ライブアップデート - セマンティックカラー API