Android 16 platformunda, uygulamanızı etkileyebilecek davranış değişiklikleri vardır. Aşağıdaki davranış değişiklikleri, targetSdkVersion
'ten bağımsız olarak Android 16'da çalıştırılan tüm uygulamalar için geçerlidir. Uygulamanızı test etmeniz ve ardından geçerli olduğu durumlarda bu değişiklikleri desteklemek için gerektiği gibi değiştirmeniz gerekir.
Yalnızca Android 16'yı hedefleyen uygulamaları etkileyen davranış değişiklikleri listesini de inceleyin.
Temel işlevler
Android 16 (API düzeyi 36), Android sisteminin çeşitli temel özelliklerini değiştiren veya genişleten aşağıdaki değişiklikleri içerir.
JobScheduler kota optimizasyonları
Android 16'dan itibaren, normal ve hızlandırılmış iş yürütme çalışma süresi kotasını aşağıdaki faktörlere göre ayarlıyoruz:
- Uygulamanın bulunduğu uygulama bekleme grubu: Android 16'da, etkin bekleme grupları geniş bir çalışma süresi kotasıyla uygulanmaya başlayacaktır.
- İş, uygulama üst durumdayken çalışmaya başlarsa: Android 16'da, uygulama kullanıcı tarafından görünür durumdayken başlatılan ve uygulama görünmez hale geldikten sonra devam eden işler, iş çalışma süresi kotasına uyar.
- İş, bir ön plan hizmeti çalışırken yürütülüyorsa: Android 16'da, bir ön plan hizmetiyle eşzamanlı olarak yürütülen işler iş çalışma süresi kotasına uyar. Kullanıcı tarafından başlatılan veri aktarımı için işlerden yararlanıyorsanız bunun yerine kullanıcı tarafından başlatılan veri aktarım işlerini kullanmayı düşünebilirsiniz.
Bu değişiklik, WorkManager, JobScheduler ve DownloadManager kullanılarak planlanan görevleri etkiler. Bir işin neden durdurulduğunu hata ayıklamak için WorkInfo.getStopReason()
'u çağırarak işinizin neden durdurulduğunu kaydetmenizi öneririz (JobScheduler işleri için JobParameters.getStopReason()
'i çağırın).
Uygulamanızın durumunun kullanabileceği kaynakları nasıl etkilediği hakkında bilgi edinmek için Güç yönetimi kaynak sınırları başlıklı makaleyi inceleyin. Pil kullanımı için en iyi uygulamalar hakkında daha fazla bilgi edinmek isterseniz görev planlama API'leri için pil kullanımını optimize etme konulu makaleyi inceleyin.
Ayrıca, bir işin neden yürütülmediğini anlamak için Android 16'da kullanıma sunulan yeni JobScheduler#getPendingJobReasonsHistory
API'den yararlanmanızı öneririz.
Test
Uygulamanızın davranışını test etmek için uygulama Android 16 cihazda çalışıyorsa belirli iş kotası optimizasyonlarının geçersiz kılınmasını etkinleştirebilirsiniz.
"Üst durum, iş çalışma zamanı kotasına bağlı olacak" kuralının uygulanmasını devre dışı bırakmak için aşağıdaki adb
komutunu çalıştırın:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME
"Ön plan hizmetiyle eşzamanlı olarak yürütülen işler, iş çalışma süresi kotasına uymalıdır" kuralının uygulanmasını devre dışı bırakmak için aşağıdaki adb
komutunu çalıştırın:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME
Belirli uygulama bekleme grubu davranışlarını test etmek için aşağıdaki adb
komutunu kullanarak uygulamanızın uygulama bekleme grubunu ayarlayabilirsiniz:
adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted
Uygulamanızın bulunduğu uygulama bekleme grubunu anlamak için aşağıdaki adb
komutunu kullanarak uygulamanızın uygulama bekleme grubunu alabilirsiniz:
adb shell am get-standby-bucket APP_PACKAGE_NAME
Terk edilmiş boş işlerin durdurulma nedeni
İşle ilişkili JobParameters
nesnesi çöp toplandıysa ancak iş tamamlandığını belirtmek için JobService#jobFinished(JobParameters,
boolean)
çağrılmadıysa iş terk edilmiş olur. Bu, işin uygulamanın bilgisi olmadan çalıştığını ve yeniden planlandığını gösterir.
JobScheduler'ı kullanan uygulamalar JobParameters
nesnesine güçlü bir referans sağlamaz ve zaman aşımı artık STOP_REASON_TIMEOUT
yerine yeni iş durdurma nedeni STOP_REASON_TIMEOUT_ABANDONED
ile verilir.
Yeni terk edilmiş duraklatma nedeni sık sık gerçekleşirse sistem, iş sıklığını azaltmak için azaltma adımları atar.
Uygulamalar, terk edilmiş işleri tespit edip azaltmak için yeni durdurma nedenini kullanmalıdır.
WorkManager, AsyncTask veya DownloadManager kullanıyorsanız bu API'ler iş yaşam döngüsünü uygulamanız adına yönettiğinden bu değişiklikten etkilenmezsiniz.
JobInfo#setImportantWhileForeground desteğinin tamamen sonlandırılması
JobInfo.Builder#setImportantWhileForeground(boolean)
yöntemi, planlama uygulaması ön plandayken veya geçici olarak arka plan kısıtlamalarından muafken bir işin önemini belirtir.
Bu yöntem, Android 12 (API düzeyi 31) sürümünden itibaren kullanımdan kaldırılmıştır. Android 16'dan itibaren bu yöntem artık etkili bir şekilde çalışmaz ve bu yöntem çağrılırsa yoksayılır.
Bu işlev kaldırma işlemi JobInfo#isImportantWhileForeground()
için de geçerlidir. Android 16'dan itibaren, yöntem çağrılırsa false
döndürülür.
Sıralı yayın önceliği kapsamı artık global değil
Android apps are allowed to define priorities on broadcast receivers to control
the order in which the receivers receive and process the broadcast. For
manifest-declared receivers, apps can use the
android:priority
attribute to define the priority and for
context-registered receivers, apps can use the
IntentFilter#setPriority()
API to define the priority. When
a broadcast is sent, the system delivers it to receivers in order of their
priority, from highest to lowest.
In Android 16, broadcast delivery order using the android:priority
attribute
or IntentFilter#setPriority()
across different processes will not be
guaranteed. Broadcast priorities will only be respected within the same
application process rather than across all processes.
Also, broadcast priorities will be automatically confined to the range
(SYSTEM_LOW_PRIORITY
+ 1,
SYSTEM_HIGH_PRIORITY
- 1). Only system components will be
allowed to set SYSTEM_LOW_PRIORITY
, SYSTEM_HIGH_PRIORITY
as broadcast
priority.
Your app might be impacted if it does either of the following:
- Your application has declared multiple processes with the same broadcast intent, and has expectations around receiving those intents in a certain order based on the priority.
- Your application process interacts with other processes and has expectations around receiving a broadcast intent in a certain order.
If the processes need to coordinate with each other, they should communicate using other coordination channels.
ART'daki dahili değişiklikler
Android 16, Android Runtime'da (ART) performansı artıran ve ek Java özellikleri için destek sağlayan en son güncellemeleri içerir. Google Play sistem güncellemeleri sayesinde bu iyileştirmeler, Android 12 (API düzeyi 31) ve sonraki sürümleri çalıştıran bir milyardan fazla cihazda da kullanılabilir.
Bu değişiklikler kullanıma sunulduğunda, ART'nin dahili yapılarına dayanan kitaplıklar ve uygulama kodları, Android 16 çalıştıran cihazların yanı sıra Google Play sistem güncellemeleri aracılığıyla ART modülünü güncelleyen önceki Android sürümlerinde düzgün çalışmayabilir.
Dahili yapılara (ör. SDK dışı arayüzler) güvenmek her zaman uyumluluk sorunlarına yol açabilir. Ancak ART değişiklikleri cihazın çalıştığı platform sürümüne bağlı olmadığı ve Google Play sistem güncellemeleri aracılığıyla bir milyardan fazla cihaza dağıtıldığı için özellikle dahili ART yapılarından yararlanan koda (veya kod içeren kitaplıklara) güvenmekten kaçınmak önemlidir.
Tüm geliştiriciler, uygulamalarını Android 16'da ayrıntılı bir şekilde test ederek uygulamalarının etkilenip etkilenmediğini kontrol etmelidir. Ayrıca, uygulamanızın dahili ART yapılarına dayalı olarak tespit ettiğimiz kitaplıklara bağımlı olup olmadığını görmek için bilinen sorunları kontrol edin. Etkilenen uygulama kodunuz veya kitaplık bağımlılıklarınız varsa mümkün olduğunda herkese açık API alternatifleri arayın ve sorun takipçimizde özellik isteği oluşturarak yeni kullanım alanları için herkese açık API'ler isteyin.
16 KB sayfa boyutu uyumluluk modu
Android 15 introduced support for 16 KB memory pages to optimize performance of the platform. Android 16 adds a compatibility mode, allowing some apps built for 4 KB memory pages to run on a device configured for 16 KB memory pages.
When your app is running on a device with Android 16 or higher, if Android
detects that your app has 4 KB aligned memory pages, it automatically uses
compatibility mode and display a notification dialog to the user. Setting the
android:pageSizeCompat
property in the AndroidManifest.xml
to enable the
backwards compatibility mode will prevent the display of the dialog when your
app launches. To use the android:pageSizeCompat
property, compile your app
using the Android 16 SDK.
For best performance, reliability, and stability, your app should still be 16 KB aligned. Check out our recent blog post on updating your apps to support 16 KB memory pages for more details.

