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ğunda) uygulamanızı bu davranışları doğru şekilde destekleyecek şekilde değiştirmeniz gerekir.

Android 12 üzerinde çalışan tüm uygulamaları etkileyen davranış değişikliklerinin listesini de incelemeyi unutmayın.

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üzen ve stillerini sağlayabiliyordu. Bu da 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çıyordu.

Android 12'yi hedefleyen uygulamalar için özel içerik görünümlerine sahip bildirimler artık bildirim alanının tamamını kullanmayacak. Bunun yerine sistem, standart bir şablon uygular. Bu şablon, özel bildirimlerin tüm durumlarda diğer bildirimlerle aynı dekorasyona sahip olmasını sağlar. Bildirimin simgesi, genişletme olanakları (daraltılmış durumda) ve bildirimin simgesi, uygulama adı ve daraltma seçeneği (genişletme durumunda) buna dahildir. Bu davranış, Notification.DecoratedCustomViewStyle davranışıyla neredeyse aynıdır.

Bu sayede Android 12, kullanıcılara keşfedilebilir, tanıdık bir bildirim genişletmesi sunarak tüm bildirimleri görsel olarak tutarlı ve kolay taranır.

Aşağıdaki resimde, standart şablonda ö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 özel alt sınıflarını tanımlayan veya Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) ve setCustomHeadsUpContentView(RemoteViews) yöntemlerini kullanan uygulamaları etkilemektedir.

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

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

    1. Yeni davranışı etkinleştirmek için uygulamanızın targetSdkVersion ayarını 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. Testler sırasında aşağıdaki hususları dikkate alın ve gerekli düzenlemeleri yapın:

    • Özel görünümlerin boyutları değişti. Genel olarak, özel bildirimlere izin verilen yükseklik eskisinden daha azdır. Daraltılmış durumda özel içeriğin maksimum yüksekliği 106 dp'den 48 dp'ye düşürülmüştür. Ayrıca, daha az yatay alan vardır.

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

    • "Dikkat" durumunun beklediğiniz gibi göründüğünden emin olmak için, bildirim kanalının önemini "YÜKSEK"e (Ekranda açılır) yükseltmeyi unutmayın.

Android 12 veya sonraki sürümleri hedefleyen uygulamalarda sistem, Android App Links'in doğrulanma şeklinde birkaç değişiklik yapar. Bu değişiklikler, uygulama bağlama deneyiminin güvenilirliğini iyileştirir ve uygulama geliştiriciler ile son kullanıcılara daha fazla kontrol sağlar.

Uygulamanızdaki web bağlantılarını açmak için Android App Link doğrulamasından yararlanıyorsanız Android App Link doğrulaması için amaç filtreleri 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ışında iyileştirmeler

Android 12'de pencere içinde pencere (PiP) modu için davranış iyileştirmeleri sunulmakta ve hem hareketle gezinme hem de öğe tabanlı gezinme için geçiş animasyonlarına yönelik önerilen kozmetik iyileştirmeler sunulmaktadır.

Daha fazla bilgi için Pencere içinde pencere iyileştirmeleri bölümüne bakın.

Tost tasarımı yenilendi

Android 12'de, kısa mesaj görünümü yeniden tasarlanmıştır. Kısa iletiler artık iki satırlık metinle sınırlandırılıyor ve metnin yanında uygulama simgesi gösteriliyor.

Android cihaz resminde, bir uygulama simgesinin yanında "Mesaj gönderiliyor" yazan pop-up mesajı gösteriliyor

Daha fazla bilgi için Bildirim mesajlarına genel bakış başlıklı makaleyi inceleyin.

Güvenlik ve gizlilik

Yaklaşık konum

Android 12 veya sonraki sürümleri çalıştıran cihazlarda, kullanıcılar uygulamanız için yaklaşık konum doğruluğu isteyebilir.

WebView'daki modern SameSite çerezleri

Android'in WebView bileşeni, Google'ın Chrome tarayıcısını destekleyen açık kaynak projesi Chromium'u temel alır. Chromium, daha fazla güvenlik ve gizlilik sağlamanın yanı sıra kullanıcılara daha fazla şeffaflık ve kontrol sunmak için üçüncü taraf çerezlerinin kullanımıyla ilgili değişiklikler yaptı. Android 12'den itibaren bu değişiklikler, uygulamalar Android 12 (API düzeyi 31) veya sonraki sürümleri hedeflediğinde WebView bölümüne de dahil edilir.

