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şikliklerini 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 uygun durumlarda uygulamanızı bu davranışları destekleyecek şekilde değiştirmeniz gerekir.

Android 12'de çalışan tüm uygulamaları etkileyen davranış değişiklikleri 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. Daha önce, özel bildirimler bildirim alanının tamamını kullanabiliyordu ve kendi düzenlerini ve stillerini sağlayabiliyordu. Bu da kullanıcıların kafasını karıştırabilecek ya da farklı cihazlarda düzen uyumluluğu sorunlarına neden olabilecek anti-kalıplar oluşmasına neden oluyordu.

Android 12'yi hedefleyen uygulamalarda, özel içerik görünümleri içeren bildirimler artık tüm bildirim alanı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. Örneğin, bildirim simgesi ve genişletme teklifleri (daraltılmış durumda) ve bildirimin simgesi, uygulama adı ve daraltma uygunluğu (genişletme durumunda) gibi. Bu davranış, Notification.DecoratedCustomViewStyle özelliğinin davranışıyla neredeyse aynıdır.

Bu sayede Android 12, kullanıcılar için bulunabilir ve tanıdık bir bildirim genişletmesi sayesinde tüm bildirimleri görsel olarak tutarlı ve kolayca taranabilir hale getirir.

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 ö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 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 alın ve gerekli düzenlemeleri yapın:

    • Özel görünümlerin boyutları değişti. Genel olarak, özel bildirimleri etkinleştiren 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ı olmasını sağlamak için setBigCustomContentView kullanmanızı da isteyeceğiniz anlamına gelir.

    • "Dikkat" durumunun beklediğiniz gibi göründüğünden emin olmak için bildirim kanalının önem düzeyini "YÜKSEK" (Ekranda pop-up) olarak yükseltmeyi unutmayın.

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

Uygulamanızda web bağlantılarını açmak için Android Uygulama Bağlantısı doğrulamasından yararlanıyorsanız Android Uygulama Bağlantısı 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.

Ayrıca, 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, pencere içinde pencere (PiP) modu için davranış iyileştirmeleri sunar ve hem hareketle gezinme hem de öğe tabanlı gezinme için geçiş animasyonlarında kozmetik iyileştirmeler önerir.

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

Yeni toast tasarımı

Android 12'de, kısa mesaj görünümü yeniden tasarlandı. Durum bildirimlerinde artık iki satır metinle sınırlanıyor ve metnin yanında uygulama simgesi gösteriliyor.

Bir uygulama simgesinin yanında "Mesaj gönderiliyor" yazan bir kısa mesaj pop-up'ını gösteren Android cihaz resmi

Daha fazla ayrıntı için Kısa mesajlara genel bakış bölümüne bakın.

Güvenlik ve gizlilik

Yaklaşık konum

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

Web Görünümü'nde modern SameSite çerezleri

Android’in WebView bileşeni, Google'ın Chrome tarayıcısını destekleyen açık kaynak projesi olan Chromium'a dayanı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 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 uygulamasına da dahil edilecektir.

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

  • SameSite özelliği olmayan çerezler SameSite=Lax olarak değerlendirilir.
  • SameSite=None içeren çerezlerin de Secure özelliğini belirtmesi gerekir. Bu, güvenli bir bağlam gerektirdiği 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 işlendiği için SameSite=None; Secure olarak uygun bir şekilde işaretlenmeyen çerezler gönderilmez.

Geliştiricilere yönelik genel kılavuz, kritik kullanıcı akışlarınızdaki siteler arası çerez bağımlılıklarını tanımlamak ve SameSite özelliğinin gerektiğinde uygun değerlerle açıkça ayarlandığından emin olmaktır. Web sitelerinde veya HTTP'den HTTPS'ye geçen aynı sitede gezinmelerde çalışmasına izin verilen çerezleri açıkça belirtmeniz gerekir.

