Özellikler ve API'ler

Android 17, geliştiriciler için harika yeni özellikler ve API'ler sunuyor. Aşağıdaki bölümlerde, ilgili API'leri kullanmaya başlamanıza yardımcı olmak için bu özellikler özetlenmiştir.

Yeni, değiştirilen ve kaldırılan API'lerin ayrıntılı listesi için API farklılıkları raporunu inceleyin. Yeni API'lerle ilgili ayrıntılar için Android API referansını ziyaret edin. Yeni API'ler, görünürlük için vurgulanmıştır.

Platform değişikliklerinin uygulamalarınızı etkileyebileceği alanları da incelemeniz gerekir. Daha fazla bilgi için aşağıdaki sayfalara bakın:

Temel işlevler

Android 17, temel Android işlevleriyle ilgili aşağıdaki yeni özellikleri ekler.

Yeni ProfilingManager tetikleyicileri

Android 17, performans sorunlarını gidermek için ayrıntılı veriler toplamanıza yardımcı olmak amacıyla ProfilingManager'a birkaç yeni sistem tetikleyicisi ekler.

Yeni tetikleyiciler şunlardır:

  • TRIGGER_TYPE_COLD_START: Tetikleyici, uygulama soğuk başlatma sırasında gerçekleşir. Yanıtta hem çağrı yığını örneği hem de sistem izi sağlar.
  • TRIGGER_TYPE_OOM: Tetikleyici, bir uygulama OutOfMemoryError hatası verdiğinde ve yanıt olarak Java yığın dökümü sağladığında gerçekleşir.
  • TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: Tetikleyici, bir uygulama anormal ve aşırı CPU kullanımı nedeniyle sonlandırıldığında gerçekleşir ve yanıt olarak bir çağrı yığını örneği sağlar.
  • TRIGGER_TYPE_ANOMALY: Aşırı bağlayıcı çağrıları ve aşırı bellek kullanımı gibi sistem performansı anormalliklerini tespit eder.

Sistem tetikleyicisinin nasıl ayarlanacağını anlamak için tetikleyici tabanlı profil oluşturma ve profil oluşturma verilerini alma ve analiz etme ile ilgili belgelere bakın.

Uygulama anormallikleri için profil oluşturma tetikleyicisi

Android 17, kaynak yoğun davranışları ve olası uyumluluk gerilemelerini izleyen, cihaz üzerinde çalışan bir anormallik algılama hizmeti sunar. ProfilingManager ile entegre olan bu hizmet, uygulamanızın sistem tarafından algılanan belirli etkinliklerin tetiklediği profil oluşturma yapılarını almasına olanak tanır.

Aşırı bağlayıcı çağrıları ve aşırı bellek kullanımı gibi sistem performansı sorunlarını tespit etmek için TRIGGER_TYPE_ANOMALY tetikleyicisini kullanın. Bir uygulama, işletim sistemi tarafından tanımlanan bellek sınırlarını ihlal ettiğinde anormallik tetikleyici, geliştiricilerin uygulamaya özel yığın dökümleri almasına olanak tanıyarak bellek sorunlarını tespit edip düzeltmelerine yardımcı olur. Ayrıca, aşırı binder spam'i için anormallik tetikleyici, binder işlemlerinde bir yığın örnekleme profili sağlar.

Bu API geri çağırma işlemi, sistem tarafından uygulanan yaptırımlardan önce gerçekleşir. Örneğin, geliştiricilerin uygulama bellek sınırlarını aştığı için sistem tarafından sonlandırılmadan önce hata ayıklama verilerini toplamasına yardımcı olabilir.

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'leri

Android 17, geliştiricilerin JobScheduler işlerinde hata ayıklamasına yardımcı olmak için yeni JobDebugInfo API'leri sunar. Bu API'ler, işlerin neden çalışmadığı, ne kadar süre çalıştığı ve diğer birleştirilmiş bilgiler hakkında bilgi sağlar.

Genişletilmiş JobDebugInfo API'lerinin ilk yöntemi getPendingJobReasonStats(), işin beklemede olan yürütme durumunda olmasının nedenlerini ve ilgili kümülatif bekleme sürelerini gösteren bir harita döndürür. Bu yöntem, planlanmış bir işin neden beklendiği gibi çalışmadığına dair bilgi vermek için getPendingJobReasonsHistory() ve getPendingJobReasons() yöntemlerine katılır ancak hem süreyi hem de iş nedenini tek bir yöntemde sunarak bilgi almayı kolaylaştırır.