Bir çerezin SameSite özelliği, herhangi bir istekle mi yoksa yalnızca aynı site istekleriyle mi gönderilebileceğini kontrol eder. Gizliliği koruyan aşağıdaki değişiklikler, üçüncü taraf çerezlerinin varsayılan olarak işlenmesini iyileştirir ve istenmeyen siteler arası paylaşıma karşı korunmaya yardımcı olur:

  • SameSite özelliği olmayan çerezler SameSite=Lax olarak kabul edilir.
  • SameSite=None içeren çerezler de Secure özelliğini belirtmelidir. Bu, güvenli bir bağlam gerektiği ve HTTPS üzerinden gönderilmesi gerektiği anlamına gelir.
  • Bir sitenin HTTP ve HTTPS sürümleri arasındaki bağlantılar artık siteler arası istekler olarak işlenmektedir. Bu nedenle, uygun bir şekilde SameSite=None; Secure olarak işaretlenmeyen çerezler gönderilmez.

Geliştiriciler için genel yol, kritik kullanıcı 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çen aynı site gezinmelerinde çalışmasına izin verilen çerezleri açık bir şekilde belirtmeniz gerekir.

Web geliştiricileri için bu değişikliklerle ilgili kapsamlı yardım bilgileri için SameSite Cookies Explained ve SchemefulSameSite bölümlerine bakın.

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

Uygulamanız Web Görünümü kullanıyorsa veya çerez kullanan bir web sitesini ya da hizmeti 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ş işlemleri ve yerleştirilmiş içeriğin yanı sıra, kullanıcının güvenli olmayan bir sayfada başlayıp güvenli bir sayfaya geçtiği oturum açma akışları, satın alma ve diğer kimlik doğrulama akışlarıyla ilgili sorunlara dikkat edin.

Bir uygulamayı WebView ile test etmek isterseniz aşağıdaki adımlardan birini uygulayarak 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 isterseniz Android Cihazlarda Uzaktan Hata Ayıklamaya Başlama bölümüne bakın.

Diğer kaynaklar

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

Hareket sensörlerinin hız sınırlaması vardır

Uygulamanız Android 12 veya sonraki bir sürümü hedefliyorsa kullanıcılar hakkındaki hassas olabilecek bilgileri korumak için sistem, belirli hareket sensörlerinden ve konum sensörlerinden gelen verilerin yenileme hızına bir sınır uygular.

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 izinleri otomatik olarak sıfırlar ve uygulamanızı hazırda bekleme durumuna geçirir.

Uygulamayı hazırda bekletme ile ilgili kılavuzda 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 bir sürümü hedefliyorsa uygulamanızın manifest dosyasında bu ilişkilendirme etiketlerini beyan etmeniz gerekir.

ADB yedekleme kısıtlaması

Android 12, gizli 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 uygulamalar için kullanıcılar adb backup komutunu çalıştırdığında uygulama verileri cihazdan dışa aktarılan diğer tüm sistem verilerinden hariç tutulur.

Test veya geliştirme iş akışlarınız adb backup kullanarak uygulama verilerini kullanıyorsa artık uygulamanızın manifest dosyasında android:debuggable öğesini 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 bir sürümü hedefliyorsa ve amaç 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 öğesini true olarak ayarlayın. Diğer çoğu durumda, android:exported öğesini false olarak ayarlayın.

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

<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ız, amaç filtreleri kullanan ancak android:exported beyanında bulunmayan bir etkinlik, hizmet veya yayın alıcı içeriyorsa, 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örünür:

  1. Manifest dosyanızda aşağıdaki lint uyarısı görünür:

    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örüntülenir:

    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 şu 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'

Beklemedeki amaçlar 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 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ı arayın:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Güvenli olmayan intent lansmanları

Android 12 ve sonraki sürümler, platform güvenliğini iyileştirmek için güvenli olmayan niyet başlatmalarını algılayan bir hata ayıklama özelliği sunar. Sistem, güvenli olmayan bir başlatma 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 hariç arka planda çalışırken ön plan hizmetlerini başlatamaz. Bir uygulama arka planda çalışırken bir ön plan hizmeti başlatmaya çalışırsa istisna oluşur (birkaç özel durum hariç).

Uygulamanız arka planda çalışırken hızlı çalışma planlamak ve başlatmak için WorkManager'ı kullanabilirsiniz. Kullanıcının istediği zamana duyarlı işlemleri tamamlamak için ön plan hizmetlerini tam bir alarm içinde başlatın.