Web geliştiricileri için bu değişikliklerle ilgili eksiksiz yardım bilgileri için SameSite Cookies Explained ve Schemeful SameSite sayfalarına göz atın.

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

Uygulamanız Web Görünümü kullanıyorsa veya çerez kullanan bir web sitesi ya da hizmeti yönetiyorsanız akışlarınızı Android 12 Web Görünümü'nde test etmenizi öneririz. Sorun bulursanız çerezlerinizi yeni SameSite davranışlarını destekleyecek şekilde güncellemeniz gerekebilir.

Kullanıcının güvenli olmayan bir sayfada başlayıp güvenli bir sayfaya geçiş yaptığı oturum açma akışları, satın alma ve diğer kimlik doğrulama akışlarındaki sorunların yanı sıra giriş işlemleri ve yerleştirilmiş içerik ile ilgili sorunlara dikkat edin.

Bir uygulamayı Web Görünümü ile test etmek istiyorsanız test etmek istediğiniz uygulama için yeni SameSite davranışlarını etkinleştirmeniz gerekir. Bunun için aşağıdaki adımlardan birini uygulayın:

  • SameSite davranışlarını test cihazında manuel olarak etkinleştirmek için WebView geliştirme araçlarında webview-enable-modern-cookie-same-site kullanıcı arayüzü işaretini açın.

    Bu yaklaşım, Android 5.0 (API düzeyi 21) veya sonraki sürümleri (Android 12 dahil) çalıştıran ve Web Görünümü 89.0.4385.0 veya sonraki sürümleri çalıştıran tüm cihazlarda test yapmanıza olanak tanır.

  • Uygulamanızı, targetSdkVersion tarihine kadar Android 12'yi (API düzeyi 31) hedefleyecek şekilde derleyin.

    Bu yaklaşımı kullanırsanız Android 12 çalıştıran bir cihaz kullanmanız gerekir.

Android'de Web Görünümü'nde uzaktan hata ayıklama hakkında bilgi edinmek için Android Cihazlarda Uzaktan Hata Ayıklamaya Başlama bölümüne bakın.

Diğer kaynaklar

SameSite modern davranışları ve Chrome ile Web Görünümü'nde kullanıma sunulması hakkında daha fazla bilgi edinmek için Chromium SameSite Güncellemeleri sayfasını ziyaret edin. Web Görünümü veya Chromium'da bir hata bulursanız bunu herkese açık Chromium sorun izleyicisinde bildirebilirsiniz.

Hareket sensörleri hız sınırlamasına sahiptir

Uygulamanız Android 12 veya sonraki sürümleri 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ırlama 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ı daha fazla hale getirmektedir. 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ı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ü 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 bildirmeniz 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 uygulamalarda, bir 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 bir sürümü hedefliyorsa ve niyet 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 birçok durumda android:exported değerini false olarak ayarlayın.

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

<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'daki Mesajlar

Uygulamanız amaç filtreleri kullanan ancak android:exported belirtmeyen bir etkinlik, hizmet veya yayın alıcısı içeriyorsa kullandığınız Android Studio sürümüne bağlı olarak aşağıdaki uyarı mesajları görüntülenir:

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

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

Beklemedeki amaç değişkenliği değişikliğini test etme

Uygulamanızın değişkenlik beyanlarının 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 bu tür 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 haricinde arka planda çalışırken ön plan hizmetlerini başlatamaz. Bir uygulama arka planda çalışırken ön plan hizmeti başlatmaya çalışırsa bir istisna oluşur (birkaç özel durum hariç).

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

Tam alarm izni

Uygulamaları sistem kaynaklarını tasarruf etmeye teşvik etmek için Android 12 ve sonraki sürümleri hedefleyen ve tam alarm 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 alarm ayarlamak için kabul edilebilir kullanım alanları hakkında daha fazla bilgi edinin.

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

