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 uygulamanızı, geçerli olduğu durumlarda bu davranışları düzgün şekilde destekleyecek şekilde değiştirmeniz gerekir.
Uygulamanın targetSdkVersion değerinden bağımsız olarak, Android 14'te çalışan tüm uygulamaları etkileyen davranış değişikliklerinin 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 enforces the BLUETOOTH_CONNECT permission when calling the
BluetoothAdapter getProfileConnectionState() method for apps targeting
Android 14 (API level 34) or higher.
This method already required the BLUETOOTH_CONNECT permission, but it was not
enforced. Make sure your app declares BLUETOOTH_CONNECT in your app's
AndroidManifest.xml file as shown in the following snippet and check that
a user has granted the permission before calling
getProfileConnectionState.
<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
Job Scheduler, kullanıma sunulduğu andan itibaren uygulamanızın
Birkaç saniye içinde onStartJob veya onStopJob. Android 14'ten önce
bir iş çok uzun süre çalışırsa iş durdurulur ve sessizce başarısız olur.
Uygulamanız Android 14 (API düzeyi 34) veya sonraki sürümleri hedefliyorsa ve ana iş parçacığında izin verilen süreyi aşıyorsa "onStartJob için yanıt yok" veya "onStopJob için yanıt yok" hata mesajıyla bir ANR tetikler.
Bu ANR, 2 senaryoya bağlı olabilir:
1. Ana iş parçacığını engelleyen ve geri çağırmaları engelleyen bir iş var (onStartJob)
veya onStopJob beklenen süre sınırı içinde yürütülmesini ve tamamlanmasını engeller.
2. Geliştirici, JobScheduler içinde engelleme çalışmasını çalıştırıyor
onStartJob veya onStopJob geri çağırması, geri çağırmanın önüne geçer.
beklenen süre aşılmadan
tamamlanmasıdır.
1. sorunu gidermek için ANR oluştuğunda ana iş parçacığının ne tarafından engellendiğini daha ayrıntılı bir şekilde hata ayıklamanız gerekir. ANR oluştuğunda tombstone izlemeyi almak için ApplicationExitInfo#getTraceInputStream()'i kullanarak bunu yapabilirsiniz. ANR'yi manuel olarak yeniden oluşturabiliyorsanız
sistem izleme kaydedebilir ve
Android Studio veya Perfetto ile hangi uygulamaların yüklü olduğunu daha iyi anlayın
ANR gerçekleştiğinde ana iş parçacığı.
Bunun doğrudan JobScheduler API'yi kullanırken olabileceğini unutmayın
veya androidx kitaplığını kullanabilirsiniz.
2. sorunu gidermek için onStartJob veya onStopJob'deki tüm işlemleri asenkron bir iş parçacığında sarmalama desteği sunan WorkManager'a geçiş yapabilirsiniz.
JobScheduler, setRequiredNetworkType veya setRequiredNetwork kısıtlaması kullanılıyorsa ACCESS_NETWORK_STATE iznini beyan etme şartını da getirir. Uygulamanız
İşi planlarken ACCESS_NETWORK_STATE izni
Android 14 veya sonraki sürümlerde SecurityException oluşur.
Tiles launch API
14 ve sonraki sürümleri hedefleyen uygulamalar için
TileService#startActivityAndCollapse(Intent) desteği sonlandırıldı ve artık çalışıyor
çağrıldığında bir istisna oluşturur. Uygulamanız kartlardan etkinlik başlatıyorsa bunun yerine TileService#startActivityAndCollapse(PendingIntent) değerini kullanın.
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
Apps and services that target Android 14 (API level 34) or higher and use
context-registered receivers are required to specify a flag
to indicate whether or not the receiver should be exported to all other apps on
the device: either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED, respectively.
This requirement helps protect apps from security vulnerabilities by leveraging
the features for these receivers introduced in Android 13.
Exception for receivers that receive only system broadcasts
If your app is registering a receiver only for
system broadcasts through Context#registerReceiver
methods, such as Context#registerReceiver(), then it
shouldn't specify a flag when registering the receiver.
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
Android 14 (API düzeyi 34) veya sonraki sürümleri hedefleyen uygulamalar için sistem, uygulamaların arka planda etkinlik başlatmasına izin verildiği durumları daha da kısıtlar:
- Bir uygulama,
PendingIntent#send()veya benzer yöntemler kullanarakPendingIntentgönderdiğinde, bekleyen intent'i başlatmak için kendi arka plan etkinliği başlatma ayrıcalıklarını vermek istiyorsa bu özelliği etkinleştirmelidir. Etkinleştirmek için uygulamanınsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)ile birActivityOptionspaketi iletmesi gerekir. - Görünen bir uygulama,
bindService()yöntemini kullanarak arka planda olan başka bir uygulamanın hizmetini bağladığında, bağlı hizmete kendi arka plan etkinliği başlatma ayrıcalıklarını vermek istiyorsa artık bu seçeneği etkinleştirmesi gerekir. Etkinleştirmek için uygulama,bindService()yöntemini çağırırkenBIND_ALLOW_ACTIVITY_STARTSişaretini içermelidir.
Bu değişiklikler, kötü amaçlı uygulamaların arka planda rahatsız edici etkinlikler başlatmak için API'leri kötüye kullanmasını engelleyerek kullanıcıları korumak amacıyla mevcut kısıtlama grubunu genişletir.
Zip path traversal
For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip
Path Traversal Vulnerability in the following way:
ZipFile(String) and
ZipInputStream.getNextEntry() throws a
ZipException if zip file entry names contain ".." or start
with "/".
Apps can opt-out from this validation by calling
dalvik.system.ZipPathValidator.clearCallback().
Her MediaProjection yakalama oturumu için kullanıcı izni gerekir
For apps targeting Android 14 (API level 34) or higher, a SecurityException is
thrown by MediaProjection#createVirtualDisplay in either of the following
scenarios:
- Your app caches the
Intentthat is returned fromMediaProjectionManager#createScreenCaptureIntent, and passes it multiple times toMediaProjectionManager#getMediaProjection. - Your app invokes
MediaProjection#createVirtualDisplaymultiple times on the sameMediaProjectioninstance.
Your app must ask the user to give consent before each capture session. A single
capture session is a single invocation on
MediaProjection#createVirtualDisplay, and each MediaProjection instance must
be used only once.
Handle configuration changes
If your app needs to invoke MediaProjection#createVirtualDisplay to handle
configuration changes (such as the screen orientation or screen size changing),
you can follow these steps to update the VirtualDisplay for the existing
MediaProjection instance:
- Invoke
VirtualDisplay#resizewith the new width and height. - Provide a new
Surfacewith the new width and height toVirtualDisplay#setSurface.
Register a callback
Your app should register a callback to handle cases where the user doesn't grant
consent to continue a capture session. To do this, implement
Callback#onStop and have your app release any related resources (such as
the VirtualDisplay and Surface).
If your app doesn't register this callback,
MediaProjection#createVirtualDisplay throws an IllegalStateException
when your app invokes it.
SDK olmayan arayüzlerle ilgili kısıtlamalar güncellendi
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 oranda artırır.
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.