Ö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 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. Önceden özel bildirimler, bildirim alanının tamamını kullanabiliyordu ve kendi düzenlerini ve stillerini sağlayabiliyordu. Bu durum, kullanıcıların kafasını karıştırabilecek veya farklı cihazlarda düzen uyumluluğu sorunlarına neden olabilecek karşıt kalıplar ortaya çıktı.
Android 12'yi hedefleyen uygulamalarda, özel içerik görünümleri içeren bildirimler artık bildirim alanının tamamını kullanmayacaktır. 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 fırsatları (daraltılmış durumda), bildirim simgesi, uygulama adı ve daraltma olanağı (genişletme durumunda) bu şekilde olur. Bu davranış, Notification.DecoratedCustomViewStyle
ile hemen hemen aynıdır.
Bu sayede Android 12, kullanıcılar için bulunabilir ve alışık olduğunuz bildirim genişletme özelliği sayesinde tüm bildirimleri görsel olarak tutarlı ve kolayca taranır.
Aşağıdaki görselde standart şablondaki bir özel 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
'in özel alt sınıflarını tanımlayan veya Notification.Builder
'in setCustomContentView(RemoteViews)
, setCustomBigContentView(RemoteViews)
ve setCustomHeadsUpContentView(RemoteViews)
yöntemlerini kullanan uygulamaları etkileyecektir.
Uygulamanız tamamen özel bildirimler kullanıyorsa en kısa sürede yeni şablonu test etmenizi öneririz.
Özel bildirim değişikliğini etkinleştirme:
- Yeni davranışı etkinleştirmek için uygulamanızın
targetSdkVersion
değeriniS
olarak değiştirin. - Yeniden derleyin.
- Uygulamanızı Android 12 çalıştıran bir cihaza veya emülatöre yükleyin.
- Yeni davranışı etkinleştirmek için uygulamanızın
Özel görünümler kullanan tüm bildirimleri test ederek, gölgede beklediğiniz gibi göründüklerinden emin olun. Test yaparken 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 bildirimler için sağlanan yükseklik eskisinden 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.
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çinsetBigCustomContentView
kullanmanızın da yararlı olacağı 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 görünür) olarak artırmayı unutmayın.
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 iyileştirir 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 App Link doğrulamasını kullanı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 sunuyor ve hem hareketle gezinme hem de öğe tabanlı gezinme için geçiş animasyonlarında kozmetik iyileştirmeler öneriliyor.
Daha fazla bilgi için Pencere içinde pencere iyileştirmeleri bölümüne bakın.
Yeni tost tasarımı
Android 12'de, toast görünümü yeniden tasarlandı. Kısa mesajlar artık iki satır metinle sınırlı ve metnin yanında uygulama simgesi gösteriliyor.