Tam alarm izni

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

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

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

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

Uygulamanızı Android 12'yi hedeflemeye hazırlarken hata ayıklaması yapılabilir derleme varyantınızdaki davranış değişikliğini test amacıyla geçici olarak devre dışı bırakabilirsiniz. Bunu yapmak 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ünen ekranda uygulamanızın adına dokunun ve ardından REQUIRE_EXACT_ALARM_PERMISSION özelliğini kapatı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 trambolin kısıtlamaları

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

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ı bildirimdeki bir bildirime veya işlem düğmesine dokunduktan sonra uygulamanız bir hizmet ya da yayın alıcısının içinde startActivity()'i arayamaz.

Uygulamanız bildirim trambolini işlevi gören bir hizmetten veya yayın alıcıdan etkinlik başlatmaya çalıştığında sistem, etkinliğin başlamasını engeller ve Logcat'te şu mesaj görünür:

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

Hangi uygulama bileşenlerinin bildirim trambolinleri olarak işlev gördüğünü belirleyin

Uygulamanızı test ederken bir bildirime dokunduktan sonra, hangi hizmetin veya yayın alıcısının uygulamanızda bildirim trambolini olarak işlev gördüğü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 "NotifEngagementLog" metni yer alır. Bu bölümde, bildirime dokunma işleminin sonucu olarak başlayan bileşeni tanımlamak için gereken bilgiler yer alır.

Uygulamanızı güncelleme

Uygulamanız, bildirim trambolini işlevi gören bir hizmetten veya yayın alıcıdan etkinlik başlatırsa 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şturma işleminin bir parçası olarak, önceki adımda oluşturduğunuz PendingIntent nesnesini kullanın.

Etkinliğin kaynağını belirlemek için, örneğin 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ışı değiştir

Uygulamanızın hata ayıklaması yapılabilir bir sürümünü test ederken, NOTIFICATION_TRAMPOLINE_BLOCK uygulama uyumluluk işaretini kullanarak bu kısıtlamayı etkinleştirebilir ve devre dışı bırakabilirsiniz.

Yedekleme ve geri yükleme

Android 12'yi (API düzeyi 31) çalıştıran ve hedefleyen uygulamalarda yedekleme ve geri yüklemenin çalışma şeklinde değişiklikler yapılmıştır. Android yedekleme ve geri yüklemenin iki biçimi vardır:

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

Verilerin yedeklenmesi ve geri yüklenmesi hakkında daha fazla bilgi edinmek için Otomatik Yedekleme ile kullanıcı verilerini yedekleme ve Android Yedekleme Hizmeti ile anahtar/değer çiftlerini yedekleme başlıklı makaleleri inceleyin.

D2D aktarım işleviyle ilgili değişiklikler

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

  • XML yapılandırma mekanizmasıyla dahil etme ve hariç tutma kurallarının belirtilmesi, D2D aktarımlarını etkilemez ancak yine de bulut tabanlı yedekleme ve geri yüklemeyi (ör. Google Drive yedeklemeleri) etkiler. D2D aktarımların kurallarını belirlemek için bir 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 D2D aktarımlar devre dışı bırakılmaz.

Yeni dahil etme ve hariç tutma biçimi

Android 12 ve sonraki sürümleri çalıştıran ve bunları 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 gerektirerek Google Drive yedeklemesi 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, daha önce kullanılan yapılandırma Android 12 veya sonraki sürümleri çalıştıran cihazlarda 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çimi değişiklikleri

Aşağıda, Android 11 ve önceki sürümlerde yedekleme ve geri yükleme yapılandırması için kullanılan biçim 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 kalın biçimdeki değişiklikler 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 göz atın.

Uygulamalar için manifest işareti

Manifest dosyanızda 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 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 sunuluyor. Bu izinler, Android 12'yi hedefleyen uygulamaların, özellikle de cihaz konumuna erişim gerektirmeyen uygulamaların Bluetooth cihazlarla etkileşime geçmesini kolaylaştırır.

Cihazınızı Android 12 veya sonraki bir sürümü hedeflemeye hazırlamak için uygulamanızın mantığını güncelleyin. Eski bir Bluetooth izni grubu beyan etmek yerine daha modern bir grup Bluetooth izni beyan edin.

Eşler arası eş zamanlı + İnternet bağlantısı

