Davranış değişiklikleri: Android 12'yi hedefleyen uygulamalar

Önceki sürümlerde olduğu gibi Android 12 de uygulamanızı etkileyebilecek davranış değişiklikleri içerir. Aşağıdaki davranış değişiklikleri yalnızca Android 12 veya sonraki sürümleri hedefleyen uygulamalar için geçerlidir. Uygulamanız Android 12'yi hedefliyorsa geçerli olduğu durumlarda bu davranışları düzgün bir şekilde destekleyecek şekilde uygulamanızı değiştirmeniz gerekir.

Ayrıca Android 12'de çalışan tüm uygulamaları etkileyen davranış değişiklikleri listesini de inceleyin.

Kullanıcı deneyimi

Özel bildirimler

Android 12, tamamen özel bildirimlerin görünümünü ve davranışını değiştirir. Önceden, özel bildirimler bildirim alanının tamamını kullanabiliyor ve kendi düzenlerini ve stillerini sağlayabiliyordu. Bu durum, kullanıcıların kafasını karıştırabilecek veya farklı cihazlarda düzen uyumluluğu sorunlarına neden olabilecek karşıt kalıplara yol açtı.

Android 12'yi hedefleyen uygulamalarda, özel içerik görünümlerine sahip bildirimler artık bildirim alanının tamamını kullanmayacak. Bunun yerine sistem, standart bir şablon uygulayacak. Bu şablon, özel bildirimlerin tüm durumlarda diğer bildirimlerle aynı parametreye sahip olmasını sağlar. Örneğin, bildirim simgesi ve genişletme olanağı (daraltılmış durumda) ile bildirim simgesi, uygulama adı ve daraltma olanağı (genişletilmiş durumda). Bu davranış, Notification.DecoratedCustomViewStyle davranışıyla neredeyse aynıdır.

Bu sayede Android 12, tüm bildirimleri görsel olarak tutarlı ve kolay taranabilir hale getirir. Ayrıca kullanıcılar için keşfedilebilir ve tanıdık bir bildirim genişletme özelliği sunar.

Aşağıdaki resimde, standart şablondaki özel bir bildirim gösterilmektedir:

Aşağıdaki örneklerde, özel bildirimlerin daraltılmış ve genişletilmiş durumda nasıl oluşturulacağı gösterilmektedir:

Android 12'deki değişiklik, Notification.Style için özel alt sınıflar tanımlayan veya Notification.Builder'un setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) ve setCustomHeadsUpContentView(RemoteViews) yöntemlerini kullanan uygulamaları etkiler.

Uygulamanız tamamen özel bildirimler kullanıyorsa en kısa sürede yeni şablonla test yapmanızı öneririz.

  1. Özel bildirim değişikliğini etkinleştirme:

    1. Yeni davranışı etkinleştirmek için uygulamanızın targetSdkVersion değerini S olarak değiştirin.
    2. Yeniden derleyin.
    3. Uygulamanızı Android 12 çalıştıran bir cihaza veya emülatöre yükleyin.

  2. Özel görünümler kullanan tüm bildirimleri test ederek gölgede beklediğiniz gibi göründüklerinden emin olun. Test sırasında aşağıdaki noktaları göz önünde bulundurun ve gerekli düzenlemeleri yapın:

    • Özel görünümlerin boyutları değişti. Genel olarak, özel bildirimlere ayrılan yükseklik eskiye göre daha az. Daraltılmış durumda, özel içeriğin maksimum yüksekliği 106 dp'den 48 dp'ye düşürüldü. Ayrıca, yatay alan artık daha az.

    • Android 12'yi hedefleyen uygulamalarda tüm bildirimler genişletilebilir. Genellikle bu, setCustomContentView kullanıyorsanız daraltılmış ve genişletilmiş durumların tutarlı olduğundan emin olmak için setBigCustomContentView da kullanmanız gerektiği anlamına gelir.

    • "Heads Up" durumunun beklediğiniz gibi görünmesi için bildirim kanalının önemini "YÜKSEK" (Ekranda gösterilir) olarak ayarlamayı unutmayın.

Android 12 veya sonraki sürümleri hedefleyen uygulamalarda sistem, Android Uygulama Bağlantılarının nasıl doğrulandığı konusunda çeşitli değişiklikler yapar. Bu değişiklikler, uygulama bağlantısı deneyiminin güvenilirliğini artırır ve uygulama geliştiricilere ve son kullanıcılara daha fazla kontrol olanağı sunar.