Daha ayrıntılı bilgi 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 için yaklaşık konum doğruluğu talep edebilir.
Web Görünümü'nde modern SameSite çerezleri
Android’in Web Görünümü bileşeni, Google'ın Chrome tarayıcısını destekleyen açık kaynak projesi 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, bu değişiklikler Android 12 (API düzeyi 31) veya sonraki sürümleri hedefleyen uygulamalar için de WebView
uygulamasına dahil edilecektir.
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şı koruma sağlamaya yardımcı olur:
SameSite
özelliği olmayan çerezlerSameSite=Lax
olarak kabul edilir.SameSite=None
içeren çerezler deSecure
özelliğini belirtmelidir. Bu, güvenli bir bağlam gerektirdiği ve HTTPS üzerinden gönderilmelidir.- 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önderilmemektedir.
Geliştiriciler için genel rehberlik, 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 rehberlik 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çtiği 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şik içerikle ilgili sorunlara dikkat edin.
Bir uygulamayı Web Görünümü ile test etmek istiyorsanız aşağıdaki adımlardan birini tamamlayarak test etmek istediğiniz uygulama için yeni SameSite davranışlarını etkinleştirmeniz gerekir:
Web Görünümü geliştirme araçlarında kullanıcı arayüzü işaretini açıp kapatarak 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 çalıştıran tüm cihazlarda (Android 12 dahil) ve WebView 89.0.4385.0 veya sonraki sürümleri çalıştıran cihazlarda test yapmanıza olanak tanır.
Uygulamanızı,
targetSdkVersion
ile 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şlayın bölümüne bakın.
Diğer kaynaklar
SameSite'ın 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 Updates 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örlerinin 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 yenileme hızı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ı daha da 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 bekletme durumuna geçirir.
Uygulamayı hazırda bekletme ile ilgili kılavuzdan daha fazla bilgi edinebilirsiniz.
Veri erişimi denetiminde ilişkilendirme beyanı
Android 11'de (API düzeyi 30) kullanıma sunulan veri erişimi 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, özel uygulama verilerinin korunmasına yardımcı olmak için adb backup
komutunun varsayılan davranışını değiştirir. Android 12 (API düzeyi 31) veya sonraki sürümleri hedefleyen uygulamalarda, bir kullanıcı 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
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 aktarmaya kaydolabilirsiniz.
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 birçok 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 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ızda, amaç 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örüntülenir:
Android Studio 2020.3.1 Canary 11 veya sonraki sürümler
Aşağıdaki mesajlar görünür:
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 hata 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 intent'ler 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 intent değişkenliği değişikliğini test etme
Uygulamanızın değişkenlik bildirimlerinin eksik olup olmadığını belirlemek için Android Studio'da aşağıdaki lint uyarısına bakı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 girişim başlatmalarını algılayan bir hata ayıklama özelliği sunar. Sistem, güvenli olmayan bir başlatma tespit ettiğinde 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 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 ön plan hizmetlerini tam 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 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ıya yönelik özellikler için kullanılmalıdır. Kesin bir alarm ayarlamak için kabul edilebilir kullanım alanları hakkında daha fazla bilgi edinin.
Davranış değişikliğini devre dışı bırakma
Uygulamanızı Android 12'yi hedefleyecek şekilde hazırlarken 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ğuyla İlgili Değişiklikler'i seçin. Görüntülenen ekranda uygulamanızın adına dokunun ve ardından REQUIRE_EXACT_ALARM_PERMISSION işlevini 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şim kurduğunda, bazı uygulamalar bildirim dokunma işlemlerine yanıt vermek için kullanıcının nihayet gördüğü ve etkileşimde bulunduğu etkinliği başlatan bir uygulama bileşenini 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 trambolini olarak kullanılan hizmetlerden veya yayın alıcılarından etkinlik başlatamaz. Diğer bir deyişle, kullanıcı bildirimdeki bir bildirime veya işlem düğmesine dokunduktan sonra uygulamanız bir hizmetin veya yayın alıcısının içinde startActivity()
'i çağıramaz.
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 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 davranacağını tanımlama
Uygulamanızı test ederken bir bildirime dokunduktan sonra, hangi hizmetin veya yayın alıcısı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 "NotifEngagementLog" metni yer alır. Bu bölümde, bildirime dokunma işleminin sonucunda başlayan bileşeni tanımlamak için gerekli 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:
- Kullanıcıların bildirime dokunduktan sonra gördükleri etkinlikle ilişkili bir
PendingIntent
nesnesi oluşturun. - Bildiriminizi oluşturma işleminin bir parçası olarak önceki adımda oluşturduğunuz
PendingIntent
nesnesini kullanın.
Örneğin, günlük kaydı oluşturmak amacıyla etkinliğin kaynağını belirlemek için bildirimi yayınlarken ekstraları kullanın. Merkezi günlük kaydı için ActivityLifecycleCallbacks veya Jetpack yaşam döngüsü gözlemleyicileri kullanın.
Davranışı aç/kapat
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 (API düzeyi 31) üzerinde çalışan ve bunları hedefleyen uygulamalarda yedekleme ve geri yüklemenin çalışma şeklinde değişiklikler yapılmıştır. Android yedekleme ve geri yükleme özelliğinin iki biçimi vardır:
- Bulut yedeklemeleri: 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 Anahtar/değer çiftlerini Android Backup Service ile yedekleme bölümlerine bakın.
D2D aktarım işleviyle ilgili değişiklikler
Android 12 ve sonraki sürümlerde çalışan ve bunları hedefleyen uygulamalar için:
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.XML yapılandırma mekanizmasıyla içerme ve hariç tutma kurallarının belirtilmesi, Google Drive yedeklerini etkilemeye devam etse de D2D aktarımlarını artık etkilemez. D2D aktarımları için kural belirlemek istiyorsanız bir sonraki bölümde ele alınan yeni yapılandırmayı kullanmanız gerekir.
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ımlar için dahil etme ve hariç tutma kurallarını ayrı olarak belirtmenizi gerektirerek Google Drive yedeklemesi ile D2D aktarımı arasındaki farkı ortaya çıkarır.
İsteğe bağlı olarak, yedekleme kurallarını belirtmek için de bu API'yi kullanabilirsiniz. Bu durumda, Android 12 veya sonraki sürümleri çalıştıran cihazlarda eski 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 gerekir.
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, 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 Otomatik Yedekleme ile kullanıcı verilerini 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'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 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ş zamanlı eşler arası ve internet bağlantılarını destekleyen cihazlar hem eş cihaza hem de internet sağlayan birincil ağa aynı anda kablosuz bağlantı sunarak kullanıcı deneyimini daha sorunsuz hale getirebilir. Android 11 (API düzeyi 30) veya önceki sürümleri hedefleyen uygulamalarda, birincil kablosuz ağın eş cihaza bağlanmadan önce bağlantısı kesilen eski davranış geçerli olmaya devam eder.
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ştirildi:
- Yalnızca tek bir kablosuz ağ varsa
WifiInfo
değeri döndürülür. - Birden fazla kablosuz ağ varsa ve arama uygulaması eşler arası bağlantıyı tetiklediyse eş cihaza karşılık gelen
WifiInfo
döndürülür. - Birden fazla kablosuz ağ varsa ve arama uygulaması eşler arası bağlantı tetiklemediyse internet sağlayan birincil bağlantının
WifiInfo
döndürülür.
Eşzamanlı çift kablosuz ağı destekleyen cihazlarda daha iyi bir kullanıcı deneyimi sağlamak için tüm uygulamaların, özellikle de eşler arası bağlantıları tetikleyen uygulamaların WifiManager.getConnectionInfo()
çağrısından farklı cihazlara taşınması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()
kullanılmasını öneririz. getConnectionInfo()
, Android 12 itibarıyla kullanımdan kaldırılmıştır.
Aşağıdaki kod örneğinde, WifiInfo
öğesini bir NetworkCallback
içinde nasıl edineceğiniz 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; ... } ... };
mDNSResponseer yerel API'si
Android 12, uygulamaların mDNSResponseer yerel API'sini kullanarak mDNSYanıter arka plan programı ile etkileşim kurabileceği zaman değişir.
Daha önce, bir uygulama ağda bir hizmeti kaydettirdiğinde ve getSystemService()
yöntemini çağırdığında, sistemin NSD hizmeti, uygulama henüz hiçbir NsdManager
yöntemini çağırmamış olsa bile mDNSResponseer arka plan programını başlatıyordu. Arka plan programı daha sonra cihazı tüm düğümleri içeren çoklu yayın gruplarına abone olarak sistemin daha sık uyanmasına ve ek güç kullanmasına neden olur. 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 mDNSResponseer arka plan programının başlatılacağını varsayan uygulamalar, sistemden mDNSResponseer arka plan programının kullanılamadığını belirten mesajlar alabilir. NsdManager
kullanan ve mDNSResponseer yerel API'sini kullanmayan uygulamalar bu değişiklikten etkilenmeyecektir.
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 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 önceki sürümleri hedefliyorsa <uses-native-library>
etiketi gerekli değildir. Bu durumda, yerel paylaşılan 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ılabildiğinden emin oluyoruz.
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) kullanabiliyor olsanız da SDK olmayan herhangi bir yöntemi veya alanı kullanmak her zaman uygulamanızın bozulma riskini taşı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üzleri kullanıyorsa SDK alternatiflerine geçiş planlamaya başlamanız gerekir. Yine de, bazı uygulamaların SDK dışı arayüzler için geçerli kullanım alanları olduğunu biliyoruz. Uygulamanızdaki bir özellik için SDK dışı arayüz kullanmaya alternatif bulamıyorsanız yeni bir herkese açık API istemeniz 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 göz atın. Genel olarak SDK olmayan arayüzler hakkında daha fazla bilgi edinmek için SDK olmayan arayüzlerle ilgili kısıtlamalar bölümünü inceleyin.