Örneğin, belirtilen bir jobId için yöntem, PENDING_JOB_REASON_CONSTRAINT_CHARGING ve 60.000 ms'lik bir süre döndürebilir. Bu, şarj kısıtlaması karşılanmadığı için işin 60.000 ms boyunca beklemede olduğunu gösterir.

Boştayken izin verilen alarmlar için dinleyici desteğiyle uyanık kalma kilitlerini azaltma

Android 17, PendingIntent yerine OnAlarmListener kabul eden yeni bir AlarmManager.setExactAndAllowWhileIdle varyantı sunar. Geri çağırma tabanlı bu yeni mekanizma, periyodik görevleri gerçekleştirmek için sürekli uyanık kalma kilitlerini kullanan uygulamalar (ör. soket bağlantılarını sürdüren mesajlaşma uygulamaları) için idealdir.

Gizlilik

Android 17, kullanıcı gizliliğini iyileştirmek için aşağıdaki yeni özellikleri içerir.

Encrypted Client Hello (ECH) platform desteği

Android 17, ağ iletişimlerinde önemli bir gizlilik iyileştirmesi olan Encrypted Client Hello (ECH) için platform desteği sunuyor. ECH, ilk TLS el sıkışması sırasında Sunucu Adı Göstergesi'ni (SNI) şifreleyen bir TLS 1.3 uzantısıdır. Bu şifreleme, bir uygulamanın bağlandığı alanın ağ aracıları tarafından tanımlanmasını zorlaştırarak kullanıcı gizliliğinin korunmasına yardımcı olur.

Platform artık ağ kitaplıklarının ECH'yi uygulaması için gerekli API'leri içeriyor. Buna, ECH yapılandırmaları içeren HTTPS DNS kayıtlarını sorgulamak için DnsResolver'daki yeni özellikler ve bir alana bağlanırken bu yapılandırmaları ileterek ECH'yi etkinleştirmek için Conscrypt'in SSLEngines ve SSLSockets'indeki yeni yöntemler dahildir. Geliştiriciler, ECH tercihlerini (ör. fırsatçı bir şekilde etkinleştirme veya kullanımını zorunlu kılma) yeni <domainEncryption> öğesi aracılığıyla yapılandırabilir. Bu öğe, Ağ Güvenliği Yapılandırma dosyası içinde yer alır ve global olarak veya alan bazında geçerlidir.

HttpEngine, WebView ve OkHttp gibi popüler ağ kitaplıklarının gelecekteki güncellemelerde bu platform API'lerini entegre etmesi bekleniyor. Bu sayede uygulamaların ECH'yi benimsemesi ve kullanıcı gizliliğini artırması kolaylaşacak.

Daha fazla bilgi için Şifrelenmiş İstemci Merhaba belgesine bakın.

Android kişi seçici

Android Kişi Seçici, kullanıcıların uygulamanızla kişi paylaşması için standartlaştırılmış, göz atılabilir bir arayüzdür. Android 17 (API düzeyi 37) veya sonraki sürümleri çalıştıran cihazlarda kullanılabilen seçici, geniş kapsamlı READ_CONTACTS iznine gizliliği korumaya yönelik bir alternatif sunar. Uygulamanız, kullanıcının tüm adres defterine erişim istemek yerine telefon numaraları veya e-posta adresleri gibi ihtiyaç duyduğu veri alanlarını belirtir ve kullanıcı, paylaşılacak belirli kişileri seçer. Bu sayede uygulamanız yalnızca seçilen verilere okuma erişimi elde eder. Böylece, kullanıcı arayüzü oluşturmak veya yönetmek zorunda kalmadan yerleşik arama, profil değiştirme ve çoklu seçim özellikleriyle tutarlı bir kullanıcı deneyimi sunarken ayrıntılı kontrol sağlayabilirsiniz.

Daha fazla bilgi için kişi seçici belgelerine bakın.

Güvenlik

Android 17, cihaz ve uygulama güvenliğini artırmak için aşağıdaki yeni özellikleri ekler.

Android Gelişmiş Koruma Modu (AAPM)