Web bağlantılarını uygulamanızda açmak için Android Uygulama Bağlantısı doğrulamasına güveniyorsanız Android Uygulama Bağlantısı doğrulaması için intent filtresi eklerken doğru biçimi kullandığınızdan emin olun. Özellikle, bu intent filtrelerinin BROWSABLE kategorisini içerdiğinden ve https şemasını desteklediğinden emin olun.

Beyanlarınızın güvenilirliğini test etmek için uygulamanızın bağlantılarını manuel olarak da doğrulayabilirsiniz.

Pencere içinde pencere davranışıyla ilgili iyileştirmeler

Android 12, pencere içinde pencere (PiP) modu için davranış iyileştirmeleri ve hem hareketle gezinme hem de öğe tabanlı gezinme için geçiş animasyonlarında önerilen kozmetik iyileştirmeler sunar.

Daha fazla bilgi için Pencere içinde pencere iyileştirmeleri başlıklı makaleyi inceleyin.

Kısa ileti yeniden tasarımı

Android 12'de kısa ileti görünümü yeniden tasarlandı. Artık kısa iletiler iki satır metinle sınırlı ve metnin yanında uygulama simgesi gösteriliyor.

Uygulama simgesinin yanında "Mesaj gönderiliyor" yazan bir pop-up mesaj gösteren Android cihaz resmi

Daha fazla bilgi için Kısa iletiye genel bakış bölümüne bakın.

Güvenlik ve gizlilik

Yaklaşık konum

Android 12 veya sonraki sürümlerin yüklü olduğu cihazlarda kullanıcılar, uygulamanız için yaklaşık konum doğruluğu isteyebilir.

WebView'da modern SameSite çerezleri

Android'in WebView bileşeni, Google'ın Chrome tarayıcısına güç veren açık kaynak projesi Chromium'a dayanır. Chromium, daha fazla güvenlik ve gizlilik sağlamak, kullanıcılara daha fazla şeffaflık ve kontrol sunmak için üçüncü taraf çerezlerinin işlenmesinde değişiklikler yaptı. Android 12'den itibaren, uygulamalar Android 12 (API düzeyi 31) veya sonraki sürümleri hedeflediğinde bu değişiklikler WebView'da de yer alır.

Bir çerezin SameSite özelliği, çerezin herhangi bir istekle mi yoksa yalnızca aynı site istekleriyle mi gönderilebileceğini kontrol eder. Gizliliği korumaya yönelik aşağıdaki değişiklikler, üçüncü taraf çerezlerinin varsayılan olarak işlenme şeklini iyileştirir ve istenmeyen siteler arası paylaşıma karşı koruma sağlar:

  • SameSite özelliği olmayan çerezler SameSite=Lax olarak değerlendirilir.
  • SameSite=None içeren çerezlerin Secure özelliğini de belirtmesi gerekir. Bu, güvenli bir bağlam gerektirdikleri ve HTTPS üzerinden gönderilmeleri gerektiği anlamına gelir.
  • Bir sitenin HTTP ve HTTPS sürümleri arasındaki bağlantılar artık siteler arası istekler olarak değerlendiriliyor. Bu nedenle, çerezler uygun şekilde SameSite=None; Secure olarak işaretlenmediği sürece gönderilmiyor.

Geliştiriciler için genel öneri, kritik kullanıcı işlemleri akışlarınızdaki siteler arası çerez bağımlılıklarını belirlemek ve SameSite özelliğinin gerektiğinde uygun değerlerle açıkça ayarlandığından emin olmaktır. Web siteleri arasında veya HTTP'den HTTPS'ye geçiş yapan aynı site gezinmelerinde çalışmasına izin verilen çerezleri açıkça belirtmeniz gerekir.

Web geliştiricilerin bu değişikliklerle ilgili tam kılavuz için SameSite Çerezleri Hakkında Bilgi ve Şemalı SameSite başlıklı makalelere göz atın.

Uygulamanızda SameSite davranışlarını test etme

Uygulamanız WebView kullanıyorsa veya çerez kullanan bir web sitesi ya da hizmet yönetiyorsanız akışlarınızı Android 12 WebView'da test etmenizi öneririz. Sorunlarla karşılaşırsanız yeni SameSite davranışlarını desteklemek için çerezlerinizi güncellemeniz gerekebilir.

