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:
- Các thay đổi về hành vi ảnh hưởng đến ứng dụng khi ứng dụng nhắm đến Android 17
- Các thay đổi về hành vi ảnh hưởng đến tất cả ứng dụng bất kể
targetSdkVersion.
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 bổ sung một số trình kích hoạt hệ thống mới cho ProfilingManager để giúp bạn thu thập dữ liệu chuyên sâu nhằm gỡ lỗi các vấn đề về hiệu suất.
Các điều kiện kích hoạt mới là:
TRIGGER_TYPE_COLD_START: Điều kiện kích hoạt xảy ra trong quá trình khởi động nguội ứng dụng. Thao tác này cung cấp cả mẫu ngăn xếp lệnh gọi và dấu vết hệ thống trong phản hồi.TRIGGER_TYPE_OOM: Điều kiện kích hoạt xảy ra khi một ứng dụng gửiOutOfMemoryErrorvà cung cấp một Java Heap Dump để phản hồi.TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: Điều kiện kích hoạt xảy ra khi một ứng dụng bị tắt do mức sử dụng CPU bất thường và quá mức, đồng thời cung cấp một mẫu ngăn xếp lệnh gọi để phản hồi.TRIGGER_TYPE_ANOMALY: Phát hiện các điểm bất thường về hiệu suất hệ thống, chẳng hạn như số lượng lệnh gọi liên kết quá mức và mức sử dụng bộ nhớ quá mức.
Để tìm hiểu cách thiết lập trình kích hoạt hệ thống, hãy xem tài liệu về phân tích hiệu suất dựa trên trình kích hoạt và cách truy xuất và phân tích dữ liệu phân tích hiệu suất.
Kích hoạt lập hồ sơ cho các điểm bất thường của ứng dụng
Android 17 giới thiệu một dịch vụ phát hiện điểm bất thường trên thiết bị, giúp theo dõi các hành vi tiêu tốn nhiều tài nguyên và khả năng tương thích có thể bị giảm. Được tích hợp với ProfilingManager, dịch vụ này cho phép ứng dụng của bạn nhận các cấu phần phần mềm lập hồ sơ do các sự kiện cụ thể mà hệ thống phát hiện được kích hoạt.
Sử dụng điều kiện kích hoạt TRIGGER_TYPE_ANOMALY để phát hiện các vấn đề về hiệu suất hệ thống, chẳng hạn như số lượng lệnh gọi liên kết quá mức và mức sử dụng bộ nhớ quá mức. Khi một ứng dụng vi phạm giới hạn bộ nhớ do hệ điều hành xác định, trình kích hoạt bất thường sẽ cho phép nhà phát triển nhận được các kết xuất heap dành riêng cho ứng dụng để giúp xác định và khắc phục các vấn đề về bộ nhớ. Ngoài ra, đối với tình trạng liên kết rác quá mức, trình kích hoạt điểm bất thường sẽ cung cấp một hồ sơ ảnh chụp nhanh tạo bằng cách lấy mẫu về các giao dịch liên kết.
Lệnh gọi lại API này xảy ra trước khi có bất kỳ hoạt động thực thi nào do hệ thống áp đặt. Ví dụ: việc này có thể giúp nhà phát triển thu thập dữ liệu gỡ lỗi trước khi hệ thống chấm dứt ứng dụng do vượt quá giới hạn bộ nhớ.
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 hỗ trợ nền tảng cho Encrypted Client Hello (ECH), một tính năng cải tiến đáng kể về quyền riêng tư cho hoạt động giao tiếp qua mạng. ECH là một tiện ích TLS 1.3 mã hoá Chỉ báo tên máy chủ (SNI) trong quá trình bắt tay TLS ban đầu. Phương thức mã hoá này giúp bảo vệ quyền riêng tư của người dùng bằng cách khiến các trung gian mạng khó xác định được miền cụ thể mà một ứng dụng đang kết nối.
Giờ đây, nền tảng này bao gồm các API cần thiết để các thư viện mạng triển khai ECH. Điều này bao gồm các chức năng mới trong DnsResolver để truy vấn các bản ghi DNS HTTPS có chứa cấu hình ECH, cũng như các phương thức mới trong SSLEngine và SSLSocket của Conscrypt để bật ECH bằng cách truyền các cấu hình này khi kết nối với một miền. Nhà phát triển có thể định cấu hình các lựa chọn ưu tiên về ECH, chẳng hạn như cho phép sử dụng tuỳ ý hoặc bắt buộc sử dụng ECH, thông qua phần tử <domainEncryption> mới trong tệp Cấu hình bảo mật mạng, áp dụng trên toàn cầu hoặc theo từng miền.
Các thư viện mạng phổ biến như HttpEngine, WebView và OkHttp dự kiến sẽ tích hợp các API nền tảng này trong các bản cập nhật sau này, giúp các ứng dụng dễ dàng áp dụng ECH và nâng cao quyền riêng tư của người dùng.
Để biết thêm thông tin, hãy xem tài liệu về Encrypted Client 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 hiện hỗ trợ lược đồ chữ ký APK kết hợp để bảo vệ danh tính ký của ứng dụng trước mối đe doạ tiềm ẩn từ các cuộc tấn công sử dụng điện toán lượng tử. Tính năng này giới thiệu một Lược đồ chữ ký APK mới, cho phép bạn ghép nối khoá ký cổ điển (chẳng hạn như RSA hoặc EC) với một thuật toán mật mã hậu lượng tử (PQC) mới (ML-DSA).
Phương pháp kết hợp này đảm bảo ứng dụng của bạn vẫn an toàn trước các cuộc tấn công lượng tử trong tương lai, đồng thời duy trì khả năng tương thích ngược hoàn toàn với các phiên bản và thiết bị Android cũ dựa vào quy trình xác minh chữ ký cổ điển.
Ảnh hưởng đối với nhà phát triển
- Ứng dụng sử dụng Tính năng ký ứng dụng của Play: Nếu sử dụng Tính năng ký ứng dụng của Play, bạn có thể đợi Google Play cung cấp cho bạn lựa chọn nâng cấp chữ ký kết hợp bằng khoá PQC do Google Play tạo, đảm bảo ứng dụng của bạn được bảo vệ mà không cần quản lý khoá theo cách thủ công.
- Ứng dụng sử dụng khoá do nhà phát triển tự quản lý: Những nhà phát triển tự quản lý khoá ký có thể sử dụng các công cụ xây dựng Android đã cập nhật (như apksigner) để chuyển sang danh tính kết hợp, kết hợp khoá PQC với một khoá cổ điển mới. (Bạn phải tạo một khoá cổ điển mới, không thể sử dụng lại khoá cũ.)
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ế
实现优化,使应用能够在低带宽卫星网络上有效运行。
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
在 Android 17 中,实时更新启动了语义着色 API,以支持具有通用含义的颜色。
以下类支持语义着色:
NotificationNotification.MetricNotification.ProgressStyle.PointNotification.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)
API UWB Downlink-TDoA cho Android 17
下行链路到达时间差 (DL-TDoA) 测距功能可让设备通过测量信号的相对到达时间来确定其相对于多个锚点的相对位置。
以下代码段演示了如何初始化 测距管理器、 验证设备功能以及启动 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();