Uygulamanızı Android 12'yi hedeflemeye hazırlarken hata ayıklaması yapılabilir derleme varyantınızda davranış değişikliğini test amacıyla 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ğuyla İlgili Değişiklikler'i seçin. Görüntülenen ekranda uygulamanızın adına dokunun ve REQUIRE_EXACT_ALARM_PERMISSION ifadesini 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, kullanıcının en sonunda gördüğü ve etkileşimde bulunduğu etkinliği başlatan bir uygulama bileşenini başlatarak bildirim dokunma işlemlerine yanıt verir. 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 trambolini olarak kullanılan hizmetlerden veya yayın alıcılarından etkinlik başlatamaz. Başka bir deyişle, kullanıcı bir bildirime veya bildirim içindeki işlem düğmesine dokunduktan sonra, uygulamanız bir hizmetin veya yayın alıcısının içinde startActivity() çağrısı yapamaz.

Uygulamanız, bildirim trambolini işlevi gören bir hizmetten veya yayın alıcısından etkinlik başlatmaya çalıştığında, sistem etkinliğin başlamasını engeller ve Logcat'te aşağıdaki 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 davrandığını tanımlama

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

Uygulamanızı güncelleme

Uygulamanız, bildirim trambolini görevi gören bir hizmetten veya yayın alıcısından bir 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şkilendirilmiş bir PendingIntent nesnesi oluşturun.
  2. Bildiriminizi oluşturma sürecinin bir parçası olarak önceki adımda oluşturduğunuz PendingIntent nesnesini kullanın.

Örneğin, günlük kaydı gerçekleştirmek için etkinliğin kaynağını belirlemek amacıyla bildirimi yayınlarken ekstralar kullanın. Merkezi günlük kaydı için ActivityLifecycleCallbacks'i veya Jetpack yaşam döngüsü gözlemleyicilerini kullanın.

Davranışı aç/kapat

Uygulamanızın hata ayıklaması yapılabilir 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 uygulamaları hedefleyen uygulamalardaki yedekleme ve geri yükleme özelliğinin çalışma şeklinde değişiklikler yapılmıştır. Android yedekleme ve geri yükleme özelliğinin iki biçimi vardır:

  • Bulutta yedekleme: Kullanıcı verileri, daha sonra ilgili cihaza veya yeni bir cihaza geri yüklenebilmesi için kullanıcının Google Drive'ında depolanır.
  • Cihazdan cihaza (D2D) aktarımlar: Kullanıcı verileri, örneğin bir kablo kullanılarak 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 Kullanıcı verilerini Otomatik Yedekleme ile yedekleme ve Android Backup Service 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ümlerde çalışan ve bunları hedefleyen uygulamalar için:

  • XML yapılandırma mekanizmasıyla dahil etme ve hariç tutma kurallarını belirtmek, bulut tabanlı yedekleme ve geri yüklemeyi (ör. Google Drive yedekleri) etkilemeye devam etse de D2D aktarımlarını etkilemez. D2D aktarımları için kural belirlemek üzere bir sonraki bölümde ele alınacak yeni yapılandırmayı kullanmanız gerekir.

  • Bazı cihaz üreticilerinin cihazlarında android:allowBackup="false" belirtildiğinde Google Drive'a yedekleme 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ı olarak belirtmenizi gerektirerek Google Drive yedeklemesi ile D2D aktarımı arasındaki farkı açık hale getirir.

İsteğe bağlı olarak, yedekleme kurallarını belirtmek için de bunu kullanabilirsiniz. Bu durumda, Android 12 veya sonraki sürümleri çalıştıran cihazlarda daha önce kullanılan yapılandırma yok sayılır. Android 11 veya önceki sürümleri çalıştıran cihazlar için hâlâ eski yapılandırma 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 gösterilmektedir:

<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 harflerle 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 kullanıcı verilerini Otomatik Yedekleme ile yedekleme kılavuzunda ilgili bölüme bakı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ına işaret ettiğinizde, Android 12 veya sonraki sürümleri çalıştıran cihazlarda eski yapılandırmayı işaret eden android:fullBackupContent özelliği yok sayı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; BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE ve BLUETOOTH_CONNECT izinlerini kullanıma sunuyor. Bu izinler, Android 12'yi hedefleyen uygulamaların, özellikle de cihaz konumuna erişim gerektirmeyen uygulamalarda 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 belirtmek yerine daha modern bir Bluetooth izinleri grubunu beyan edin.

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

Android 12 (API düzeyi 31) veya sonraki sürümleri hedefleyen uygulamalar için eşler arası ve internet bağlantılarını destekleyen cihazlar hem eş cihaz hem de internet sağlayan birincil ağ ile eş zamanlı kablosuz bağlantı sürdürebilir ve böylece kullanıcı deneyimini daha sorunsuz hale getirebilir. Android 11 (API düzeyi 30) veya önceki sürümleri hedefleyen uygulamalar, eski davranışla karşılaşmaya devam eder. Bu durumda, eş cihaza bağlanmadan önce birincil kablosuz ağın bağlantısı kesilir.

Uyumluluk

WifiManager.getConnectionInfo(), WifiInfo özelliğini 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:

  • Sadece tek bir kablosuz ağ varsa onun WifiInfo 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 sesli 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ı ikili ağı destekleyen cihazlarda daha iyi bir kullanıcı deneyimi sağlamak için tüm uygulamaların, özellikle de eşler arası bağlantı tetikleyenlerin WifiManager.getConnectionInfo() çağrısından başka bir yere taşınmasını ve bunun yerine, NetworkCallback'ı kaydetmek için kullanılan NetworkRequest ile eşleşen tüm WifiInfo nesnelerini almak için NetworkCallback.onCapabilitiesChanged() kullanmasını öneririz. getConnectionInfo(), Android 12 itibarıyla kullanımdan kaldırılmıştır.

Aşağıdaki kod örneğinde, NetworkCallback içinde WifiInfo öğesinin 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'de, uygulamaların mDNSReplyer yerel API'sini kullanarak mDNSResponseer arka plan programı ile etkileşim kurabileceği zaman değişiyor. Daha önce, bir uygulama ağda bir hizmeti kaydettirdiğinde ve getSystemService() yöntemini çağırdığında, sistemin NSD hizmeti, uygulama henüz herhangi bir NsdManager yöntemi çağırmamış olsa bile mDNSResponseer arka plan programını başlatırdı. Ardından arka plan programı, cihazı tüm düğümlü çoklu yayın gruplarına abone olarak sistemin daha sık uyanmasına ve ek güç kullanmasına neden oldu. Pil kullanımını en aza indirmek için Android 12 ve sonraki sürümlerde sistem artık mDNSResponseer arka plan programını yalnızca NSD etkinlikleri için gerekli olduğunda başlatıp daha sonra durdurur.

Bu değişiklik mDNSResponseer arka plan programının ne zaman kullanılabilir olacağını etkilediğinden, getSystemService() yöntemini çağırdıktan sonra mDNSReplyer arka plan programının başlatılacağını varsayan uygulamalar, sistemden mDNSResponseer arka plan programının kullanılamadığını belirten iletiler 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 tedarikçileri 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 istendiğinde erişilebilir.

Uygulama, Android 11 (API düzeyi 30) veya altını hedefliyorsa <uses-native-library> etiketi gerekli değildir. Bu durumda, paylaşılan her yerel kitaplığa NDK kitaplığı olup olmadığına bakılmaksızın erişilebilir.

Güncellenen SDK dışı kısıtlamalar

Android 12, Android geliştiricileriyle yapılan ortak çalışmalara ve en son dahili testlere göre 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şikliklerden bazıları sizi hemen etkilemeyebilir. Bununla birlikte, şu anda bazı SDK dışı arayüzleri (uygulamanızın hedef API düzeyine bağlı olarak) kullanabilseniz de herhangi bir SDK olmayan yöntem veya alanın kullanılması her zaman uygulamanızın bozulma riskini artırır.

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