Girişlerde ve yerleştirilmiş içeriklerde, ayrıca oturum açma akışlarında, satın alma işlemlerinde ve kullanıcının güvenli olmayan bir sayfada başlayıp güvenli bir sayfaya geçtiği diğer kimlik doğrulama akışlarında sorun olup olmadığını kontrol edin.

Bir uygulamayı WebView ile test etmek için aşağıdaki adımlardan birini tamamlayarak test etmek istediğiniz uygulama için yeni SameSite davranışlarını etkinleştirmeniz gerekir:

Android'de WebView için uzaktan hata ayıklama hakkında bilgi edinmek istiyorsanız Android Cihazlarda Uzaktan Hata Ayıklamayı Kullanmaya Başlama başlıklı makaleyi inceleyin.

Diğer kaynaklar

SameSite modern davranışları ve Chrome ile WebView'a sunulması hakkında daha fazla bilgi için Chromium SameSite Güncellemeleri sayfasını ziyaret edin. WebView veya Chromium'da bir hata bulursanız bunu herkese açık Chromium hata izleyicide bildirebilirsiniz.

Hareket sensörleri sıklık sınırlamasına tabidir

Kullanıcılarla ilgili hassas olabilecek bilgileri korumak için uygulamanız Android 12 veya sonraki sürümleri hedefliyorsa sistem, belirli hareket sensörlerinden ve konum sensörlerinden gelen verilerin yenileme hızına bir sınır koyar.

Sensör sıklık sınırlaması hakkında daha fazla bilgi edinin.

Uygulamayı hazırda bekletme

Android 12, Android 11'de (API düzeyi 30) kullanıma sunulan izinleri otomatik sıfırlama davranışını genişletir. Uygulamanız Android 12'yi hedefliyorsa ve kullanıcı birkaç ay boyunca uygulamanızla etkileşimde bulunmazsa sistem, verilen tüm izinleri otomatik olarak sıfırlar ve uygulamanızı kullanılmayan uygulama durumuna getirir.

Uygulamayı hazırda bekletme ile ilgili kılavuzdan daha fazla bilgi edinebilirsiniz.

Veri erişimi denetiminde ilişkilendirme beyanı

Android 11'de (API düzeyi 30) kullanıma sunulan veri erişimi denetimi API'si, uygulamanızın kullanım alanlarına göre ilişkilendirme etiketleri oluşturmanıza olanak tanır. Bu etiketler, uygulamanızın hangi bölümünün belirli bir veri erişimi türünü gerçekleştirdiğini belirlemenizi kolaylaştırır.

Uygulamanız Android 12 veya sonraki sürümleri hedefliyorsa uygulamanızın manifest dosyasında bu ilişkilendirme etiketlerini bildirmeniz gerekir.

ADB yedekleme kısıtlaması

Android 12, özel uygulama verilerinin korunmasına yardımcı olmak için adb backup komutunun varsayılan davranışını değiştirir. Android 12 (API düzeyi 31) veya sonraki sürümleri hedefleyen uygulamalarda, kullanıcı adb backup komutunu çalıştırdığında uygulama verileri, cihazdan dışa aktarılan diğer sistem verilerinden hariç tutulur.

Test veya geliştirme iş akışlarınız adb backup kullanan uygulama verilerine dayanıyorsa artık uygulamanızın manifest dosyasında android:debuggable değerini true olarak ayarlayarak uygulamanızın verilerini dışa aktarmayı etkinleştirebilirsiniz.

Daha güvenli bileşen dışa aktarma

Uygulamanız Android 12 veya sonraki sürümleri hedefliyorsa ve intent filtreleri kullanan etkinlikler, hizmetler ya da yayın alıcıları içeriyorsa bu uygulama bileşenleri için android:exported özelliğini açıkça beyan etmeniz gerekir.

Uygulama bileşeni LAUNCHER kategorisini içeriyorsa android:exported değerini true olarak ayarlayın. Diğer çoğu durumda android:exported öğesini false değerine ayarlayın.

Aşağıdaki kod snippet'inde, android:exported özelliği false olarak ayarlanmış bir intent filtresi içeren hizmet örneği gösterilmektedir:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Android Studio'da mesajlar