Kullanıcı deneyimi ve sistem kullanıcı arayüzü
Android 16 (API düzeyi 36), daha tutarlı ve sezgisel bir kullanıcı deneyimi sunmak için tasarlanmış aşağıdaki değişiklikleri içerir.
Kullanımı engelleyen erişilebilirlik duyurularının desteğinin sonlandırılması
Android 16, announceForAccessibility
kullanımı veya TYPE_ANNOUNCEMENT
erişilebilirlik etkinliklerinin gönderilmesiyle karakterize edilen erişilebilirlik duyurularını desteklememektedir. Bu durum, TalkBack ve Android'in ekran okuyucusunun kullanıcıları için tutarsız kullanıcı deneyimleri oluşturabilir. Alternatifler ise Android'in çeşitli yardımcı teknolojileri genelinde daha geniş bir kullanıcı ihtiyacı yelpazesine daha iyi hizmet eder.
Alternatiflere örnekler:
- Pencere değişiklikleri gibi önemli kullanıcı arayüzü değişiklikleri için
Activity.setTitle(CharSequence)
vesetAccessibilityPaneTitle(java.lang.CharSequence)
değerlerini kullanın. Oluştur'daModifier.semantics { paneTitle = "paneTitle" }
simgesini kullanarak - Kullanıcıyı kritik kullanıcı arayüzündeki değişiklikler hakkında bilgilendirmek için
setAccessibilityLiveRegion(int)
simgesini kullanın. Oluştur'daModifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]}
simgesini kullanın . Bu bildirimler, bir görünüm her güncellendiğinde bildirim oluşturabileceğinden, dikkatli bir şekilde kullanılmalıdır. - Kullanıcıları hatalar hakkında bilgilendirmek için
AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR
türündeki birAccessibilityEvent
gönderin veAccessibilityNodeInfo#setError(CharSequence)
değerini ayarlayın veyaTextView#setError(CharSequence)
kullanın.
Kullanımdan kaldırılan announceForAccessibility
API'nin referans dokümanlarında, önerilen alternatifler hakkında daha fazla bilgi verilmektedir.
3 düğmeli gezinme desteği
Android 16, tahmini geriye doğru geçişi doğru şekilde gerçekleştiren uygulamalarda 3 düğmeli gezinme için tahmini geri desteği sunar. Geri düğmesine uzun bastığınızda tahmini geri animasyonu başlatılır. Bu animasyon, geri kaydırmanın sizi nereye götüreceğinin önizlemesini gösterir.
Bu davranış, sistem animasyonları (ana sayfaya geri gitme, görevler arası ve etkinlikler arası) dahil olmak üzere sistemin tahmine dayalı geri animasyonlarını destekleyen tüm alanlarında geçerlidir.
Cihaz form faktörleri
Android 16 (API seviyesi 36), sanal cihaz sahipleri tarafından ekranlara yansıtılan uygulamalar için aşağıdaki değişiklikleri içerir.
Sanal cihaz sahibinin geçersiz kılma işlemleri
Sanal cihaz sahibi, sanal cihaz oluşturan ve yöneten güvenilir veya ayrıcalıklı bir uygulamadır. Sanal cihaz sahipleri, uygulamaları sanal bir cihazda çalıştırır ve ardından uygulamaları kişisel bilgisayar, sanal gerçeklik cihazı veya araç bilgi-eğlence sistemi gibi uzak bir cihazın ekranına yansıtır. Sanal cihaz sahibi, cep telefonu gibi yerel bir cihaz kullanıyordur.

