يقدّم Android 17 ميزات وواجهات برمجة تطبيقات جديدة ورائعة للمطوّرين. تلخّص الأقسام التالية هذه الميزات لمساعدتك في البدء باستخدام واجهات برمجة التطبيقات ذات الصلة.
للحصول على قائمة مفصّلة بواجهات برمجة التطبيقات الجديدة والمعدَّلة والمُزالة، يُرجى قراءة تقرير مقارنة واجهات برمجة التطبيقات. للحصول على تفاصيل حول واجهات برمجة التطبيقات الجديدة، يُرجى الانتقال إلى مرجع واجهة برمجة تطبيقات Android. يتم تمييز واجهات برمجة التطبيقات الجديدة لتسهيل رؤيتها.
عليك أيضًا مراجعة المجالات التي قد تؤثر فيها تغييرات النظام الأساسي في تطبيقاتك. لمزيد من المعلومات، يُرجى الاطّلاع على الصفحات التالية:
- تغييرات في السلوك تؤثر في التطبيقات التي تستهدف Android 17
- تغييرات في السلوك تؤثر في جميع التطبيقات بغض النظر عن
targetSdkVersion
الوظيفة الأساسية
يضيف Android 17 الميزات الجديدة التالية المتعلقة بالوظيفة الأساسية لنظام Android.
عوامل التشغيل الجديدة في ProfilingManager
يضيف Android 17 عدة عوامل تشغيل جديدة على مستوى النظام إلى ProfilingManager لمساعدتك في جمع بيانات مفصّلة لتصحيح مشاكل الأداء.
في ما يلي عوامل التشغيل الجديدة:
TRIGGER_TYPE_COLD_START: يتم تشغيل المشغِّل أثناء تشغيل التطبيق على البارد. ويوفّر في الردّ نموذجًا لحزمة التنفيذ وتتبُّعًا للنظام.TRIGGER_TYPE_OOM: يتم تشغيل العامل عندما يعرض التطبيقOutOfMemoryErrorويوفّر تفريغًا لذاكرة Java المؤقتة في الردّ.TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: يتم تشغيل المشغّل عندما يتم إيقاف التطبيق بسبب الاستخدام غير الطبيعي والمفرط لوحدة المعالجة المركزية، ويوفّر نموذجًا لحزمة التنفيذ في الردّ.TRIGGER_TYPE_ANOMALY: يتم تشغيل العامل لرصد الحالات غير الطبيعية في أداء النظام، مثل عدد كبير من طلبات الإجراءات في Binder والاستخدام المفرط للذاكرة.
لفهم كيفية إعداد عامل تشغيل النظام، يمكنك الاطّلاع على المستندات حول إنشاء ملفات الأداء استنادًا إلى عوامل التشغيل وكيفية استرداد بيانات الأداء وتحليلها المستندات.
عامل تشغيل ملفات الأداء للحالات غير الطبيعية في التطبيق
يقدّم Android 17 خدمة لرصد الحالات غير الطبيعية على الجهاز فقط تراقب السلوكيات التي تستهلك الكثير من الموارد وحالات التراجع المحتملة في التوافق. تسمح هذه الخدمة لتطبيقك، عند دمجها
مع ProfilingManager، بتلقّي بيانات الأداء
التي يتم تشغيلها من خلال أحداث معيّنة يرصدها النظام.
استخدِم المشغِّل TRIGGER_TYPE_ANOMALY لرصد مشاكل في أداء النظام مثل عدد كبير من طلبات الإجراءات في Binder والاستخدام المفرط للذاكرة. عندما يخالف التطبيق حدود الذاكرة التي يحدّدها نظام التشغيل، يسمح عامل تشغيل الحالات غير الطبيعية للمطوّرين بتلقّي تفريغات لذاكرة التطبيق المؤقتة للمساعدة في تحديد مشاكل الذاكرة وحلّها. بالإضافة إلى ذلك، بالنسبة إلى عدد كبير من طلبات الإجراءات في Binder، يوفّر عامل تشغيل الحالات غير الطبيعية ملفًا شخصيًا لعينات مكدس طلبات الإجراءات بشأن معاملات Binder.
يحدث معاودة الاتصال بواجهة برمجة التطبيقات هذه قبل أي عمليات إنفاذ يفرضها النظام. على سبيل المثال، يمكن أن يساعد ذلك المطوّرين في جمع بيانات تصحيح الأخطاء قبل أن يوقف النظام التطبيق بسبب تجاوز حدود الذاكرة.
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
يقدّم الإصدار 17 من Android واجهات برمجة تطبيقات JobDebugInfo جديدة لمساعدة المطوّرين في تصحيح أخطاء مهام JobScheduler، مثل سبب عدم تنفيذها ومدة تنفيذها وغيرها من المعلومات المجمّعة.
الطريقة الأولى من واجهات برمجة التطبيقات الموسّعة JobDebugInfo هي
getPendingJobReasonStats()، والتي تعرض خريطة للأسباب التي أدّت إلى بقاء المهمة في
حالة التنفيذ المعلّق ومدة التنفيذ المعلّق التراكمية لكل سبب. تنضم هذه الطريقة إلى الطريقتَين getPendingJobReasonsHistory() وgetPendingJobReasons() لتزويدك بمعلومات حول سبب عدم تنفيذ مهمة مجدولة على النحو المتوقّع، ولكنّها تبسّط عملية استرداد المعلومات من خلال إتاحة كلّ من المدة وسبب المهمة في طريقة واحدة.
على سبيل المثال، بالنسبة إلى jobId محدّد، قد تعرض الطريقة PENDING_JOB_REASON_CONSTRAINT_CHARGING ومدة 60000 ملي ثانية، ما يشير إلى أنّ المهمة كانت في انتظار التنفيذ لمدة 60000 ملي ثانية بسبب عدم استيفاء شرط الشحن.
تقليل عمليات قفل التنشيط باستخدام ميزة متتبِّع المنبّهات التي يتم تفعيلها أثناء وضع غير مستخدَم من قِبل أي برنامج حاليًا
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)
يتيح الإصدار 17 من نظام التشغيل Android استخدام Encrypted Client Hello (ECH)، وهي ميزة مهمة لتحسين الخصوصية في ما يتعلّق باتصالات الشبكة. ECH هي إضافة إلى الإصدار 1.3 من بروتوكول TLS تشفّر الإشارة إلى اسم الخادم (SNI) أثناء تأكيد اتصال TLS الأوّلي. يساعد هذا التشفير في حماية خصوصية المستخدمين من خلال صعوبة تحديد الوسطاء في الشبكة للنطاق المحدّد الذي يتصل به التطبيق.
تتضمّن المنصة الآن واجهات برمجة التطبيقات اللازمة لمكتبات إنشاء الشبكات من أجل تنفيذ ECH. ويشمل ذلك إمكانات جديدة في DnsResolver للاستعلام عن سجلّات نظام أسماء النطاقات (DNS) عبر HTTPS التي تتضمّن إعدادات ECH، وطُرقًا جديدة في SSLEngines وSSLSockets من Conscrypt لتفعيل ECH من خلال تمرير هذه الإعدادات عند الاتصال بنطاق. يمكن للمطوّرين ضبط الإعدادات المفضَّلة لـ ECH، مثل تفعيلها بشكل انتهازي أو فرض استخدامها، من خلال العنصر الجديد <domainEncryption> ضمن ملف إعدادات أمان الشبكة، والذي يمكن تطبيقه على مستوى العالم أو على أساس كل نطاق.
من المتوقّع أن تدمج مكتبات الشبكات الشائعة، مثل HttpEngine وWebView وOkHttp، واجهات برمجة التطبيقات هذه في التحديثات المستقبلية، ما يسهّل على التطبيقات استخدام ECH وتعزيز خصوصية المستخدمين.
لمزيد من المعلومات، يُرجى الاطّلاع على مستندات Encrypted Client Hello.
أداة اختيار جهات الاتصال في Android
Android 联系人选择工具是一个标准化的可浏览界面,供用户与您的应用分享联系人。该选择工具适用于搭载 Android 17(API 级别 37)或更高版本的设备,可提供一种可保护隐私的替代方案,以取代广泛的 READ_CONTACTS 权限。您的应用无需请求访问用户的整个地址簿,而是指定所需的数据字段(例如电话号码或电子邮件地址),然后用户选择要分享的特定联系人。这样,您的应用便只能读取所选数据,从而确保精细控制,同时提供一致的用户体验,并具有内置搜索、个人资料切换和多选功能,而无需构建或维护界面。
如需了解详情,请参阅联系人选择工具文档。
الأمان
يضيف Android 17 الميزات الجديدة التالية لتحسين أمان الجهاز والتطبيق.
وضع "الحماية المتقدّمة على Android" (AAPM)
Android 高级保护模式为 Android 用户提供了一套强大的新安全功能,标志着在保护用户(尤其是面临较高风险的用户)免遭复杂攻击方面迈出了重要一步。AAPM 是一项选择启用功能,只需进行一项配置设置即可激活。用户可以随时启用该功能,以应用一套主观的安全保护措施。
这些核心配置包括:禁止安装未知来源的应用(旁加载)、限制 USB 数据信号传输,以及强制执行 Google Play 保护机制扫描,从而显著减小设备的攻击面。
开发者可以使用 AdvancedProtectionManager API 与此功能集成,以检测模式的状态,从而使应用能够在用户选择启用此模式时自动采用强化型安全姿态或限制高风险功能。
توقيع حزمة APK باستخدام تقنية PQC
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 الميزات التالية لتحسين إمكانية اتصال الجهاز والتطبيق.
شبكات الأقمار الصناعية المقيّدة
تتضمّن هذه السمة تحسينات تتيح للتطبيقات العمل بفعالية على شبكات الأقمار الصناعية ذات معدل نقل البيانات المنخفض.
تجربة المستخدم وواجهة مستخدم النظام
يتضمّن Android 17 التغييرات التالية لتحسين تجربة المستخدم.
مصدر صوت مخصّص لمستوى صوت "مساعد Google"
يقدّم Android 17 مصدر صوت مخصّصًا لمستوى صوت "مساعد Google" لتطبيقات "مساعد Google"، وذلك لتشغيله باستخدام USAGE_ASSISTANT. يؤدي هذا التغيير إلى فصل صوت "مساعد Google" عن مصدر الوسائط العادي، ما يمنح المستخدمين تحكّمًا منفصلاً في كلا مستوىَي الصوت. يتيح ذلك سيناريوهات مثل كتم صوت تشغيل الوسائط مع الحفاظ على إمكانية سماع ردود "مساعد Google"، والعكس.
يمكن لتطبيقات المساعد التي يمكنها الوصول إلى وضع الصوت الجديد MODE_ASSISTANT_CONVERSATION audio تحسين اتساق التحكّم في مستوى الصوت بشكل أكبر. يمكن لتطبيقات "مساعد Google" استخدام هذا الوضع لتقديم تلميح إلى النظام بشأن جلسة نشطة في "مساعد Google"، ما يضمن إمكانية التحكّم في مصدر صوت "مساعد Google" خارج تشغيل USAGE_ASSISTANT النشط أو باستخدام الأجهزة الطرفية المتصلة عبر البلوتوث.
التسليم (Handoff)
Handoff هي ميزة وواجهة برمجة تطبيقات جديدة ستتوفّر في Android 17، ويمكن لمطوّري التطبيقات دمجها لتوفير تجربة متواصلة للمستخدمين على جميع الأجهزة. تتيح هذه الميزة للمستخدم بدء نشاط تطبيق على أحد أجهزة Android ونقله إلى جهاز Android آخر. تعمل ميزة "نقل النشاط" في خلفية جهاز المستخدم، وتعرض الأنشطة المتاحة من أجهزة المستخدم الأخرى القريبة من خلال نقاط دخول مختلفة، مثل مشغّل التطبيقات وشريط المهام، على الجهاز المستلِم.
يمكن للتطبيقات تحديد ميزة "نقل البيانات" لتشغيل تطبيق Android الأصلي نفسه، إذا كان مثبّتًا ومتوفّرًا على الجهاز المستلِم. في مسار التنقّل من تطبيق إلى تطبيق، يتم توجيه المستخدم إلى النشاط المحدّد من خلال رابط لصفحة في التطبيق. يمكن بدلاً من ذلك توفير ميزة "التسليم من التطبيق إلى الويب" كخيار احتياطي أو تنفيذها مباشرةً باستخدام ميزة "التسليم من عنوان URL".
يتم تنفيذ ميزة Handoff على أساس كل نشاط. لتفعيل ميزة "التسليم"، استدعِ طريقة setHandoffEnabled() للنشاط. قد يلزم تمرير بيانات إضافية مع عملية التسليم حتى يتمكّن النشاط الذي تم إنشاؤه من جديد على الجهاز المستلِم من استعادة الحالة المناسبة. نفِّذ
onHandoffActivityDataRequested()
الدالة التنفيذية لعرض عنصر
HandoffActivityData
يحتوي على تفاصيل تحدّد كيفية تعامل ميزة "التسليم" مع النشاط وإعادة إنشائه على الجهاز المستلِم.
تحديث مباشر: واجهة برمجة التطبيقات للألوان الدلالية
في نظام التشغيل Android 17، تطلق ميزة التحديث المباشر واجهات برمجة التطبيقات Semantic Coloring لدعم الألوان ذات المعنى العالمي.
تتيح الفئات التالية التلوين الدلالي:
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)
واجهة برمجة التطبيقات UWB Downlink-TDoA لنظام 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)
يقدّم المقتطف التالي مثالاً على بيانات إعداد DL-TDoA OOB لشبكة Wi-Fi و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
};
إذا تعذّر عليك استخدام إعداد 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();