Uygulamanızda intent filtreleri kullanan ancak android:exported özelliğini beyan etmeyen bir etkinlik, hizmet veya yayın alıcısı varsa kullandığınız Android Studio sürümüne bağlı olarak aşağıdaki uyarı mesajları gösterilir:

Android Studio 2020.3.1 Canary 11 veya sonraki sürümler

Aşağıdaki mesajlar gösterilir:

  1. Manifest dosyanızda aşağıdaki hata analizi uyarısı gösteriliyor:

    When using intent filters, please specify android:exported as well

  2. Uygulamanızı derlemeye çalıştığınızda aşağıdaki derleme hatası mesajı görünür:

    Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.
Android Studio'nun eski sürümleri

Uygulamayı yüklemeye çalışırsanız Logcat aşağıdaki hata mesajını gösterir:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Beklemede olan intent'lerin değişkenliği

Uygulamanız Android 12'yi hedefliyorsa uygulamanızın oluşturduğu her PendingIntent nesnesinin değişkenliğini belirtmeniz gerekir. Bu ek şart, uygulamanızın güvenliğini artırır.

Beklemedeki intent değişkenliği değişikliğini test etme

Uygulamanızda değişkenlik bildirimlerinin eksik olup olmadığını belirlemek için Android Studio'da aşağıdaki hata analizi uyarısını bulun:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Güvenli olmayan intent başlatma işlemleri

Android 12 ve sonraki sürümlerde, platform güvenliğini artırmak için intent'lerin güvenli olmayan şekilde başlatılmasını algılayan bir hata ayıklama özelliği bulunur. Sistem bu tür güvenli olmayan bir başlatma işlemi algıladığında StrictMode ihlali gerçekleşir.

Performans

Ön plan hizmeti başlatma kısıtlamaları

Android 12 veya sonraki sürümleri hedefleyen uygulamalar, birkaç özel durum dışında arka planda çalışırken ön plan hizmetlerini başlatamaz. Bir uygulama arka planda çalışırken ön plan hizmeti başlatmaya çalışırsa istisna oluşur (birkaç özel durum hariç).

Uygulamanız arka planda çalışırken yüksek öncelikli işleri planlamak ve başlatmak için WorkManager'ı kullanabilirsiniz. Kullanıcının istediği zamana duyarlı işlemleri tamamlamak için tam alarm içinde ön plan hizmetlerini başlatın.

Tam alarm izni

Android 12 ve sonraki sürümleri hedefleyen ve tam alarmlar ayarlayan uygulamaların, sistem kaynaklarını koruması için sistem ayarlarındaki Özel uygulama erişimi ekranında görünen "Alarmlar ve hatırlatıcılar" özelliğine erişmesi gerekir.

Bu özel uygulama erişimini elde etmek için manifest dosyasında SCHEDULE_EXACT_ALARM iznini isteyin.

Kesin zamanlı alarmlar yalnızca kullanıcılara yönelik özellikler için kullanılmalıdır. Kesin zamanlı alarm ayarlamak için kabul edilebilir kullanım alanları hakkında daha fazla bilgi edinin.

Davranış değişikliğini devre dışı bırakma

Uygulamanızı Android 12'yi hedefleyecek şekilde hazırlarken test amacıyla hata ayıklanabilir derleme değişkeninizde davranış değişikliğini geçici olarak devre dışı bırakabilirsiniz. Bunun için aşağıdaki görevlerden birini tamamlayın:

  • Geliştirici seçenekleri ayar ekranında Uygulama Uyumluluğu Değişiklikleri'ni seçin. Görüntülenen ekranda uygulamanızın adına dokunun, ardından REQUIRE_EXACT_ALARM_PERMISSION'ı devre dışı bırakın.

  • Geliştirme makinenizdeki bir terminal penceresinde aşağıdaki komutu çalıştırın:

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

Bildirim trambolini kısıtlamaları

Kullanıcılar bildirimlerle etkileşimde bulunduğunda bazı uygulamalar, bildirim dokunmalarına yanıt olarak bir uygulama bileşeni başlatır. Bu bileşen de kullanıcının en sonunda görüp etkileşimde bulunduğu etkinliği başlatır. Bu uygulama bileşeni, bildirim trambolini olarak bilinir.

