機能と API

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

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

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

• Android 17 をターゲットとするアプリに影響する動作の変更点
• targetSdkVersion に関係なく、すべてのアプリに影響する動作の変更点。

注: このページでは、特に重要な新機能の一部を紹介しています。詳しくは、Android 17 リリースノートをご覧ください。

コア機能

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

新しい ProfilingManager トリガー

Android 17 向 ProfilingManager 添加了多个新的系统触发器，可帮助您收集深入的数据来调试性能问题。

新增的触发条件包括：

• TRIGGER_TYPE_COLD_START：触发器在应用冷启动期间触发。它会在响应中同时提供调用堆栈样本和系统轨迹。
• TRIGGER_TYPE_OOM：当应用抛出 OutOfMemoryError 并提供 Java 堆转储作为响应时，会触发此事件。
• TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE：当应用因 CPU 使用率异常过高而被终止时，系统会触发此事件，并提供调用堆栈样本作为响应。

如需了解如何设置系统触发器，请参阅有关基于触发器的分析以及如何检索和分析分析数据的文档。

JobDebugInfo API

Android 17 では、デベロッパーが JobScheduler ジョブのデバッグに役立つ新しい JobDebugInfo API が導入されました。ジョブが実行されない理由、実行時間、その他の集計情報などを確認できます。

拡張された JobDebugInfo API の最初のメソッドは getPendingJobReasonStats() です。これは、ジョブが実行待ち状態だった理由と、それぞれの累積待ち時間を示すマップを返します。このメソッドは、getPendingJobReasonsHistory() メソッドと getPendingJobReasons() メソッドを結合して、スケジュールされたジョブが想定どおりに実行されない理由を把握できるようにします。また、期間とジョブの理由の両方を 1 つのメソッドで使用できるようにすることで、情報取得を簡素化します。

たとえば、指定された jobId に対して、メソッドは PENDING_JOB_REASON_CONSTRAINT_CHARGING と 60000 ミリ秒の期間を返すことがあります。これは、充電の制約が満たされなかったため、ジョブが 60000 ミリ秒間保留されたことを示します。

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

Android 17 引入了 AlarmManager.setExactAndAllowWhileIdle 的新变体，该变体 接受 OnAlarmListener 而不是 PendingIntent。这种基于回调的新机制非常适合目前依赖于连续唤醒锁来执行定期任务的应用，例如维护套接字连接的消息传递应用。

プライバシー

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

Android の連絡先選択ツール

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

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

セキュリティ

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

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

Android 高级保护模式为 Android 用户提供了一套强大的新安全功能，标志着在保护用户（尤其是面临较高风险的用户）免遭复杂攻击方面迈出了重要一步。AAPM 是一项选择启用功能，只需进行一项配置设置即可激活。用户可以随时启用该功能，以应用一套主观的安全保护措施。

这些核心配置包括：禁止安装未知来源的应用（旁加载）、限制 USB 数据信号传输，以及强制执行 Google Play 保护机制扫描，从而显著减小设备的攻击面。 开发者可以使用 AdvancedProtectionManager API 与此功能集成，以检测模式的状态，从而使应用能够在用户选择启用此模式时自动采用强化型安全姿态或限制高风险功能。

PQC APK 署名

Android 现在支持混合 APK 签名方案，以保护应用的签名身份免受利用量子计算的潜在攻击威胁。此功能引入了一种新的 APK 签名方案，可让您将经典签名密钥（例如 RSA 或 EC）与新的后量子密码 (PQC) 算法 (ML-DSA) 配对。

这种混合方法可确保您的应用在未来免受量子攻击，同时与依赖经典签名验证的旧版 Android 版本和设备保持完全向后兼容。

注意： 您需要创建一个新的传统签名密钥，以便与 PQC 密钥配对。您无法重复使用混合之前的经典签名密钥。

对开发者的影响

• 使用 Play 应用签名的应用 ：如果您使用 Play 应用签名，可以等待 Google Play 为您提供使用 Google Play 生成的 PQC 密钥升级混合签名的选项，确保您的应用受到保护，而无需手动管理密钥。
• 使用自行管理的密钥的应用 ：自行管理签名密钥的开发者可以利用更新后的 Android build 工具（例如 apksigner）轮替到混合身份，将 PQC 密钥与新的经典密钥相结合。（您必须创建新的经典密钥，无法重复使用旧密钥。）

