Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

功能和 API

Android 17 面向开发者引入了一些出色的新功能和 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：检测系统性能异常，例如 binder 调用过多和内存用量过多。

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

应用异常性能分析触发器

Android 17 引入了设备端异常值检测服务，用于监控资源密集型行为和潜在的兼容性回归。此服务与 ProfilingManager 集成，可让您的应用接收由系统检测到的特定事件触发的性能分析工件。

使用 TRIGGER_TYPE_ANOMALY 触发器检测系统性能问题，例如 Binder 调用过多和内存用量过多。当应用超出操作系统定义的内存限制时，异常触发器会向开发者发送应用专属堆转储，帮助他们识别并解决内存问题。此外，对于过多的 binder 垃圾内容，异常触发器会提供 binder 事务的堆栈采样分析。

此 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.

通过监听器支持“空闲时允许”闹钟，减少唤醒锁定

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

隐私权

Android 17 包含以下新功能，可更好地保护用户隐私。

加密客户端 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 权限，从而保护隐私。您的应用无需请求访问用户的整个通讯簿，而是指定所需的数据字段（例如电话号码或邮箱），然后由用户选择要分享的特定联系人。这会向您的应用授予对所选数据的读取权限，从而确保精细控制，同时通过内置搜索、个人资料切换和多选功能提供一致的用户体验，而无需构建或维护界面。

如需了解详情，请参阅联系人选择工具文档。

安全

Android 17 添加了以下新功能，以提高设备和应用的安全性。

Android 高级保护模式 (AAPM)

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

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

PQC APK 签名

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

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

对开发者的影响

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

连接

Android 17 添加了以下功能，以改进设备和应用连接。

受限卫星网络

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

用户体验和系统界面

Android 17 包含以下旨在提升用户体验的变更。

专用 Google 助理音量流

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

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

Handoff

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 onHandoffActivityDataRequested() callback to return a HandoffActivityData object which contains details that specify how Handoff should handle and recreate the activity on the receiving device.

实时动态 - 语义颜色 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 Downlink-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

通过监听器支持“空闲时允许”闹钟，减少唤醒锁定

隐私权

加密客户端 Hello (ECH) 平台支持

Android 联系人选择工具

安全

Android 高级保护模式 (AAPM)

PQC APK 签名

对开发者的影响

连接

受限卫星网络

用户体验和系统界面

专用 Google 助理音量流

Handoff

实时动态 - 语义颜色 API

Coloring

适用于 Android 17 的 UWB Downlink-TDoA API

Kotlin

Java

Out-of-Band (OOB) Configurations

Java

Kotlin

Java

功能和 API