Tính năng và API

Android 17 mang đến cho nhà phát triển các tính năng và API mới tuyệt vời. Các phần sau đây tóm tắt những tính năng này để giúp bạn làm quen với các API liên quan.

Để biết danh sách chi tiết về các API mới, đã được sửa đổi, cũng như đã bị xoá, hãy đọc báo cáo điểm khác biệt về API. Để biết thông tin chi tiết về các API mới, vui lòng truy cập Tài liệu tham khảo API cho Android (các API mới được làm nổi bật).

Bạn cũng nên xem xét những khía cạnh mà các thay đổi về nền tảng có thể ảnh hưởng đến ứng dụng của mình. Để biết thêm thông tin, hãy xem các trang sau:

Chức năng cốt lõi

Android 17 bổ sung các tính năng mới sau đây liên quan đến chức năng cốt lõi của Android.

Điều kiện kích hoạt ProfilingManager mới

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

新触发器包括：

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

应用异常的性能分析触发器

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

API JobDebugInfo

Android 17 giới thiệu các API JobDebugInfo mới để giúp nhà phát triển gỡ lỗi các công việc JobScheduler – lý do công việc không chạy, thời gian chạy và các thông tin tổng hợp khác.

Phương thức đầu tiên của các API JobDebugInfo mở rộng là getPendingJobReasonStats(). Phương thức này trả về một bản đồ các lý do khiến công việc ở trạng thái chờ thực thi và thời lượng chờ tích luỹ tương ứng . Phương thức này kết hợp với các phương thức getPendingJobReasonsHistory() và getPendingJobReasons() để giúp bạn hiểu rõ lý do một lệnh theo lịch biểu không chạy như mong đợi, nhưng đơn giản hoá việc truy xuất thông tin bằng cách cung cấp cả thời lượng và lý do công việc trong một phương thức.

Ví dụ: đối với một jobId được chỉ định, phương thức này có thể trả về PENDING_JOB_REASON_CONSTRAINT_CHARGING và thời lượng là 60000 ms, cho biết công việc đang chờ trong 60000 ms do không đáp ứng được ràng buộc về việc sạc.

Giảm khoá đánh thức bằng tính năng hỗ trợ trình nghe cho báo thức cho phép trong khi thiết bị ở trạng thái rảnh

Android 17 giới thiệu một biến thể mới của AlarmManager.setExactAndAllowWhileIdle mà chấp nhận một OnAlarmListener thay vì một PendingIntent. Cơ chế mới dựa trên lệnh gọi lại này rất phù hợp với những ứng dụng hiện dựa vào khoá đánh thức liên tục để thực hiện các tác vụ định kỳ, chẳng hạn như các ứng dụng nhắn tin duy trì kết nối socket.

Quyền riêng tư

Android 17 bao gồm các tính năng mới sau đây để cải thiện quyền riêng tư của người dùng.

Hỗ trợ nền tảng Encrypted Client Hello (ECH)

Android 17 引入了对加密客户端 Hello (ECH) 的平台支持，这是对网络通信的一项重大隐私增强功能。ECH 是一项 TLS 1.3 扩展，可在初始 TLS 握手期间加密服务器名称指示 (SNI)。这种加密有助于保护用户隐私，因为它可以让网络中介更难识别应用连接到的特定网域。

该平台现在包含网络库实现 ECH 所需的 API。这包括 DnsResolver 中的新功能，用于查询包含 ECH 配置的 HTTPS DNS 记录；以及 Conscrypt 的 SSLEngine 和 SSLSocket 中的新方法，用于在连接到网域时传入这些配置来启用 ECH。开发者可以通过网络安全配置文件中的新 <domainEncryption> 元素来配置 ECH 偏好设置，例如机会性地启用 ECH 或强制使用 ECH，这些设置可全局应用，也可按网域应用。

预计 HttpEngine、WebView 和 OkHttp 等热门联网库将在未来的更新中集成这些平台 API，从而使应用能够更轻松地采用 ECH 并增强用户隐私保护。

如需了解详情，请参阅加密的客户端 Hello 文档。

Trình chọn người liên hệ cho Android

Android 联系人选择工具是一个标准化的可浏览界面，供用户与您的应用分享联系人。该选择工具适用于搭载 Android 17（API 级别 37）或更高版本的设备，可提供一种可保护隐私的替代方案，以取代广泛的 READ_CONTACTS 权限。您的应用无需请求访问用户的整个地址簿，而是指定所需的数据字段（例如电话号码或电子邮件地址），然后用户选择要分享的特定联系人。这样，您的应用便只能读取所选数据，从而确保精细控制，同时提供一致的用户体验，并具有内置搜索、个人资料切换和多选功能，而无需构建或维护界面。

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

Bảo mật

Android 17 bổ sung các tính năng mới sau đây để cải thiện tính bảo mật của thiết bị và ứng dụng.

Chế độ Bảo vệ nâng cao trên Android (AAPM)

Chế độ Bảo vệ nâng cao của Android cung cấp cho người dùng Android một bộ tính năng bảo mật mới mạnh mẽ, đánh dấu một bước tiến quan trọng trong việc bảo vệ người dùng (đặc biệt là những người dùng có nguy cơ cao hơn) khỏi các cuộc tấn công tinh vi. Được thiết kế như một tính năng chọn sử dụng, AAPM được kích hoạt bằng một chế độ cài đặt cấu hình duy nhất mà người dùng có thể bật bất cứ lúc nào để áp dụng một bộ biện pháp bảo vệ bảo mật theo ý kiến riêng.