Android Gelişmiş Koruma Modu, Android kullanıcılarına güçlü bir yeni güvenlik özellikleri paketi sunarak kullanıcıları, özellikle de daha yüksek risk altındaki kullanıcıları gelişmiş saldırılardan koruma konusunda önemli bir adım atıyor. İsteğe bağlı bir özellik olarak tasarlanan AAPM, kullanıcıların istediği zaman etkinleştirerek güvenlik korumaları uygulayabileceği tek bir yapılandırma ayarıyla etkinleştirilir.

Bu temel yapılandırmalar arasında bilinmeyen kaynaklardan uygulama yüklenmesini engelleme (yan yükleme), USB veri sinyalini kısıtlama ve Google Play Protect taramasını zorunlu kılma yer alır. Bu yapılandırmalar, cihazın saldırı yüzey alanını önemli ölçüde azaltır. Geliştiriciler, modun durumunu algılamak için AdvancedProtectionManager API'sini kullanarak bu özellikle entegrasyon yapabilir. Böylece, kullanıcı modu etkinleştirdiğinde uygulamalar otomatik olarak daha sıkı bir güvenlik duruşu benimseyebilir veya yüksek riskli işlevleri kısıtlayabilir.

PQC APK İmzalama

Android artık uygulamanızın imzalama kimliğini kuantum bilişimden yararlanan olası saldırı tehditlerine karşı geleceğe hazırlamak için karma APK imza şemasını destekliyor. Bu özellik, klasik bir imzalama anahtarını (ör. RSA veya EC) yeni bir kuantum sonrası kriptografi (PQC) algoritmasıyla (ML-DSA) eşlemenize olanak tanıyan yeni bir APK İmza Şeması sunar.

Bu karma yaklaşım, uygulamanızın gelecekteki kuantum saldırılarına karşı güvende kalmasını sağlarken klasik imza doğrulamaya dayalı eski Android sürümleri ve cihazlarla tam geriye dönük uyumluluğu korur.

Geliştiriciler üzerindeki etkisi

  • Google Play Uygulama İmzalama'yı kullanan uygulamalar: Google Play Uygulama İmzalama'yı kullanıyorsanız Google Play'in, Google Play tarafından oluşturulan bir PQC anahtarını kullanarak karma imzayı yükseltme seçeneğini sunmasını bekleyebilirsiniz. Böylece uygulamanız, manuel anahtar yönetimi gerekmeden korunur.
  • Kendi kendine yönetilen anahtarlar kullanan uygulamalar: Kendi imzalama anahtarlarını yöneten geliştiriciler, güncellenmiş Android derleme araçlarını (ör. apksigner) kullanarak karma kimliğe geçebilir ve bir PQC anahtarını yeni bir klasik anahtarla birleştirebilir. (Yeni bir klasik anahtar oluşturmanız gerekir. Eski anahtarı tekrar kullanamazsınız.)

Bağlantı

Android 17, cihaz ve uygulama bağlantısını iyileştirmek için aşağıdaki özellikleri ekler.

Kısıtlı uydu ağları

Uygulamaların düşük bant genişliğine sahip uydu ağlarında etkili bir şekilde çalışmasını sağlamak için optimizasyonlar uygular.

Kullanıcı deneyimi ve sistem arayüzü

Android 17, kullanıcı deneyimini iyileştirmek için aşağıdaki değişiklikleri içerir.

Özel Asistan ses akışı

Android 17, USAGE_ASSISTANT ile oynatmak üzere Asistan uygulamaları için özel bir Asistan ses akışı sunar. Bu değişiklik, Asistan sesini standart medya akışından ayırarak kullanıcıların her iki ses seviyesini de ayrı ayrı kontrol etmesine olanak tanır. Bu sayede, Asistan yanıtlarının sesini açık tutarken medya oynatmayı sessize alma gibi senaryolar mümkün olur.

Yeni MODE_ASSISTANT_CONVERSATION ses moduna erişimi olan asistan uygulamaları, ses seviyesi kontrolünün tutarlılığını daha da artırabilir. Asistan uygulamaları, etkin bir Asistan oturumu hakkında sisteme ipucu vermek için bu modu kullanabilir. Böylece, Asistan akışının etkin USAGE_ASSISTANT oynatma dışında veya bağlı Bluetooth çevre birimleriyle kontrol edilebilmesi sağlanır.