Uygulama performansını ve kullanıcı deneyimini iyileştirmek için Android 12 veya sonraki sürümleri hedefleyen uygulamalar, bildirim trampolini olarak kullanılan hizmetlerden veya yayın alıcılarından etkinlik başlatamaz. Diğer bir deyişle, kullanıcı bir bildirime veya bildirimdeki bir işlem düğmesine dokunduktan sonra uygulamanız, bir hizmet veya yayın alıcısı içinde startActivity() yöntemini çağıramaz.

Uygulamanız, bildirim trambolini görevi gören bir hizmetten veya yayın alıcıdan etkinlik başlatmaya çalıştığında sistem, etkinliğin başlatılmasını engeller ve Logcat'te aşağıdaki mesaj gösterilir:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Bildirim trambolini işlevi gören uygulama bileşenlerini belirleme

Uygulamanızı test ederken bir bildirime dokunduktan sonra uygulamanızda hangi hizmetin veya yayın alıcının bildirim trambolini olarak davrandığını belirleyebilirsiniz. Bunun için aşağıdaki terminal komutunun çıkışına bakın:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

Çıktının bir bölümünde "NotifInteractionLog" metni yer alır. Bu bölümde, bir bildirime dokunulması sonucunda başlayan bileşeni tanımlamak için gerekli bilgiler yer alır.

Uygulamanızı güncelleme

Uygulamanız, bildirim trambolini görevi gören bir hizmetten veya yayın alıcıdan etkinlik başlatıyorsa aşağıdaki taşıma adımlarını tamamlayın:

  1. Kullanıcıların bildirime dokunduktan sonra gördükleri etkinlikle ilişkili bir PendingIntent nesnesi oluşturun.
  2. Bildiriminizi oluştururken önceki adımda oluşturduğunuz PendingIntent nesnesini kullanın.

Etkinliğin kaynağını belirlemek için (ör. günlük kaydı yapmak amacıyla) bildirimi yayınlarken ekstraları kullanın. Merkezi günlük kaydı için ActivityLifecycleCallbacks veya Jetpack yaşam döngüsü gözlemcilerini kullanın.

Davranışı açma/kapatma

Uygulamanızın hata ayıklanabilir bir sürümünü test ederken NOTIFICATION_TRAMPOLINE_BLOCK uygulama uyumluluğu işaretini kullanarak bu kısıtlamayı etkinleştirebilir ve devre dışı bırakabilirsiniz.

Yedekleme ve geri yükleme

Android 12 (API düzeyi 31) üzerinde çalışan ve bu sürümü hedefleyen uygulamalarda yedekleme ve geri yükleme işlemlerinin işleyişinde değişiklikler yapılmıştır. Android yedekleme ve geri yükleme iki şekilde yapılabilir:

  • Bulut yedeklemeleri: Kullanıcı verileri, daha sonra ilgili cihazda veya yeni bir cihazda geri yüklenebilmesi için kullanıcının Google Drive'ında depolanır.
  • Cihazdan cihaza (D2D) aktarımlar: Kullanıcı verileri, kablo gibi bir yöntemle doğrudan kullanıcının eski cihazından yeni cihazına gönderilir.

Verilerin nasıl yedeklendiği ve geri yüklendiği hakkında daha fazla bilgi için Otomatik Yedekleme ile kullanıcı verilerini yedekleme ve Android Backup Service ile anahtar/değer çiftlerini yedekleme başlıklı makaleleri inceleyin.

Cihazdan cihaza aktarım işlevindeki değişiklikler

Android 12 ve sonraki sürümleri çalıştıran ve hedefleyen uygulamalar için:

  • XML yapılandırma mekanizmasıyla dahil etme ve hariç tutma kurallarını belirtmek, cihazlar arası aktarımları etkilemez ancak bulut tabanlı yedekleme ve geri yükleme işlemlerini (ör. Google Drive yedeklemeleri) etkiler. Cihazlar arası aktarımlarla ilgili kuralları belirtmek için sonraki bölümde ele alınan yeni yapılandırmayı kullanmanız gerekir.

  • Bazı cihaz üreticilerinin cihazlarında android:allowBackup="false" değerini belirtmek, Google Drive'a yedeklemeleri devre dışı bırakır ancak uygulama için cihazdan cihaza aktarımları devre dışı bırakmaz.

Yeni dahil etme ve hariç tutma biçimi

