Come le release precedenti, Android 14 include modifiche del comportamento che potrebbero influire la tua app. Le seguenti modifiche del comportamento si applicano esclusivamente alle app che: che hanno come target Android 14 (livello API 34) o versioni successive. Se la tua app ha come target Android 14 o versioni successive, devi modificare l'app per supportare correttamente questi comportamenti. ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche al comportamento che interessano tutte le app in esecuzione su Android 14, indipendentemente dal targetSdkVersion
dell'app.
Funzionalità di base
I tipi di servizio in primo piano sono obbligatori
If your app targets Android 14 (API level 34) or higher, it must specify at least one foreground service type for each foreground service within your app. You should choose a foreground service type that represents your app's use case. The system expects foreground services that have a particular type to satisfy a particular use case.
If a use case in your app isn't associated with any of these types, it's strongly recommended that you migrate your logic to use WorkManager or user-initiated data transfer jobs.
Applicazione dell'autorizzazione BLUETOOTH_CONNECT in BluetoothAdapter
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,Android 14 会在调用 BluetoothAdapter
getProfileConnectionState()
方法时强制执行 BLUETOOTH_CONNECT
权限。
此方法已要求 BLUETOOTH_CONNECT
权限,但未强制执行。确保您的应用在应用的 AndroidManifest.xml
文件中声明 BLUETOOTH_CONNECT
,如以下代码段所示,并在调用 getProfileConnectionState
之前检查用户是否已授予相应权限。
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
Aggiornamenti di OpenJDK 17
Android 14 continua l'opera di aggiornamento delle librerie di base di Android per allinearsi alle funzionalità delle ultime release OpenJDK LTS, inclusi gli aggiornamenti delle librerie e il supporto del linguaggio Java 17 per gli sviluppatori di app e piattaforme.
Alcune di queste modifiche possono influire sulla compatibilità delle app:
- Modifiche alle espressioni regolari: i riferimenti ai gruppi non validi ora non sono consentiti per seguire più da vicino la semantica di OpenJDK. Potresti vedere
nuovi casi in cui viene generato un
IllegalArgumentException
dalla classejava.util.regex.Matcher
, quindi assicurati di testare la tua app per verificare la presenza di aree che utilizzano espressioni regolari. Per attivare o disattivare questa modifica durante il test, attiva/disattiva il flagDISALLOW_INVALID_GROUP_REFERENCE
utilizzando gli strumenti del framework di compatibilità. - Gestione degli UUID: il metodo
java.util.UUID.fromString()
ora esegue controlli più rigorosi durante la convalida dell'argomento di input, pertanto potresti visualizzare unIllegalArgumentException
durante la deserializzazione. Per attivare o disattivare questa variazione durante il test, attiva/disattiva il flagENABLE_STRICT_VALIDATION
utilizzando gli strumenti del framework di compatibilità. - Problemi di ProGuard: in alcuni casi, l'aggiunta della classe
java.lang.ClassValue
causa un problema se provi a ridurre, offuscare e ottimizzare l'app utilizzando ProGuard. Il problema ha origine da una libreria Kotlin che modifica il comportamento di runtime in base al fatto cheClass.forName("java.lang.ClassValue")
restituisca o meno una classe. Se la tua app è stata sviluppata in base a una versione precedente del runtime senza la classejava.lang.ClassValue
disponibile, queste ottimizzazioni potrebbero rimuovere il metodocomputeValue
dalle classi derivate dajava.lang.ClassValue
.
JobScheduler rafforza il callback e il comportamento di rete
Dalla sua introduzione, JobScheduler si aspetta che la tua app torni da
onStartJob
o onStopJob
entro pochi secondi. Prima di Android 14, se un job è in esecuzione per troppo tempo, viene interrotto e non viene visualizzato alcun messaggio di errore.
Se la tua app ha come target Android 14 (livello API 34) o versioni successive e supera il tempo concesso nel thread principale, attiva un ANR con il messaggio di errore "Nessuna risposta a onStartJob
" o "Nessuna risposta a onStopJob
".
Questo errore ANR potrebbe essere il risultato di due scenari:
1. Un'attività sta bloccando il thread principale, impedendo i callback onStartJob
o onStopJob
dall'esecuzione e dal completamento entro il limite di tempo previsto.
2. Lo sviluppatore sta eseguendo il blocco del lavoro in JobScheduler
callback onStartJob
o onStopJob
, impedendo la richiamata
il completamento entro il limite di tempo previsto.
Per risolvere il problema 1, dovrai eseguire ulteriormente il debug di ciò che blocca il thread principale quando si verifica l'errore ANR. Puoi farlo utilizzando ApplicationExitInfo#getTraceInputStream()
per ottenere la traccia della pietra tombale quando si verifica l'errore ANR. Se riesci a riprodurre manualmente l'errore ANR,
puoi registrare una traccia del sistema ed esaminarla utilizzando
Android Studio o Perfetto per comprendere meglio cosa viene eseguito
nel thread principale quando si verifica l'errore ANR.
Tieni presente che questo può accadere quando utilizzi direttamente l'API JobScheduler o la libreria androidx WorkManager.
Per il passaggio 2, valuta la possibilità di eseguire la migrazione a WorkManager, che fornisce
supporto per il wrapping di qualsiasi elaborazione in onStartJob
o onStopJob
in un thread asincrono.
JobScheduler
introduce anche il requisito di dichiarare l'autorizzazione
ACCESS_NETWORK_STATE
se utilizzi il vincolo setRequiredNetworkType
o
setRequiredNetwork
. Se la tua app non dichiara
Autorizzazione ACCESS_NETWORK_STATE
durante la pianificazione del job e il targeting
Android 14 o versioni successive si tradurrà in SecurityException
.
API Tiles lancio
Per le app con targeting per 14 e versioni successive,
TileService#startActivityAndCollapse(Intent)
è deprecato e ora genera
un'eccezione quando vengono chiamati. Se la tua app avvia attività dalle schede, utilizza
TileService#startActivityAndCollapse(PendingIntent)
.
Privacy
Accesso parziale a foto e video
Android 14 introduce l'accesso alle foto selezionate, che consente agli utenti di concedere alle app l'accesso a immagini e video specifici nella raccolta, anziché a tutti i contenuti multimediali di un determinato tipo.
Questa modifica è attivata solo se la tua app ha come target Android 14 (livello API 34) o versioni successive. Se non utilizzi ancora il selettore di foto, ti consigliamo di implementarlo nella tua app per offrire un'esperienza coerente per la selezione di immagini e video, migliorando al contempo la privacy degli utenti senza dover richiedere autorizzazioni di archiviazione.
Se gestisci il tuo selettore di gallerie utilizzando le autorizzazioni di archiviazione e devi mantenere il pieno controllo sull'implementazione, adatta l'implementazione per utilizzare la nuova autorizzazione READ_MEDIA_VISUAL_USER_SELECTED
. Se la tua app
non utilizza la nuova autorizzazione, il sistema la esegue in una modalità di compatibilità.
Esperienza utente
Notifiche sicure di intent a schermo intero
在 Android 11(API 级别 30)中,任何应用都可以在手机处于锁定状态时使用 Notification.Builder.setFullScreenIntent
发送全屏 intent。您可以通过在 AndroidManifest 中声明 USE_FULL_SCREEN_INTENT
权限,在应用安装时自动授予此权限。
全屏 intent 通知适用于需要用户立即注意的极高优先级通知,例如用户来电或用户配置的闹钟设置。对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,获准使用此权限的应用仅限于提供通话和闹钟的应用。对于不适合此情况的任何应用,Google Play 商店会撤消其默认的 USE_FULL_SCREEN_INTENT
权限。这些政策变更的截止日期为 2024 年 5 月 31 日。
在用户更新到 Android 14 之前,在手机上安装的应用仍拥有此权限。用户可以开启和关闭此权限。
您可以使用新 API NotificationManager.canUseFullScreenIntent
检查应用是否具有该权限;如果没有,应用可以使用新 intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT
启动设置页面,在该页面中,用户可以授予权限。
Sicurezza
Limitazioni agli intent impliciti e in attesa
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);
I broadcast receiver registrati in fase di runtime devono specificare il comportamento di esportazione
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.
Caricamento di codice dinamico più sicuro
Se la tua app ha come target Android 14 (livello API 34) o versioni successive e utilizza il caricamento di codice dinamico (DCL), tutti i file caricati dinamicamente devono essere contrassegnati come di sola lettura. In caso contrario, il sistema genera un'eccezione. Consigliamo alle app di evitare di caricare codice dinamicamente se possibile, in quanto ciò aumenta notevolmente il rischio che un'app possa essere compromessa da iniezione di codice o manomissione del codice.
Se devi caricare dinamicamente il codice, utilizza il seguente approccio per impostare il file caricato dinamicamente (ad esempio un file DEX, JAR o APK) come di sola lettura non appena viene aperto e prima che vengano scritti contenuti:
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);
Gestire i file caricati dinamicamente esistenti
Per evitare che vengano lanciate eccezioni per i file caricati dinamicamente esistenti, consigliamo di eliminarli e ricrearli prima di provare a caricarli di nuovo dinamicamente nella tua app. Durante la ricreazione dei file, segui le indicazioni precedenti per contrassegnarli come di sola lettura al momento della scrittura. In alternativa, puoi etichettare nuovamente i file esistenti come di sola lettura, ma in questo caso ti consigliamo vivamente di verificare prima l'integrità dei file (ad esempio controllando la firma del file rispetto a un valore attendibile) per proteggere la tua app da azioni dannose.
Ulteriori limitazioni relative all'avvio di attività in background
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,系统会进一步限制允许应用在后台启动 activity 的时间:
- 现在,当应用使用
PendingIntent#send()
或类似方法发送PendingIntent
时,如果它想要授予自己的后台 activity 启动待处理 intent 的启动特权,则必须选择启用。如需选择启用,应用应通过setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
传递ActivityOptions
软件包。 - 当可见应用使用
bindService()
方法绑定其他在后台应用的服务时,如果可见应用想要授予自己的后台 activity 对绑定服务的启动特权,则必须选择启用。如需选择启用,应用应在调用bindService()
方法时包含BIND_ALLOW_ACTIVITY_STARTS
标志。
这些更改扩大了一组现有限制条件的范围,目的是防止恶意应用滥用 API 以在后台启动干扰性活动,从而保护用户。
Zip Path Traversal
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,Android 会通过以下方式防止 Zip 路径遍历漏洞:如果 Zip 文件条目名称包含“..”或以“/”开头,ZipFile(String)
和 ZipInputStream.getNextEntry()
会抛出 ZipException
。
应用可以通过调用 dalvik.system.ZipPathValidator.clearCallback()
选择停用此验证。
Consenso dell'utente obbligatorio per ogni sessione di acquisizione MediaProjection
Per le app che hanno come target Android 14 (livello API 34) o versioni successive, un SecurityException
viene generato da MediaProjection#createVirtualDisplay
in uno dei seguenti scenari:
- L'app memorizza nella cache
Intent
restituito daMediaProjectionManager#createScreenCaptureIntent
e lo passa più volte aMediaProjectionManager#getMediaProjection
. - La tua app richiama
MediaProjection#createVirtualDisplay
più volte sulla stessa istanzaMediaProjection
.
L'app deve chiedere all'utente di dare il consenso prima di ogni sessione di acquisizione. Una singola sessione di acquisizione è una singola chiamata su MediaProjection#createVirtualDisplay
e ogni istanza di MediaProjection
deve essere utilizzata una sola volta.
Gestire le modifiche alla configurazione
Se la tua app deve richiamare MediaProjection#createVirtualDisplay
per gestire le modifiche alla configurazione (ad esempio l'orientamento o le dimensioni dello schermo), puoi seguire questi passaggi per aggiornare VirtualDisplay
per l'istanza MediaProjection
esistente:
- Richiama
VirtualDisplay#resize
con la nuova larghezza e altezza. - Fornisci un nuovo
Surface
con le nuove larghezza e altezza aVirtualDisplay#setSurface
.
Registra un callback
L'app deve registrare un callback per gestire i casi in cui l'utente non concede il consenso per continuare una sessione di acquisizione. Per farlo, implementa
Callback#onStop
e fai in modo che la tua app rilasci le risorse correlate (come
VirtualDisplay
e Surface
).
Se la tua app non registra questo callback,MediaProjection#createVirtualDisplay
genera un IllegalStateException
quando la tua app lo invoca.
Limitazioni non SDK aggiornate
Android 14 include elenchi aggiornati di elementi non SDK soggetti a restrizioni basate sulla collaborazione con gli sviluppatori Android e le applicazioni per i test interni. Ove possibile, ci assicuriamo che siano disponibili alternative pubbliche prima di applicare limitazioni alle interfacce non SDK.
Se la tua app non ha come target Android 14, alcune di queste modifiche potrebbero non interessarti immediatamente. Tuttavia, sebbene al momento tu possa utilizzare interfacce non SDK (in base all'API target dell'app ), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di danneggiare dell'app.
Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare app per scoprirlo. Se la tua app si basa su interfacce non SDK, dovresti iniziare a pianificare una migrazione alle alternative dell'SDK. Tuttavia, siamo consapevoli che alcune app hanno casi d'uso validi per l'utilizzo di interfacce non SDK. Se non riesci a trovare un'alternativa all'utilizzo di un'interfaccia non SDK per una funzionalità nella tua app, devi richiedere una nuova API pubblica.
To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 14. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.