Bu sayfa, Cloud Translation API ile çevrilmiştir.

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 uygulamanızı 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 inceleyin.

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ı 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ümleri içeren bildirimler artık bildirim alanının tamamını kullanmaz. Bunun yerine sistem, standart bir şablon uygular. Bu şablon, özel bildirimlerin tüm durumlarda diğer bildirimlerle aynı süslemeye (ör. bildirimin simgesi ve genişleme olanakları (daraltılmış durumda)) ve bildirimin simgesi, uygulama adı ve daraltma olanağı (genişletilmiş durumda)) sahip olmasını sağlar. Bu davranış, Notification.DecoratedCustomViewStyle ile neredeyse aynıdır.

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

Aşağıdaki görselde 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'un özel alt sınıflarını tanımlayan veya Notification.Builder'in 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 etmenizi öneririz.

Ö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.
Özel görünümler kullanan tüm bildirimleri test edin ve gölgede beklediğiniz gibi göründüğünden emin olun. Test sırasında aşağıdaki hususları göz önünde bulundurun ve gerekli düzenlemeleri yapın:
- Özel görünümlerin boyutları değişti. Genel olarak, özel bildirimlerin izin verilen yüksekliği öncekinden daha azdır. Daraltılmış durumdayken özel içeriğin maksimum yüksekliği 106 dp'den 48 dp'ye düşürülmüştür. Ayrıca yatay alan daha azdır.
- 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'i de kullanmanız gerektiği anlamına gelir.
- "Uyarı" durumunun istediğiniz gibi görünmesini sağlamak için bildirim kanalının önemini "YÜKSEK" olarak ayarlayın (Ekranda açılır).

Android App Links doğrulama değişiklikleri

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ştiricilere 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ını kullanıyorsanız Android App Link doğrulaması için intent 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ışı iyileştirmeleri

Android 12, pencere içinde pencere (PiP) modu için davranış iyileştirmeleri ve hem hareket tabanlı gezinme hem de öğeye dayalı gezinme için geçiş animasyonlarında önerilen görsel iyileştirmeler sunar.

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

Yeniden tasarlanan Toast

Android 12'de kısa mesaj görünümü yeniden tasarlandı. Bildirimler artık iki satır metinle sınırlıdır ve metnin yanında uygulama simgesi gösterilir.

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

Daha fazla bilgi için Toast'lara 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 için yaklaşık konum doğruluğu isteyebilir.

WebView'de modern SameSite çerezleri

Android'in WebView bileşeni, Google'ın Chrome tarayıcısını destekleyen açık kaynak projesi olan Chromium'u temel alı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şlenmesiyle ilgili değişiklikler yaptı. Android 12'den itibaren, uygulamalar Android 12'yi (API düzeyi 31) veya sonraki sürümleri hedeflediğinde bu değişiklikler WebView'e de dahil edilir.

Bir çerezin SameSite özelliği, çerezin tüm isteklerle 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 siteler arası istenmeyen paylaşımlara karşı koruma sağlar:

SameSite özelliği olmayan çerezler SameSite=Lax olarak kabul edilir.
SameSite=None içeren çerezlerde Secure özelliği de belirtilmelidir. 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 değerlendirilir. Bu nedenle, uygun şekilde SameSite=None; Secure olarak işaretlenmediği sürece çerezler gönderilmez.

Geliştiriciler için genel öneri, 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 veya HTTP'den HTTPS'ye geçen aynı sitedeki gezinmelerde çalışmasına izin verilen çerezleri açıkça belirtmeniz gerekir.

Web geliştiricileri için bu değişikliklerle ilgili tam rehberlik için SameSite Çerezleri Hakkında Bilgi ve Schemeful SameSite başlıklı makalelere bakı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'de test etmenizi öneririz. Sorun bulursanız çerezlerinizi yeni SameSite davranışlarını destekleyecek şekilde güncellemeniz gerekebilir.

Girişlerde ve yerleştirilmiş içeriklerde, 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 sorunlar olup olmadığını kontrol edin.

Bir uygulamayı Web Görünümü 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:

WebView devtools'de kullanıcı arayüzü işaretçisini webview-enable-modern-cookie-same-site olarak değiştirerek test cihazında SameSite davranışlarını manuel olarak etkinleştirin.

Bu yaklaşım, Android 5.0 (API düzeyi 21) veya sonraki sürümleri (Android 12 dahil) ve WebView 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 yüklü bir cihaz kullanmanız gerekir.

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

Diğer kaynaklar