Handoff

Handoff, Android 17'ye gelecek yeni bir özellik ve API'dir. Uygulama geliştiriciler, kullanıcılarına cihazlar arası süreklilik sağlamak için bu özelliği entegre edebilir. Kullanıcının bir Android cihazda uygulama etkinliği başlatmasına ve bu etkinliği başka bir Android cihaza aktarmasına olanak tanır. Handoff, kullanıcının cihazının arka planında çalışır ve kullanıcının yakındaki diğer cihazlarındaki mevcut etkinlikleri, alıcı cihazdaki başlatıcı ve görev çubuğu gibi çeşitli giriş noktaları aracılığıyla gösterir.

Uygulamalar, alıcı cihazda yüklü ve kullanılabilir durumdaysa aynı yerel Android uygulamasını başlatmak için Handoff'u belirleyebilir. Bu uygulamadan uygulamaya akışta kullanıcı, belirlenen etkinliğe derin bağlantıyla yönlendirilir. Alternatif olarak, uygulamadan web'e aktarım, yedek seçenek olarak sunulabilir veya URL aktarımı ile doğrudan uygulanabilir.

Aktarma desteği, etkinlik bazında uygulanır. Handoff'u etkinleştirmek için etkinlikte setHandoffEnabled() yöntemini çağırın. Alıcı cihazda yeniden oluşturulan etkinliğin uygun durumu geri yükleyebilmesi için aktarma işlemiyle birlikte ek verilerin de iletilmesi gerekebilir. Handoff'un, etkinliği alıcı cihazda nasıl işlemesi ve yeniden oluşturması gerektiğini belirten ayrıntıları içeren bir HandoffActivityData nesnesi döndürmek için onHandoffActivityDataRequested() geri çağırma işlevini uygulayın.

Canlı güncelleme - Anlamsal renk API'si

Android 17 ile birlikte Canlı Haberler, evrensel anlamı olan renkleri desteklemek için Semantic Coloring API'lerini kullanıma sunuyor.

Aşağıdaki sınıflar semantik renklendirmeyi destekler:

Boyama

  • Yeşil: Güvenlikle ilişkilendirilir. Bu renk, kullanıcılara güvende olduğunuzu bildirmek için kullanılmalıdır.
  • Turuncu: Dikkatli olunması gereken durumları ve fiziksel tehlikeleri belirtmek için kullanılır. Bu renk, kullanıcıların daha iyi koruma ayarı belirlemek için dikkat etmesi gereken durumlarda kullanılmalıdır.
  • Kırmızı: Genellikle tehlikeyi ve durmayı gösterir. Kullanıcıların dikkatini acilen çekmeniz gereken durumlarda gösterilmelidir.
  • Mavi: Bilgilendirici olan ve diğer içeriklerden ayrılması gereken içerikler için nötr renk.

Aşağıdaki örnekte, bildirimdeki metne anlamsal stillerin nasıl uygulanacağı gösterilmektedir:

  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 için UWB Downlink-TDoA API

Downlink Time Difference of Arrival (DL-TDoA) ölçümü, bir cihazın sinyallerin göreli varış zamanlarını ölçerek birden fazla bağlantı noktasına göre konumunu belirlemesini sağlar.

Aşağıdaki snippet'te, Mesafe Ölçüm Yöneticisi'nin nasıl ilk kullanıma hazırlanacağı, cihaz özelliklerinin nasıl doğrulanacağı ve DL-TDoA oturumunun nasıl başlatılacağı gösterilmektedir:

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

Bant Dışı (OOB) Yapılandırmaları

Aşağıdaki snippet'te, Wi-Fi ve BLE için DL-TDoA OOB yapılandırma verilerine dair bir örnek verilmiştir:

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

Kullanıma hazır bir yapılandırma eksik olduğu için kullanılamıyorsa veya kullanıma hazır yapılandırmada bulunmayan varsayılan değerleri değiştirmeniz gerekiyorsa aşağıdaki snippet'te gösterildiği gibi DlTdoaRangingParams.Builder ile parametreler oluşturabilirsiniz. DlTdoaRangingParams.createFromFiraConfigPacket() yerine şu parametreleri kullanabilirsiniz:

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