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

Android 12, önceki sürümlerde olduğu gibi 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 şekilde destekleyecek şekilde değiştirmeniz gerekir.

Android 12'de çalışan tüm uygulamaları etkileyen davranış değişiklikleri listesini de incelediğinizden emin olun.

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 anti-pattern'lere 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ı süslemeye sahip olmasını sağlar. Örneğin, bildirim simgesi ve genişletme olanakları (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 kolayca taranabilir hale getirir. Ayrıca, kullanıcılar için bildirimleri genişletme özelliği kolayca bulunabilir ve tanıdık bir şekilde sunulur.

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'ın setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) ve setCustomHeadsUpContentView(RemoteViews) yöntemlerini kullanan uygulamaları etkiler.

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

  1. Özel bildirimler değişikliğini etkinleştirin:

    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 beklendiği gibi göründüğünden 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 azdır. Daraltılmış durumda, özel içeriğin maksimum yüksekliği 106 dp'den 48 dp'ye düşürüldü. Ayrıca, yatay alan daha azdır.

    • Android 12'yi hedefleyen uygulamalarda tüm bildirimler genişletilebilir. Bu genellikle setCustomContentView kullanıyorsanız daraltılmış ve genişletilmiş durumların tutarlı olmasını sağlamak için setBigCustomContentView kullanmanız gerektiği anlamına gelir.

    • "Heads Up" durumunun istediğiniz gibi görünmesini sağlamak için bildirim kanalının önemini "YÜKSEK" (Ekranda açılır) olarak ayarlamayı unutmayın.

Android 12 veya sonraki sürümleri hedefleyen uygulamalarda sistem, Android App Link'lerin 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.

Uygulamanızda web bağlantılarını açmak için Android App Link doğrulamasına güveniyorsanız Android App Link doğrulaması için amaç filtresi eklerken doğru biçimi kullandığınızdan emin olun. Özellikle bu amaç 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, resim içinde resim (PiP) modunda 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 Resim içinde resim iyileştirmeleri başlıklı makaleyi inceleyin.

Toast yeniden tasarımı

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

Android cihazda, uygulama simgesinin yanında "Mesaj gönderiliyor" yazan bir durum mesajı pop-up'ının gösterildiği resim

Daha fazla bilgi için Toasts'a 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'ye de dahil edilir.

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 işlenmesini iyileştirir ve istenmeyen siteler arası paylaşıma karşı koruma sağlar:

  • SameSite özelliği olmayan çerezler SameSite=Lax olarak kabul edilir.
  • SameSite=None içeren çerezler, Secure özelliğini de belirtmelidir. 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ı istek olarak kabul ediliyor. Bu nedenle, çerezler uygun şekilde SameSite=None; Secure olarak işaretlenmediği sürece gönderilmiyor.

Geliştiriciler için genel yönerge, kritik kullanıcı akışlarınızdaki siteler arası çerez bağımlılıklarını belirlemek ve gerektiğinde SameSite özelliğinin uygun değerlerle açıkça ayarlandığından emin olmaktır. Web sitelerinde veya HTTP'den HTTPS'ye geçiş yapan aynı site navigasyonlarında ç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 Cookies Explained (SameSite Çerezleri Hakkında Bilgi) ve Schemeful SameSite (Şemalı SameSite) başlıklı makalelere göz atın.

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

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

Kullanıcının güvenli olmayan bir sayfada başlayıp güvenli bir sayfaya geçtiği girişler, yerleştirilmiş içerikler, oturum açma akışları, satın alma ve diğer kimlik doğrulama akışlarındaki sorunlara dikkat edin.

Bir uygulamayı WebView ile test etmek için aşağıdaki adımlardan birini uygulayarak test etmek istediğiniz uygulamada 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ıklamaya Başlama başlıklı makaleyi inceleyin.

Diğer kaynaklar

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

Hareket sensörleri için sıklık sınırlaması uygulanır

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

Sensör hız 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ı hazırda bekleme durumuna geçirir.

Uygulama hazırda bekletme ile ilgili kılavuzdan daha fazla bilgi edinin.

Veri erişimi denetiminde ilişkilendirme beyanı

