Android 14, önceki sürümlerde olduğu gibi uygulamanızı etkileyebilecek davranış değişiklikleri içerir. Aşağıdaki davranış değişiklikleri yalnızca Android 14 (API düzeyi 34) veya sonraki sürümleri hedefleyen uygulamalar için geçerlidir. Uygulamanız Android 14 veya sonraki sürümleri hedefliyorsa geçerli durumlarda bu davranışları düzgün şekilde destekleyecek şekilde değiştirmeniz gerekir.
Uygulamanın targetSdkVersion'sinden bağımsız olarak Android 14'te çalışan tüm uygulamaları etkileyen davranış değişiklikleri
listesini de inceleyin.
Temel işlevler
Ön plan hizmeti türleri zorunludur
Uygulamanız Android 14 (API düzeyi 34) veya sonraki sürümleri hedefliyorsa uygulamanızdaki her ön plan hizmeti için en az bir ön plan hizmet türü belirtilmelidir. Uygulamanızın kullanım alanını temsil eden bir ön plan hizmet türü seçmeniz gerekir. Sistem, belirli bir türe sahip ön plan hizmetlerinin belirli bir kullanım alanını karşılamasını bekler.
Uygulamanızdaki bir kullanım alanı bu türlerden hiçbiriyle ilişkili değilse mantığınızı WorkManager veya kullanıcı tarafından başlatılan veri aktarım işleri kullanmaya taşımanız önemle tavsiye edilir.
BluetoothAdapter'da BLUETOOTH_CONNECT izninin zorunlu kılınması
Android 14, Android 14 (API düzeyi 34) veya sonraki sürümleri hedefleyen uygulamalar için BluetoothAdapter getProfileConnectionState() yöntemi çağrılırken BLUETOOTH_CONNECT iznini zorunlu kılar.
Bu yöntem için BLUETOOTH_CONNECT izni zaten gerekliydi ancak bu şart uygulanmadı. Uygulamanızın, aşağıdaki snippet'te gösterildiği gibi BLUETOOTH_CONNECT öğesini uygulamanızın AndroidManifest.xml dosyasında beyan ettiğinden emin olun ve getProfileConnectionState öğesini çağırmadan önce kullanıcının izin verip vermediğini kontrol edin.
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
OpenJDK 17 güncellemeleri
Android 14, Android'in temel kitaplıklarını en son OpenJDK LTS sürümlerindeki özelliklerle uyumlu hale getirmek için yenileme çalışmalarına devam ediyor. Bu çalışmalara hem kitaplık güncellemeleri hem de uygulama ve platform geliştiricileri için Java 17 dil desteği dahildir.
Bu değişikliklerden bazıları uygulama uyumluluğunu etkileyebilir:
- Normal ifadelerdeki değişiklikler: OpenJDK'nın anlamını daha yakından takip etmek için geçersiz grup referanslarına artık izin verilmiyor.
java.util.regex.Matchersınıfı tarafındanIllegalArgumentExceptionatanmasının olduğu yeni durumlar görebilirsiniz. Bu nedenle, uygulamanızı normal ifadelerin kullanıldığı alanlar açısından test ettiğinizden emin olun. Test sırasında bu değişikliği etkinleştirmek veya devre dışı bırakmak için uyumluluk çerçevesi araçlarını kullanarakDISALLOW_INVALID_GROUP_REFERENCEişaretini açın veya kapatın. - UUID işleme:
java.util.UUID.fromString()yöntemi artık giriş bağımsız değişkenini doğrularken daha katı kontroller yapıyor. Bu nedenle, seri dışılaştırma sırasında birIllegalArgumentExceptiongörebilirsiniz. Test sırasında bu değişikliği etkinleştirmek veya devre dışı bırakmak için uyumluluk çerçevesi araçlarını kullanarakENABLE_STRICT_VALIDATIONişaretini açın veya kapatın. - ProGuard sorunları: Bazı durumlarda, ProGuard'ı kullanarak uygulamanızı küçültmeye, kod karartmaya ve optimize etmeye çalıştığınızda
java.lang.ClassValuesınıfının eklenmesi soruna neden olur. Sorun,Class.forName("java.lang.ClassValue")'ün sınıf döndürüp döndürmediğine bağlı olarak çalışma zamanı davranışını değiştiren bir Kotlin kitaplığından kaynaklanıyor. Uygulamanız,java.lang.ClassValuesınıfının bulunmadığı çalışma ortamının eski bir sürümüne göre geliştirildiyse bu optimizasyonlar,java.lang.ClassValuesınıfından türetilen sınıflardancomputeValueyöntemini kaldırabilir.
JobScheduler, geri çağırma ve ağ davranışını güçlendirir
Since its introduction, JobScheduler expects your app to return from
onStartJob or onStopJob within a few seconds. Prior to Android 14,
if a job runs too long, the job is stopped and fails silently.
If your app targets Android 14 (API level 34) or higher and
exceeds the granted time on the main thread, the app triggers an ANR
with the error message "No response to onStartJob" or
"No response to onStopJob".
This ANR may be a result of 2 scenarios:
1. There is work blocking the main thread, preventing the callbacks onStartJob
or onStopJob from executing and completing within the expected time limit.
2. The developer is running blocking work within the JobScheduler
callback onStartJob or onStopJob, preventing the callback from
completing within the expected time limit.
To address #1, you will need to further debug what is blocking the main thread
when the ANR occurs, you can do this using
ApplicationExitInfo#getTraceInputStream() to get the tombstone
trace when the ANR occurs. If you're able to manually reproduce the ANR,
you can record a system trace and inspect the trace using either
Android Studio or Perfetto to better understand what is running on
the main thread when the ANR occurs.
Note that this can happen when using JobScheduler API directly
or using the androidx library WorkManager.
To address #2, consider migrating to WorkManager, which provides
support for wrapping any processing in onStartJob or onStopJob
in an asynchronous thread.
JobScheduler also introduces a requirement to declare the
ACCESS_NETWORK_STATE permission if using setRequiredNetworkType or
setRequiredNetwork constraint. If your app does not declare the
ACCESS_NETWORK_STATE permission when scheduling the job and is targeting
Android 14 or higher, it will result in a SecurityException.
Tiles launch API
For apps targeting 14 and higher,
TileService#startActivityAndCollapse(Intent) is deprecated and now throws
an exception when called. If your app launches activities from tiles, use
TileService#startActivityAndCollapse(PendingIntent) instead.
Gizlilik
Fotoğraf ve videolara kısmi erişim
Android 14, kullanıcıların belirli bir türdeki tüm medyalara erişim vermek yerine uygulamalara kitaplarındaki belirli resimlere ve videolara erişim izni vermesine olanak tanıyan Seçili Fotoğraflar Erişimi özelliğini kullanıma sunar.
Bu değişiklik yalnızca uygulamanız Android 14'ü (API düzeyi 34) veya sonraki sürümleri hedefliyorsa etkinleştirilir. Fotoğraf seçiciyi henüz kullanmıyorsanız depolama alanı izni istemek zorunda kalmadan resim ve video seçmek için tutarlı bir deneyim sunmak ve kullanıcı gizliliğini artırmak amacıyla uygulamanıza uygulamanızı öneririz.
Depolama alanı izinlerini kullanarak kendi galeri seçicinizi kullanıyorsanız ve uygulamanız üzerinde tam kontrol sahibi olmanız gerekiyorsa yeni READ_MEDIA_VISUAL_USER_SELECTED iznini kullanmak için uygulamanızı uyarlayın. Uygulamanız yeni izni kullanmıyorsa sistem, uygulamanızı uyumluluk modunda çalıştırır.
Kullanıcı deneyimi
Güvenli tam ekran intent bildirimleri
With Android 11 (API level 30), it was possible for any app to use
Notification.Builder.setFullScreenIntent to send full-screen
intents while the phone is locked. You could auto-grant this on app install by
declaring USE_FULL_SCREEN_INTENT permission in the
AndroidManifest.
Full-screen intent notifications are designed for extremely high-priority
notifications demanding the user's immediate attention, such as an incoming
phone call or alarm clock settings configured by the user. For apps targeting
Android 14 (API level 34) or higher, apps that are allowed to use this
permission are limited to those that provide calling and alarms only. The Google
Play Store revokes default USE_FULL_SCREEN_INTENT permissions for any apps
that don't fit this profile. The deadline for these policy changes is May 31,
2024.
This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.
You can use the new API
NotificationManager.canUseFullScreenIntent to check if your app
has the permission; if not, your app can use the new intent
ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT to launch the settings
page where users can grant the permission.
Güvenlik
Örtülü ve bekleyen amaçlarla ilgili kısıtlamalar
For apps targeting Android 14 (API level 34) or higher, Android restricts apps from sending implicit intents to internal app components in the following ways:
- Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
- If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.
These changes prevent malicious apps from intercepting implicit intents that are intended for use by an app's internal components.
For example, here is an intent filter that could be declared in your app's manifest file:
<activity
android:name=".AppActivity"
android:exported="false">
<intent-filter>
<action android:name="com.example.action.APP_ACTION" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
If your app tried to launch this activity using an implicit intent, an
ActivityNotFoundException exception would be thrown:
Kotlin
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(Intent("com.example.action.APP_ACTION"))
Java
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(new Intent("com.example.action.APP_ACTION"));
To launch the non-exported activity, your app should use an explicit intent instead:
Kotlin
// This makes the intent explicit. val explicitIntent = Intent("com.example.action.APP_ACTION") explicitIntent.apply { package = context.packageName } context.startActivity(explicitIntent)
Java
// This makes the intent explicit. Intent explicitIntent = new Intent("com.example.action.APP_ACTION") explicitIntent.setPackage(context.getPackageName()); context.startActivity(explicitIntent);
Çalışma zamanında kaydedilen yayın alıcılar, dışa aktarma davranışını belirtmelidir
Android 14 (API düzeyi 34) veya sonraki sürümleri hedefleyen ve bağlama kayıtlı alıcıları kullanan uygulamaların ve hizmetlerin, alıcının cihazdaki diğer tüm uygulamalara aktarılıp aktarılmayacağını belirtmek için bir işaret belirtmesi gerekir: sırasıyla RECEIVER_EXPORTED veya RECEIVER_NOT_EXPORTED.
Bu şart, Android 13'te kullanıma sunulan bu alıcılara yönelik özelliklerden yararlanarak uygulamaları güvenlik açıklarına karşı korumaya yardımcı olur.
Yalnızca sistem yayınları alan alıcılar için istisna
Uygulamanız, Context#registerReceiver() gibi Context#registerReceiveryöntemleri kullanarak yalnızca sistem yayınları için alıcı kaydediyorsa alıcıyı kaydederken bir işaret belirtmemelidir.
Daha güvenli dinamik kod yükleme
Uygulamanız Android 14 (API düzeyi 34) veya sonraki sürümleri hedefliyorsa ve Dinamik Kod kullanıyorsa Yükleniyor (DCL) durumunda, dinamik olarak yüklenen tüm dosyalar salt okunur olarak işaretlenmelidir. Aksi takdirde, sistem bir istisna uygular. Uygulamalardan Kodu dinamik olarak yükleme Çünkü böyle yapmak, uygulamanızın tekrar gözden geçirilmesi riskini veya başkasının eline geçer.
Kodu dinamik olarak yüklemeniz gerekiyorsa dinamik olarak yüklenen dosyayı (ör. DEX, JAR veya APK dosyası) açıldıktan hemen sonra ve herhangi bir içerik yazılmadan önce salt okunur olarak ayarlamak için aşağıdaki yaklaşımı kullanın:
Kotlin
val jar = File("DYNAMICALLY_LOADED_FILE.jar") val os = FileOutputStream(jar) os.use { // Set the file to read-only first to prevent race conditions jar.setReadOnly() // Then write the actual file content } val cl = PathClassLoader(jar, parentClassLoader)
Java
File jar = new File("DYNAMICALLY_LOADED_FILE.jar"); try (FileOutputStream os = new FileOutputStream(jar)) { // Set the file to read-only first to prevent race conditions jar.setReadOnly(); // Then write the actual file content } catch (IOException e) { ... } PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);
Mevcut olan ve dinamik olarak yüklenmiş dosyaları işleyin
Dinamik olarak yüklenen mevcut dosyalara yönelik istisnaların atılmasını önlemek için dinamik olarak denemeden önce dosyaları silip yeniden oluşturmanızı öneririz. bunları uygulamanıza tekrar yükleyebilirsiniz. Dosyaları yeniden oluştururken önceki yazma zamanında dosyaları salt okunur olarak işaretleme ile ilgili yol gösterici bilgiler içerir. Alternatif olarak mevcut dosyaları salt okunur olarak yeniden etiketleyin. Ancak bu örnekte, önce dosyaların bütünlüğünü doğrulamanızı öneririz (örneğin, uygulamanızın korunmasına yardımcı olmak için dosyanın imzasını güvenilir bir değerle karşılaştırarak kötü amaçlı işlemlerden korur.
Arka planda etkinlik başlatmayla ilgili ek kısıtlamalar
For apps targeting Android 14 (API level 34) or higher, the system further restricts when apps are allowed to start activities from the background:
- When an app sends a
PendingIntentusingPendingIntent#send()or similar methods, the app must opt in if it wants to grant its own background activity launch privileges to start the pending intent. To opt in, the app should pass anActivityOptionsbundle withsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED). - When a visible app binds a service of another app that's in the background
using the
bindService()method, the visible app must now opt in if it wants to grant its own background activity launch privileges to the bound service. To opt in, the app should include theBIND_ALLOW_ACTIVITY_STARTSflag when calling thebindService()method.
These changes expand the existing set of restrictions to protect users by preventing malicious apps from abusing APIs to start disruptive activities from the background.
Zip path traversal
Android 14 (API düzeyi 34) veya sonraki sürümleri hedefleyen uygulamalarda Android, ZIP Yol Geçiş Güvenlik Açığını aşağıdaki şekilde önler: ZipFile(String) ve ZipInputStream.getNextEntry(), ZIP dosyası giriş adları ".." içeriyorsa veya "/" ile başlıyorsa ZipException hatası oluşturur.
Uygulamalar, dalvik.system.ZipPathValidator.clearCallback() çağrısı yaparak bu doğrulamayı devre dışı bırakabilir.
Her MediaProjection yakalama oturumu için kullanıcı izni gerekir
Android 14 (API düzeyi 34) veya sonraki sürümleri hedefleyen uygulamalarda, aşağıdaki senaryolardan birinde MediaProjection#createVirtualDisplay tarafından bir SecurityException atılır:
- Uygulamanız,
MediaProjectionManager#createScreenCaptureIntentkaynağından döndürülenIntentöğesini önbelleğe alır veMediaProjectionManager#getMediaProjectionkaynağına birden çok kez iletir. - Uygulamanız aynı
MediaProjectionörneğindeMediaProjection#createVirtualDisplayişlevini birden fazla kez çağırıyor.
Uygulamanız, her yakalama oturumundan önce kullanıcıdan izin almalıdır. Tek bir yakalama oturumu, MediaProjection#createVirtualDisplay üzerinde tek bir çağrıdır ve her MediaProjection örneği yalnızca bir kez kullanılmalıdır.
Yapılandırma değişikliklerini işleme
Uygulamanızın yapılandırma değişikliklerini (ör. ekran yönü veya ekran boyutu değişikliği) işlemek için MediaProjection#createVirtualDisplay'ü çağırması gerekiyorsa mevcut MediaProjection örneği için VirtualDisplay'ı güncellemek üzere aşağıdaki adımları uygulayabilirsiniz:
- Yeni genişlik ve yükseklikle
VirtualDisplay#resizeişlevini çağırın. VirtualDisplay#setSurfaceiçin yeni genişlik ve yükseklik içeren yeni birSurfacesağlayın.
Geri arama kaydı
Uygulamanız, kullanıcının yakalama oturumuna devam etmek için izin vermediği durumları işlemek üzere bir geri çağırma işlevi kaydetmelidir. Bunu yapmak için Callback#onStop'u uygulayın ve uygulamanızın ilgili tüm kaynakları (ör. VirtualDisplay ve Surface) yayınlamasını sağlayın.
Uygulamanız bu geri çağırma işlevini kaydetmezse MediaProjection#createVirtualDisplay, uygulamanız işlevi çağırdığında IllegalStateException hatası verir.
SDK olmayan arayüzlerle ilgili güncellenen kısıtlamalar
Android 14, Android geliştiricilerle işbirliği ve en son dahili 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ılabilir olmasını sağlarız.
Uygulamanız Android 14'ü hedeflemiyorsa bu değişikliklerin bazıları sizi hemen etkilemeyebilir. Ancak şu anda bazı SDK dışı arayüzleri (uygulamanızın hedef API düzeyine bağlı olarak) kullanabilseniz de herhangi bir SDK dışı yöntemi veya alanı kullanmak uygulamanızın bozulma riskini her zaman yüksek tutar.
Uygulamanızın SDK dışı arayüzler kullanıp kullanmadığından emin değilseniz öğrenmek için uygulamanızı test edebilirsiniz. Uygulamanız SDK dışı arayüzleri kullanıyorsa SDK alternatiflerine geçişi planlamaya başlamanız gerekir. Bununla birlikte, bazı uygulamaların SDK dışı arayüzleri kullanmak için geçerli kullanım alanları olduğunu anlıyoruz. Uygulamanızdaki bir özellik için SDK dışı arayüz kullanmaya alternatif bulamıyorsanız yeni bir herkese açık API isteğinde bulunmalısınız.
Android'in bu sürümündeki değişiklikler hakkında daha fazla bilgi edinmek için Android 14'te 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.