Các cấu hình cốt lõi này bao gồm việc chặn cài đặt ứng dụng từ các nguồn không xác định (tải ứng dụng bên ngoài), hạn chế tín hiệu dữ liệu USB và bắt buộc quét bằng Google Play Protect, giúp giảm đáng kể phạm vi tấn công của thiết bị. Nhà phát triển có thể tích hợp với tính năng này bằng cách sử dụng API AdvancedProtectionManager để phát hiện trạng thái của chế độ, cho phép các ứng dụng tự động áp dụng trạng thái bảo mật tăng cường hoặc hạn chế chức năng có rủi ro cao khi người dùng đã chọn sử dụng.

Ký APK PQC

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

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

对开发者的影响

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

Khả năng kết nối

Android 17 bổ sung các tính năng sau đây để cải thiện khả năng kết nối của thiết bị và ứng dụng.

Mạng vệ tinh bị hạn chế

Triển khai các hoạt động tối ưu hoá để cho phép ứng dụng hoạt động hiệu quả trên các mạng vệ tinh có băng thông thấp.

Trải nghiệm người dùng và giao diện người dùng hệ thống

Android 17 bao gồm các thay đổi sau đây để cải thiện trải nghiệm người dùng.

Luồng âm lượng riêng cho Trợ lý

Android 17 giới thiệu một luồng âm lượng riêng cho Trợ lý đối với các ứng dụng trợ lý, để phát bằng USAGE_ASSISTANT. Thay đổi này tách âm thanh của Trợ lý khỏi luồng nội dung nghe nhìn tiêu chuẩn, giúp người dùng có thể kiểm soát riêng cả hai âm lượng. Điều này cho phép các trường hợp như tắt tiếng phát nội dung nghe nhìn trong khi vẫn duy trì khả năng nghe được các câu trả lời của Trợ lý và ngược lại.

Các ứng dụng Trợ lý có quyền truy cập vào chế độ âm thanh MODE_ASSISTANT_CONVERSATION mới có thể cải thiện hơn nữa tính nhất quán của việc kiểm soát âm lượng. Các ứng dụng Trợ lý có thể sử dụng chế độ này để cung cấp gợi ý cho hệ thống về một phiên Trợ lý đang hoạt động, đảm bảo rằng luồng Trợ lý có thể được kiểm soát bên ngoài quá trình phát USAGE_ASSISTANT đang hoạt động hoặc bằng các thiết bị ngoại vi Bluetooth được kết nối.

Handoff

Handoff là một tính năng và API mới sắp có trên Android 17. Các nhà phát triển ứng dụng có thể tích hợp tính năng này để mang đến trải nghiệm liền mạch trên nhiều thiết bị cho người dùng. Tính năng này cho phép người dùng bắt đầu một hoạt động trong ứng dụng trên một thiết bị Android và chuyển hoạt động đó sang một thiết bị Android khác. Tính năng Handoff chạy ở chế độ nền trên thiết bị của người dùng và hiển thị các hoạt động có sẵn từ các thiết bị khác ở gần của người dùng thông qua nhiều điểm truy cập, chẳng hạn như trình chạy và thanh tác vụ, trên thiết bị nhận.

Các ứng dụng có thể chỉ định tính năng Bàn giao để khởi chạy cùng một ứng dụng Android gốc, nếu ứng dụng đó được cài đặt và có trên thiết bị nhận. Trong quy trình từ ứng dụng đến ứng dụng này, người dùng được liên kết sâu đến hoạt động được chỉ định. Ngoài ra, bạn có thể cung cấp tính năng Bàn giao từ ứng dụng sang web dưới dạng lựa chọn dự phòng hoặc triển khai trực tiếp bằng tính năng Bàn giao URL.

Tính năng handoff được triển khai dựa trên từng hoạt động. Để bật tính năng Handoff, hãy gọi phương thức setHandoffEnabled() cho hoạt động. Bạn có thể cần chuyển thêm dữ liệu cùng với quá trình chuyển giao để hoạt động được tạo lại trên thiết bị nhận có thể khôi phục trạng thái thích hợp. Triển khai lệnh gọi lại onHandoffActivityDataRequested() để trả về một đối tượng HandoffActivityData chứa thông tin chi tiết chỉ định cách Handoff nên xử lý và tạo lại hoạt động trên thiết bị nhận.

Cập nhật trực tiếp – API màu ngữ nghĩa

Với Android 17, Live Update (Cập nhật trực tiếp) sẽ ra mắt Semantic Coloring API (API tô màu theo ngữ nghĩa) để hỗ trợ các màu có ý nghĩa phổ quát.

Các lớp sau đây hỗ trợ tính năng tô màu theo ngữ nghĩa:

Tô màu

  • Màu xanh lục: Liên quan đến sự an toàn. Bạn nên dùng màu này trong trường hợp muốn cho mọi người biết bạn đang ở trong tình huống an toàn.
  • Màu cam: Dùng để chỉ sự thận trọng và đánh dấu các mối nguy hiểm về thể chất. Bạn nên dùng màu này trong trường hợp người dùng cần chú ý để đặt biện pháp bảo vệ tốt hơn.
  • Đỏ: Thường biểu thị nguy hiểm, dừng lại. Bạn nên trình bày thông báo này trong trường hợp cần thu hút sự chú ý của mọi người một cách khẩn cấp.
  • Xanh dương: Màu trung tính cho nội dung mang tính thông tin và cần nổi bật so với nội dung khác.

Ví dụ sau đây cho thấy cách áp dụng kiểu ngữ nghĩa cho văn bản trong một thông báo:

  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)

API UWB Downlink-TDoA cho Android 17

下行链路到达时间差 (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.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
        }
    }
}

带外 (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();