Android 12 ve sonraki sürümlerde çalışan ve bu sürümleri hedefleyen uygulamalar, XML yapılandırması için farklı bir biçim kullanır. Bu biçim, bulut yedeklemeleri ve cihazlar arası aktarım için dahil etme ve hariç tutma kurallarını ayrı ayrı belirtmenizi zorunlu kılarak Google Drive yedeklemesi ile cihazlar arası aktarım arasındaki farkı netleştirir.

İsterseniz yedekleme kurallarını belirtmek için de kullanabilirsiniz. Bu durumda, daha önce kullanılan yapılandırma Android 12 veya sonraki sürümleri çalıştıran cihazlarda yoksayılır. Android 11 veya daha eski sürümleri çalıştıran cihazlar için eski yapılandırma hâlâ gereklidir.

XML biçimi değişiklikleri

Android 11 ve önceki sürümlerde yedekleme ve geri yükleme yapılandırması için aşağıdaki biçim kullanılır:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Aşağıda, biçimdeki değişiklikler kalın yazı tipiyle gösterilmiştir.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Daha fazla bilgi için Otomatik Yedekleme ile kullanıcı verilerini yedekleme kılavuzundaki ilgili bölüme bakın.

Uygulamalar için manifest işareti

Manifest dosyanızdaki android:dataExtractionRules özelliğini kullanarak uygulamalarınızı yeni XML yapılandırmasına yönlendirin. Yeni XML yapılandırmasını işaret ettiğinizde, eski yapılandırmayı işaret eden android:fullBackupContent özelliği, Android 12 veya sonraki sürümleri çalıştıran cihazlarda yoksayılır. Aşağıdaki kod örneğinde yeni manifesto dosyası girişleri gösterilmektedir:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Bağlantı

Bluetooth izinleri

Android 12'de BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE ve BLUETOOTH_CONNECT izinleri kullanıma sunulmuştur. Bu izinler, Android 12'yi hedefleyen uygulamaların Bluetooth cihazlarla etkileşim kurmasını kolaylaştırır. Bu durum özellikle cihaz konumuna erişim gerektirmeyen uygulamalar için geçerlidir.

Cihazınızı Android 12 veya sonraki sürümleri hedeflemeye hazırlamak için uygulamanızın mantığını güncelleyin. Eski Bluetooth izinleri grubunu bildirmek yerine daha modern bir Bluetooth izinleri grubu bildirin.

Eşzamanlı Eşler Arası + İnternet Bağlantısı

Android 12 (API düzeyi 31) veya sonraki sürümleri hedefleyen uygulamalarda, eşler arası ve internet bağlantılarını aynı anda destekleyen cihazlar, hem eş cihaza hem de internet sağlayan birincil ağa aynı anda kablosuz bağlantı kurarak kullanıcı deneyimini daha sorunsuz hale getirebilir. Android 11 (API düzeyi 30) veya daha eski sürümleri hedefleyen uygulamalar, eş cihaza bağlanmadan önce birincil kablosuz ağ bağlantısının kesildiği eski davranışı kullanmaya devam eder.

Uyumluluk

WifiManager.getConnectionInfo(), yalnızca tek bir ağ için WifiInfo döndürebilir. Bu nedenle, API'nin davranışı Android 12 ve sonraki sürümlerde aşağıdaki şekillerde değiştirilmiştir:

  • Yalnızca tek bir kablosuz ağ varsa bu ağın WifiInfo değeri döndürülür.
  • Birden fazla kablosuz ağ varsa ve arama uygulaması eşler arası bağlantıyı tetiklediyse eş cihaza karşılık gelen WifiInfo döndürülür.
  • Birden fazla kablosuz ağ varsa ve arama uygulaması eşler arası bağlantıyı tetiklemediyse internet sağlayan birincil bağlantının WifiInfo değeri döndürülür.

Eşzamanlı iki kablosuz ağı destekleyen cihazlarda daha iyi bir kullanıcı deneyimi sunmak için tüm uygulamaların (özellikle de eşler arası bağlantıları tetikleyen uygulamaların) WifiManager.getConnectionInfo() çağrısı yapmayı bırakıp bunun yerine NetworkCallback.onCapabilitiesChanged() kullanarak NetworkCallback kaydetmek için kullanılan NetworkRequest ile eşleşen tüm WifiInfo nesnelerini almasını öneririz. getConnectionInfo(), Android 12'den itibaren kullanımdan kaldırılmıştır.