Android 11'de (API düzeyi 30) kullanıma sunulan veri erişimi denetleme 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 bu ilişkilendirme etiketlerini uygulamanızın manifest dosyasında 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'yi (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 tüm sistem verilerinin dışında tutulur.

Test veya geliştirme iş akışlarınızda adb backup kullanan uygulama verileri varsa artık uygulama manifest dosyanızda android:debuggable değerini true olarak ayarlayarak uygulama verilerinizi 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 veya 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 olarak ayarlayın.

Aşağıdaki kod snippet'inde, android:exported özelliği false olarak ayarlanmış bir amaç 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 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 lint 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 hata mesajı gösterilir:

    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ıştığınızda 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'

PendingIntent 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 koşul, uygulamanızın güvenliğini artırır.

Beklemedeki amaç 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 lint uyarısını bulun:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Güvenli olmayan amaç başlatma işlemleri

Android 12 ve sonraki sürümlerde, platform güvenliğini artırmak için amaçların 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 (birkaç özel durum hariç) istisna oluşur.

Uygulamanız arka planda çalışırken hızlandırılmış 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 zamanlı 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.

Tam alarmlar yalnızca kullanıcıya yönelik özellikler için kullanılmalıdır. Tam alarm ayarlamayla ilgili 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 varyantınızda 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. Açılan ekranda uygulamanızın adına dokunun ve 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 trampolini kısıtlamaları

Kullanıcılar bildirimlerle etkileşime geçtiğinde bazı uygulamalar, bildirimlere dokunulduğunda uygulama bileşenini başlatarak yanıt verir. Bu bileşen, kullanıcının sonunda gördüğü ve etkileşimde bulunduğu etkinliği başlatır. Bu uygulama bileşenine bildirim trambolini adı verilir.

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

Uygulamanız, bildirim trambolini görevi gören bir hizmetten veya yayın alıcısından 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.

Hangi uygulama bileşenlerinin bildirim trambolini olarak işlev gördüğünü belirleme

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

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

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

Uygulamanızı güncelleme

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

  1. Kullanıcıların bildirime dokunduktan sonra gördüğü etkinlikle ilişkilendirilmiş bir PendingIntent nesnesi oluşturun.
  2. Önceki adımda oluşturduğunuz PendingIntent nesnesini bildiriminizi oluşturma sürecinde kullanın.

Etkinliğin kaynağını belirlemek için (ör. günlük kaydı oluşturmak 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'de (API düzeyi 31) çalışan ve bu sürümü hedefleyen uygulamalarda yedekleme ve geri yükleme işlevlerinin çalışma şekli değişti. Android yedekleme ve geri yükleme iki şekilde yapılır:

  • 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 saklanır.
  • Cihazdan cihaza (D2D) aktarımlar: Kullanıcı verileri, kablo kullanmak gibi yöntemlerle 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ı makalelere bakın.

D2D aktarım işlevindeki değişiklikler

Android 12 ve sonraki sürümlerde çalışan ve bu sürümleri hedefleyen uygulamalar için:

  • XML yapılandırma mekanizmasıyla dahil etme ve hariç tutma kurallarını belirtmek, D2D aktarımlarını etkilemez ancak bulut tabanlı yedekleme ve geri yükleme (ör. Google Drive yedeklemeleri) işlemlerini etkilemeye devam eder. Cihazdan cihaza 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" belirtildiğinde Google Drive'a yedeklemeler devre dışı bırakılır ancak uygulama için cihazdan cihaza aktarımlar devre dışı bırakılmaz.

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 D2D aktarımı için dahil etme ve hariç tutma kurallarını ayrı ayrı belirtmenizi isteyerek Google Drive yedekleme ile D2D aktarımı arasındaki farkı açıkça ortaya koyar.

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

XML biçimindeki değişiklikler

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

<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 olarak gösterilmektedir.

<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, Android 12 veya sonraki sürümlerin yüklü olduğu cihazlarda eski yapılandırmayı işaret eden android:fullBackupContent özelliği yoksayılır. Aşağıdaki kod örneğinde yeni manifest 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, özellikle cihaz konumuna erişim gerektirmeyen uygulamalar için Android 12'yi hedefleyen uygulamaların Bluetooth cihazlarla etkileşimde bulunmasını kolaylaştırır.

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ş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ş cihazla hem de internet sağlayan birincil ağla eş zamanlı Wi-Fi bağlantısı kurabilir. Bu sayede kullanıcı deneyimi daha sorunsuz hale gelir. Android 11 (API düzeyi 30) veya önceki sürümleri hedefleyen uygulamalar, eş cihaza bağlanmadan önce birincil kablosuz ağın bağlantısının kesildiği eski davranışı deneyimlemeye devam eder.

Uyumluluk

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

  • Yalnızca tek bir kablosuz ağ varsa bu ağın WifiInfo değeri döndürülür.
  • Birden fazla kablosuz ağ varsa ve görüşme uygulaması eşler arası bağlantıyı tetiklediyse eş cihazla eşleşen 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.

Aynı anda iki kablosuz ağ bağlantısını destekleyen cihazlarda daha iyi bir kullanıcı deneyimi sunmak için tüm uygulamaların (özellikle eşler arası bağlantıları tetikleyen uygulamaların) WifiManager.getConnectionInfo() çağrısından uzaklaşarak NetworkCallback.onCapabilitiesChanged() kullanmasını öneririz. Bu sayede NetworkCallback'ı kaydetmek için kullanılan NetworkRequest ile eşleşen tüm WifiInfo nesneleri alınabilir. getConnectionInfo() desteği, Android 12'den itibaren sonlandırıldı.

Aşağıdaki kod örneğinde, WifiInfo değerinin NetworkCallback içinde 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 daemon'uyla 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öntemi çağırmamış olsa bile sistemin NSD hizmeti mDNSResponder daemon'unu başlatıyordu. Ardından daemon, 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 daemon'u yalnızca NSD etkinlikleri için gerektiğinde başlatıp sonrasında durduruyor.

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

Tedarikçi kitaplıkları

Sağlayıcı tarafından sağlanan yerel paylaşılan kitaplıklar

Uygulama Android 12'yi (API düzeyi 31) veya sonraki sürümleri hedefliyorsa silikon satıcıları 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'i (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 olmayan arayüzlerle ilgili güncellenen kısıtlamalar

Android 12, Android geliştiricilerle işbirliği ve en son dahili testlere dayalı olarak kısıtlanmış SDK dışı arayüzlerin güncellenmiş listelerini içerir. Mümkün olduğunda, SDK olmayan arayüzleri kısıtlamadan önce herkese açık alternatiflerin kullanılabilir olmasını sağlarız.

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

Uygulamanızda SDK dışı arayüzler kullanılıp kullanılmadığından emin değilseniz öğrenmek için uygulamanızı test edebilirsiniz. Uygulamanız SDK dışı 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 anlıyoruz. Uygulamanızdaki bir özellik için SDK dışı arayüz kullanmaya alternatif bulamıyorsanız yeni bir herkese açık API isteğinde bulunmalısınız.

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