SameSite'in modern davranışları ve Chrome ile WebView'de kullanıma 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 sorun takipçisinde bildirebilirsiniz.

Hareket sensörleri hız sınırlıdı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örlerinden ve konum sensörlerinden gelen verilerin yenilenme hızını sınırlar.

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 izinlerin otomatik olarak sıfırlanması davranışını genişletir. Uygulamanız Android 12'yi hedefliyorsa ve kullanıcı birkaç ay boyunca uygulamanızla etkileşime geçmiyorsa sistem, verilen tüm izinleri otomatik olarak sıfırlar ve uygulamanızı uyku durumuna alır.

Uygulama kış uykusu kılavuzundan 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, 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, 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 verilerini kullanı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 filtrelerini kullanan etkinlikler, hizmetler veya yayın alıcıları içeriyorsa bu uygulama bileşenleri için android:exported özelliğini açıkça belirtmeniz 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 bir 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ız, intent filtreleri kullanan ancak android:exported bildirmeyen 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österilir:

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

Aşağıdaki mesajlar gösterilir:

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

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

Uygulamanızı derlemeye çalıştığınızda aşağıdaki derleme hatası 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ışı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.

Beklemede olan intent değişkenliği değişikliğini test etme

Uygulamanızda 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 başlatmaları

Android 12 ve sonraki sürümler, platform güvenliğini iyileştirmek için intent'lerin güvenli olmayan başlatmalarını algılayan bir hata ayıklama özelliği sunar. Sistem bu tür güvenli olmayan bir başlatma tespit ettiğinde StrictMode ihlali meydana gelir.

Performans

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

Android 12 veya sonraki sürümleri hedefleyen uygulamalar, birkaç özel durum hariç olmak üzere 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 hızlandırılmış çalışma planlamak ve başlatmak için WorkManager'ı kullanmayı düşünün. Kullanıcının istediği, zamana duyarlı işlemleri tamamlamak için ön plan hizmetlerini tam alarm içinde başlatın.

Tam alarm izni

Uygulamaların sistem kaynaklarını korumasını 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şimi olmalıdır.

Bu özel uygulama erişimini elde etmek için manifest dosyasında SCHEDULE_EXACT_ALARM iznine izin verin.

Tam alarmlar yalnızca kullanıcılara yönelik özelliklerde kullanılmalıdır. Tam saat 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 hedeflemeye hazırlarken, hata ayıklama 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ğu Değişiklikleri'ni seçin. Görünen ekranda uygulamanızın adına dokunun, ardından REQUIRE_EXACT_ALARM_PERMISSION ayarını 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 atlama kısıtlamaları

Kullanıcılar bildirimlerle etkileşime geçtiğinde bazı uygulamalar, bildirim dokunmalarına yanıt olarak bir uygulama bileşeni başlatır. Bu bileşen, kullanıcının gördüğü ve etkileşime geçtiği etkinliği başlatır. Bu uygulama bileşenine bildirim trambolini adı verilir.

Uygulama performansını ve kullanıcı deneyimini iyileştirmek için Android 12 veya sonraki sürümleri hedefleyen uygulamalar, bildirim trambolinleri 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 işlem düğmesine dokunduktan sonra uygulamanız bir hizmet veya yayın alıcısının içinde startActivity() çağıramaz.

Uygulamanız, bildirim atlama tahtası 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örünür:

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

Bildirim trampolini olarak hangi uygulama bileşenlerinin kullanıldığını belirleme

Uygulamanızı test ederken bir bildirime dokunduktan sonra, uygulamanızda bildirim trambolini olarak hangi hizmetin veya yayın alıcısının kullanıldığını belirleyebilirsiniz. Bunu yapmak için aşağıdaki terminal komutunun çıktısı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ıyor. Bu bölümde, bildirim dokunuşu sonucunda başlayan bileşeni tanımlamak için gerekli bilgiler yer alır.

Uygulamanızı güncelleme

Uygulamanız, bildirim trambolini olarak işlev 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:

Kullanıcıların bildirime dokunduktan sonra gördüğü etkinlikle ilişkili bir PendingIntent nesnesi oluşturun.
Bildiriminizi oluşturma kapsamında ö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 ek özellikleri kullanın. Merkezi günlük kaydı için ActivityLifecycleCallbacks veya Jetpack yaşam döngüsü gözlemcileri'ni kullanın.

Davranışı açma/kapatma

Uygulamanızın hata ayıklama yapılabilir 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ükleme işlevinin işleyiş şekli değişti. Android yedekleme ve geri yükleme işleminin iki biçimi vardır:

Bulut yedeklemeleri: Kullanıcı verileri, daha sonra bu cihazda veya yeni bir cihazda geri yüklenebilmesi için kullanıcının Google Drive'ında saklanır.
Cihazlar arası (D2D) aktarımlar: Kullanıcı verileri, kablo kullanılarak eski cihazdan doğrudan kullanıcının yeni cihazına gönderilir.

Verilerin nasıl yedeklenip geri yükleneceğ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.

D2D aktarım işleviyle ilgili 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ın belirtilmesi, cihazlar arası aktarımları etkilemez ancak bulut tabanlı yedekleme ve geri yüklemeyi (ör. Google Drive yedeklemeleri) etkiler. D2D aktarımlarıyla ilgili kuralları belirtmek için sonraki bölümde açıklanan yeni yapılandırmayı kullanmanız gerekir.
Bazı cihaz üreticilerinin cihazlarında android:allowBackup="false" belirtildiğinde Google Drive'a yapılan yedeklemeler devre dışı bırakılır ancak uygulama için cihazlar arası aktarım devre dışı bırakılmaz.

Yeni dahil etme ve hariç tutma biçimi

Android 12 ve sonraki sürümleri çalıştıran ve 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 zorunlu kılarak Google Drive yedekleme ile D2D aktarımı arasındaki farkı açıkça ortaya koyar.

İsteğe bağlı olarak, yedeklemeyle ilgili kuralları belirtmek için de bu özelliği 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 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 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ö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, Android 12 veya sonraki sürümleri çalıştıran 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, Android 12'yi hedefleyen uygulamaların Bluetooth cihazlarla etkileşim kurmasını kolaylaştırır. Özellikle de cihaz konumuna erişim gerektirmeyen uygulamalar için bu durum 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 grubu yerine daha modern bir Bluetooth izinleri grubu tanımlayın.

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

Android 12 (API düzeyi 31) veya sonraki sürümleri hedefleyen uygulamalarda, eşzamanlı eşler arası ve internet bağlantılarını destekleyen cihazlar hem eş cihazla hem de birincil internet sağlayıcı ağ ile eşzamanlı kablosuz bağlantılar sağlayarak kullanıcı deneyimini daha sorunsuz hale getirebilir. Android 11 (API düzeyi 30) veya önceki sürümleri hedefleyen uygulamalarda, eş cihaza bağlanmadan önce birincil kablosuz ağın bağlantısının kesildiği eski davranış hâlâ geçerlidir.

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 şekilde değiştirildi:

Yalnızca tek bir kablosuz ağ varsa 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 arama uygulaması eşler arası bağlantı tetiklemediyse birincil internet bağlantısının WifiInfo döndürülür.

Eşzamanlı çift kablosuz ağları 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ından vazgeçmesini ve bunun yerine NetworkCallback'yi kaydettirmek için kullanılan NetworkRequest ile eşleşen tüm WifiInfo nesnelerini almak üzere NetworkCallback.onCapabilitiesChanged() kullanmasını öneririz. getConnectionInfo() desteği Android 12'den itibaren sonlandırıldı.

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 daemon'ı ile etkileşime geçebileceği durumlarla ilgili değişiklikler yapar. Daha önce, bir uygulama ağda bir 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 daemon'ını başlatıyordu. Ardından daemon, cihazı tüm düğümler çoklu yayın gruplarına kaydetti. Bu da sistemin daha sık uyandığına ve ek güç kullandığına neden oldu. Android 12 ve sonraki sürümlerde sistem, pil kullanımını en aza indirmek için mDNSResponder daemon'ını yalnızca NSD etkinlikleri için gerektiğinde başlatır ve daha sonra durdurur.

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

Tedarikçi firma 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 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 sürümleri 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ştiricilerle yapılan ortak çalışmalara ve en son şirket içi 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ılabildiğinden 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ışı herhangi bir yöntem veya alanı kullanmak her zaman uygulamanızın bozulma riskini artırır.

Uygulamanızda SDK dışı arayüzlerin kullanılıp kullanılmadığını öğrenmek için uygulamanızı test edebilirsiniz. Uygulamanız SDK dışı arayüzlere dayanıyorsa SDK alternatiflerine geçiş planlamaya başlamanız gerekir. Bununla birlikte, bazı uygulamaların SDK dışı arayüzleri kullanmanın geçerli kullanım alanları olduğunu biliyoruz. 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 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.