Uygulamaya özgü geçersiz kılmalar
Android 16 (API düzeyi 36) çalıştıran cihazlarda sanal cihaz sahipleri, yönettikleri belirli sanal cihazlardaki uygulama ayarlarını geçersiz kılabilir. Örneğin, sanal cihaz sahibi, uygulama düzenini iyileştirmek için uygulamaları harici bir ekrana yansıtırken yön, en boy oranı ve yeniden boyutlandırılabilirlik kısıtlamalarını yoksayabilir.
Sık karşılaşılan zarar veren değişiklikler
Android 16 davranışı, özellikle de dikey yönde küçük ekranlar için tasarlanmış düzenler olmak üzere, araç ekranları veya Chromebook'lar gibi büyük ekran form faktörlerindeki uygulamanızın kullanıcı arayüzünü etkileyebilir. Uygulamanızı tüm cihaz form faktörlerine uyarlanabilir hale getirmeyi öğrenmek için Uyarlanabilir düzenler hakkında başlıklı makaleyi inceleyin.
Referanslar
Güvenlik
Android 16 (API düzeyi 36), uygulamaları ve kullanıcıları kötü amaçlı uygulamalara karşı korumaya yardımcı olmak için sistem güvenliğini destekleyen değişiklikler içerir.
Intent yönlendirme saldırılarına karşı gelişmiş güvenlik
Android 16, minimum uyumluluk ve geliştirici değişiklikleri gerektiren genel Intent
yönlendirme saldırılarına karşı varsayılan güvenlik sağlar.
Yönlendirme kötüye kullanımlarına karşı varsayılan olarak güvenlik sağlamlaştırma çözümleri sunuyoruz.Intent
Intent kullanan uygulamalar genellikle uyumluluk sorunları yaşamaz. Geliştirme sürecimiz boyunca, hangi uygulamaların kesinti yaşayabileceğini izlemek için metrikler topladık.
Android'de Intent yönlendirmesi, saldırgan bir uygulamanın, güvenlik açığı olan bir uygulama bağlamında yeni bir bileşeni başlatmak için kullanılan Intent'in içeriğini kısmen veya tamamen kontrol edebilmesi ve kurban uygulamanın bir ("üst düzey") Intent'in ekstralar alanında güvenilmeyen bir alt düzey Intent'i başlatması durumunda gerçekleşir. Bu durum, saldırgan uygulamasının kurban uygulaması bağlamında özel bileşenler başlatmasına, ayrıcalıklı işlemleri tetiklemesine veya hassas verilere URI erişimi elde etmesine neden olabilir. Bu da veri hırsızlığına ve keyfi kod yürütmeye yol açabilir.
Intent yönlendirme işlevini devre dışı bırakma
Android 16, uygulamaların başlatma güvenlik korumalarını devre dışı bırakmasına olanak tanıyan yeni bir API'yi kullanıma sunar. Bu, varsayılan güvenlik davranışının meşru uygulama kullanım alanlarını etkilediği belirli durumlarda gerekli olabilir.
Android 16 (API düzeyi 36) SDK'sı veya sonraki sürümler kullanılarak derlenen uygulamalar için
Intent nesnesinde doğrudan removeLaunchSecurityProtection()
yöntemini kullanabilirsiniz.
val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
Android 15 (API düzeyi 35) veya önceki sürümlere göre derlenen uygulamalar için
Önerilmez ancak removeLaunchSecurityProtection()
yöntemine erişmek için yansımayı kullanabilirsiniz.
val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
// Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }
Tamamlayıcı uygulamalar artık keşif zaman aşımlarından haberdar edilmeyecek
Android 16, kullanıcının konum gizliliğini kötü amaçlı uygulamalardan korumak için yardımcı cihaz eşleme akışında yeni bir davranış sunar. Android 16'da çalışan tüm tamamlayıcı uygulamalar artık RESULT_DISCOVERY_TIMEOUT
kullanılarak keşif zaman aşımı hakkında doğrudan bilgilendirilmez. Bunun yerine, kullanıcıya görsel bir iletişim kutusu gösterilerek zaman aşımı etkinlikleri bildirilir. Kullanıcı iletişim kutusunu kapattığında uygulama, RESULT_USER_REJECTED
ile ilişkilendirme hatası konusunda uyarılır.
Arama süresi de orijinal 20 saniyeden uzatıldı ve cihaz bulma işlemi, arama sırasında kullanıcı tarafından herhangi bir noktada durdurulabilir. Aramanın başlatılmasından sonraki ilk 20 saniye içinde en az bir cihaz bulunursa CDM başka cihaz aramayı durdurur.
Bağlantı
Android 16 (API düzeyi 36), çevre birimleri ile bağlantıyı iyileştirmek için Bluetooth yığınında aşağıdaki değişiklikleri içerir.
Borç kaybının ele alınması iyileştirildi
Starting in Android 16, the Bluetooth stack has been updated to improve security and user experience when a remote bond loss is detected. Previously, the system would automatically remove the bond and initiate a new pairing process, which could lead to unintentional re-pairing. We have seen in many instances apps not taking care of the bond loss event in a consistent way.
To unify the experience, Android 16 improved the bond loss handling to the system. If a previously bonded Bluetooth device could not be authenticated upon reconnection, the system will disconnect the link, retain local bond information, and display a system dialog informing users of the bond loss and directing them to re-pair.