Aşağıdaki kod örneğinde, NetworkCallback içinde WifiInfo değerinin nasıl alınacağı gösterilmektedir:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

mDNSResponder yerel API'si

Android 12, uygulamaların mDNSResponder yerel API'sini kullanarak mDNSResponder arka plan programı ile etkileşim kurabileceği zamanlarda değişiklik yapar. Daha önce bir uygulama ağda hizmet kaydettiğinde ve getSystemService() yöntemini çağırdığında, uygulama henüz herhangi bir NsdManager yöntemini çağırmamış olsa bile sistemin NSD hizmeti mDNSResponder arka plan programını başlatıyordu. Ardından arka plan programı, cihazı tüm düğümlerin çoklu yayın gruplarına abone etti. Bu durum, sistemin daha sık uyanmasına ve daha fazla güç kullanmasına neden oldu. Android 12 ve sonraki sürümlerde pil kullanımını en aza indirmek için sistem artık mDNSResponder arka plan programı yalnızca NSD etkinlikleri için gerektiğinde başlatıyor ve sonrasında durduruyor.

Bu değişiklik, mDNSResponder arka plan programının ne zaman kullanılabileceğini etkilediğinden getSystemService() yöntemi çağrıldıktan sonra mDNSResponder arka plan programının başlatılacağını varsayan uygulamalar, sistemden mDNSResponder arka plan programı kullanılamadığını belirten mesajlar alabilir. NsdManager kullanan ve mDNSResponder yerel API'sini kullanmayan uygulamalar bu değişiklikten etkilenmez.

Tedarikçi kitaplıkları

Tedarikçi tarafından sağlanan yerel paylaşılan kitaplıklar

Uygulama Android 12 (API düzeyi 31) veya sonraki sürümleri hedefliyorsa silikon tedarikçileri ya da cihaz üreticileri tarafından sağlanan NDK dışı yerel paylaşılan kitaplıklara varsayılan olarak erişilemez. Kitaplıklara yalnızca <uses-native-library> etiketi kullanılarak açıkça istendiğinde erişilebilir.

Uygulama Android 11 (API düzeyi 30) veya daha eski bir sürümü hedefliyorsa <uses-native-library> etiketi gerekli değildir. Bu durumda, NDK kitaplığı olup olmadığına bakılmaksızın tüm yerel paylaşılan kitaplıklara erişilebilir.

SDK dışı kısıtlamalar güncellendi

Android 12, Android geliştiricileriyle yapılan ortak çalışmalar ve en son dahili testlere dayalı olarak güncellenmiş kısıtlanmış SDK dışı arayüz listeleri içerir. SDK olmayan arayüzleri kısıtlamadan önce mümkün olduğunca herkese açık alternatiflerin mevcut olduğundan emin oluruz.

Uygulamanız Android 12'yi hedeflemiyorsa bu değişikliklerin bazıları sizi hemen etkilemeyebilir. Ancak şu anda bazı SDK dışı arayüzleri kullanabilseniz de (uygulamanızın hedef API düzeyine bağlı olarak) SDK dışı bir yöntem veya alan kullanmak her zaman uygulamanızın bozulmasıyla ilgili yüksek risk taşır.

Uygulamanızın SDK dışı arayüzler kullanıp kullanmadığından emin değilseniz uygulamanızı test ederek öğrenebilirsiniz. Uygulamanız SDK olmayan arayüzleri kullanıyorsa SDK alternatiflerine geçişi planlamaya başlamanız gerekir. Bununla birlikte, bazı uygulamaların SDK dışı arayüzleri kullanmak için geçerli kullanım alanları olduğunu biliyoruz. Uygulamanızdaki bir özellik için SDK olmayan arayüz kullanmaya alternatif bulamıyorsanız yeni bir herkese açık API isteğinde bulunmanız gerekir.

Android'in bu sürümündeki değişiklikler hakkında daha fazla bilgi edinmek için Android 12'deki SDK olmayan arayüzlerle ilgili kısıtlamalarda yapılan güncellemeler başlıklı makaleyi inceleyin. SDK olmayan arayüzler hakkında genel bilgi edinmek için SDK olmayan arayüzlerde kısıtlamalar başlıklı makaleyi inceleyin.