接続

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

制約のある衛星ネットワーク

低帯域幅の衛星ネットワークでアプリが効果的に機能するように最適化を実装します。

注: この機能は、Android 16 QPR2 四半期リリースでリリースされました。詳しくは、制約のある衛星ネットワーク向けに開発するをご覧ください。

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

Android 17 には、ユーザー エクスペリエンスを改善するための以下の変更が含まれています。

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

Android 17 针对 Google 助理应用引入了专用的 Google 助理音量音频流，以便使用 USAGE_ASSISTANT 进行播放。此项变更将 Google 助理音频与标准媒体音频流分离，让用户可以单独控制这两个音频流的音量。这样一来，您就可以实现以下场景：在将媒体播放静音的同时，保持 Google 助理回答的可听性，反之亦然。

有权访问新的 MODE_ASSISTANT_CONVERSATION 音频模式的助理应用可以进一步提高音量控制的一致性。助理应用可以使用此模式向系统提供有关有效助理会话的提示，确保可以在有效 USAGE_ASSISTANT 播放之外或通过连接的蓝牙外围设备控制助理流。

ハンドオフ

Handoff is a new feature and API coming to Android 17 that app developers can integrate with to provide cross-device continuity for their users. It allows the user to start an app activity on one Android device and transition it to another Android device. Handoff runs in the background of a user's device and surfaces available activities from the user's other nearby devices through various entry points, like the launcher and taskbar, on the receiving device.

Apps can designate Handoff to launch the same native Android app, if it is installed and available on the receiving device. In this app-to-app flow, the user is deep-linked to the designated activity. Alternatively, app-to-web Handoff can be offered as a fallback option or directly implemented with URL Handoff.

Handoff support is implemented on a per-activity basis. To enable Handoff, call the setHandoffEnabled() method for the activity. Additional data may need to be passed along with the handoff so the recreated activity on the receiving device can restore appropriate state. Implement the onHandoffActivityRequested() callback to return a HandoffActivityData object which contains details that specify how Handoff should handle and recreate the activity on the receiving device.

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

Android 17 では、ライブ アップデートを通じて、普遍的な意味を持つ色を サポートするセマンティック カラー API がリリースされます。

次のクラスはセマンティック カラーをサポートしています。

• Notification
• Notification.Metric
• Notification.ProgressStyle.Point
• Notification.ProgressStyle.Segment

色の意味

• 緑: 安全に関連付けられています。 安全な状況であることをユーザーに知らせる場合に使用します。
• オレンジ: 注意を促し、物理的な危険をマークするために使用します。この色は、ユーザーが保護設定を適切に行うために注意を払う必要がある状況で 使用してください。
• 赤: 一般的に危険、停止を示します。緊急にユーザーの注意を引く必要がある場合に表示します。
• 青: 情報提供を目的とし、他のコンテンツと区別する必要があるコンテンツに使用するニュートラルな色です。

次の例は、通知のテキストにセマンティック スタイルを適用する方法を示しています。

  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

ダウンリンク到達時間差（DL-TDoA）測距により、デバイスは信号の相対到達時間を測定することで、複数のアンカーに対する相対位置を特定できます。

次のスニペットは、Ranging Manager を初期化し、デバイスの機能を検証して、DL-TDoA セッションを開始する方法を示しています。

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.CapabilitiesCallback {
            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 = intArrayOf(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.CapabilitiesCallback() {
            @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());
        int[] rangingRoundIndexes = new int[] {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
        }
    }
}

アウトオブバンド（OOB）構成

次のスニペットは、Wi-Fi と BLE の DL-TDoA OOB 構成データの例を示しています。

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
};

OOB 構成がないために使用できない場合や、OOB 構成にないデフォルト値を変更する必要がある場合は、次のスニペットに示すように、DlTdoaRangingParams.Builder を使用してパラメータをビルドできます。これらのパラメータは 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();