Android 12 (API düzeyi 31) veya sonraki sürümleri hedefleyen uygulamalar için eşzamanlı eşler arası ve internet bağlantılarını destekleyen cihazlar hem eş cihazla hem de internet sağlayan birincil ağla eşzamanlı kablosuz bağlantıları sürdürebilir. Bu da kullanıcı deneyimini daha sorunsuz hale getirir. 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ışı kullanmaya devam eder.

Uyumluluk

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

  • Yalnızca tek bir kablosuz ağ varsa WifiInfo değeri döndürülür.
  • Birden fazla kablosuz ağ mevcutsa ve telefon eden uygulama, 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 bağlantısı döndürülür.

Eşzamanlı çift kablosuz ağı destekleyen cihazlarda daha iyi bir kullanıcı deneyimi sağlamak için özellikle eşler arası bağlantıları tetikleyen tüm uygulamaların WifiManager.getConnectionInfo() çağrısından uzaklaşmasını ve bunun yerine, NetworkCallback öğesini kaydetmek için kullanılan NetworkRequest ile eşleşen tüm WifiInfo nesnelerini almak için NetworkCallback.onCapabilitiesChanged() yöntemini kullanmasını öneririz. getConnectionInfo() desteği, Android 12'den itibaren kullanımdan kaldırılmıştır.

Aşağıdaki kod örneğinde, WifiInfo öğesinin 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;
    ...
  }
  ...
};

mDNSReplyer yerel API'si

Android 12, uygulamaların mDNSReplyer yerel API'sini kullanarak mDNSReplyer arka plan programıyla etkileşim kurabileceği zamanı değiştirir. Önceden, bir uygulama ağda bir hizmeti kaydettiğinde ve getSystemService() yöntemini çağırdığında, uygulama henüz herhangi bir NsdManager yöntemi çağırmamış olsa bile sistemin NSD hizmeti mDNSResponseer arka plan programını başlatıyordu. Daha sonra arka plan programı, cihazı tüm düğümlü çok yayın gruplarına abone yaptı. Bu da sistemin daha sık uyanmasına ve ek güç kullanmasına neden oldu. Android 12 ve sonraki sürümlerde sistem, pil kullanımını en aza indirmek amacıyla artık mDNSResponseer arka plan programını yalnızca NSD etkinlikleri için gerekli olduğunda başlatıyor ve daha sonra durduruyor.

Bu değişiklik, mDNSResponseer arka plan programının kullanılabileceği zamanı etkilediği için, getSystemService() yöntemini çağırdıktan sonra mDNSReplyer arka plan programının başlatılacağını varsayan uygulamalar, sistemden mDNSReplyer arka plan programının kullanılamadığını belirten mesajlar alabilir. NsdManager kullanan ve mDNSResponseer yerel API'sini kullanmayan uygulamalar bu değişiklikten etkilenmez.

Satıcı kitaplıkları

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

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

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

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

Android 12, Android geliştiricileriyle yapılan ortak çalışmaya ve en son dahili testlere dayanarak kısıtlanmış SDK dışı arayüzlerin güncellenmiş listelerini içerir. Mümkün olduğunda SDK dışı arayüzleri kısıtlamadan önce herkese açık alternatiflerin kullanılabildiğinden emin oluruz.

Uygulamanız Android 12'yi hedeflemiyorsa bu değişikliklerden bazıları sizi hemen etkilemeyebilir. Ancak şu anda bazı SDK olmayan arayüzleri (uygulamanızın hedef API düzeyine bağlı olarak) kullanabilirsiniz. Ancak SDK olmayan herhangi bir yöntem veya alan kullanmak her zaman uygulamanızın bozulma riski taşır.

Uygulamanızın SDK olmayan arayüz kullanıp kullanmadığından emin değilseniz öğrenmek için uygulamanızı test edebilirsiniz. Uygulamanız SDK olmayan arayüzleri kullanıyorsa SDK alternatiflerine geçiş planlamaya başlamanız gerekir. Bununla birlikte, bazı uygulamaların SDK dışı arayüzler için geçerli kullanım alanları olduğunun farkındayız. Uygulamanızdaki bir özellik için SDK dışı arayüz kullanmanın alternatifini 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üz kısıtlamalarıyla ilgili güncellemeler bölümüne bakın. SDK olmayan arayüzler hakkında genel olarak daha fazla bilgi edinmek için SDK dışı arayüzlerdeki kısıtlamalar bölümüne bakın.