Cambiamenti del comportamento: app destinate ad Android 14 o versioni successive

Come le versioni precedenti, Android 14 include modifiche al comportamento che potrebbero influire sulla tua app. Le seguenti modifiche al comportamento si applicano esclusivamente alle app 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 modificarla 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 dall'targetSdkVersion dell'app.

Funzionalità di base

I tipi di servizi in primo piano sono obbligatori

Se la tua app ha come target Android 14 (livello API 34) o versioni successive, deve specificare almeno un tipo di servizio in primo piano per ogni servizio in primo piano al suo interno. Devi scegliere un tipo di servizio in primo piano che rappresenti il caso d'uso della tua app. Il sistema si aspetta che i servizi in primo piano di un determinato tipo satisfaggino un determinato caso d'uso.

Se un caso d'uso nella tua app non è associato a nessuno di questi tipi, ti consigliamo vivamente di eseguire la migrazione della logica per utilizzare WorkManager o processi di trasferimento di dati avviati dall'utente.

Applicazione dell'autorizzazione BLUETOOTH_CONNECT in BluetoothAdapter

Android 14 applica l'autorizzazione BLUETOOTH_CONNECT quando viene chiamato il metodoBluetoothAdapter getProfileConnectionState() per le app che hanno come target Android 14 (livello API 34) o versioni successive.

Questo metodo richiedeva già l'autorizzazione BLUETOOTH_CONNECT, ma non è stato applicato. Assicurati che la tua app dichiari BLUETOOTH_CONNECT nel file AndroidManifest.xml come mostrato nello snippet seguente e verifica che un utente abbia concesso l'autorizzazione prima di chiamare getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

Aggiornamenti di OpenJDK 17

Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.

A few of these changes can affect app compatibility:

  • Changes to regular expressions: Invalid group references are now disallowed to more closely follow the semantics of OpenJDK. You might see new cases where an IllegalArgumentException is thrown by the java.util.regex.Matcher class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle the DISALLOW_INVALID_GROUP_REFERENCE flag using the compatibility framework tools.
  • UUID handling: The java.util.UUID.fromString() method now does more strict checks when validating the input argument, so you might see an IllegalArgumentException during deserialization. To enable or disable this change while testing, toggle the ENABLE_STRICT_VALIDATION flag using the compatibility framework tools.
  • ProGuard issues: In some cases, the addition of the java.lang.ClassValue class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whether Class.forName("java.lang.ClassValue") returns a class or not. If your app was developed against an older version of the runtime without the java.lang.ClassValue class available, then these optimizations might remove the computeValue method from classes derived from java.lang.ClassValue.

JobScheduler rafforza il comportamento di callback e 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 di lancio delle tessere

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.

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 dell'intent a schermo intero sicure

Con Android 11 (livello API 30), era possibile per qualsiasi app utilizzare Notification.Builder.setFullScreenIntent per inviare intent a schermo intero mentre lo smartphone è bloccato. Puoi concederla automaticamente al momento dell'installazione dell'app dichiarando l'autorizzazione USE_FULL_SCREEN_INTENT in AndroidManifest.

Le notifiche di intent a schermo intero sono progettate per notifiche di priorità estremamente elevata che richiedono l'attenzione immediata dell'utente, ad esempio una chiamata in arrivo o le impostazioni della sveglia configurate dall'utente. Per le app che hanno come target Android 14 (livello API 34) o versioni successive, le app che possono utilizzare questa autorizzazione sono limitate a quelle che forniscono solo chiamate e sveglie. Google Play Store revoca le autorizzazioni USE_FULL_SCREEN_INTENT predefinite per tutte le app che non rientrano in questo profilo. Il termine ultimo per queste modifiche alle norme è il 31 maggio 2024.

Questa autorizzazione rimane attiva per le app installate sullo smartphone prima dell'aggiornamento ad Android 14. Gli utenti possono attivare e disattivare questa autorizzazione.

Puoi utilizzare la nuova API NotificationManager.canUseFullScreenIntent per verificare se la tua app ha l'autorizzazione. In caso contrario, la tua app può utilizzare il nuovo intento ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT per aprire la pagina delle impostazioni dove gli utenti possono concedere l'autorizzazione.

Sicurezza

Limitazioni relative agli intent impliciti e in attesa

Per le app che hanno come target Android 14 (livello API 34) o versioni successive, Android impedisce alle app di inviare intent impliciti ai componenti interni dell'app nei seguenti modi:

  • Gli intent impliciti vengono recapitati solo ai componenti esportati. Le app devono utilizzare un intent esplicito per l'invio a componenti non esportati oppure contrassegnare il componente come esportato.
  • Se un'app crea un intent in attesa mutabile con un intent che non specifica un componente o un pacchetto, il sistema genera un'eccezione.

Queste modifiche impediscono alle app dannose di intercettare gli intent impliciti che sono destinati ai componenti interni di un'app.

Ad esempio, ecco un filtro di intent che potrebbe essere dichiarato nel file manifest della tua app:

<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>

Se la tua app ha provato ad avviare questa attività utilizzando un'intent implicita, verrà lanciata un'eccezione ActivityNotFoundException:

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"));

Per avviare l'attività non esportata, l'app deve invece usare un intent esplicito:

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 del codice dinamico più sicuro

If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:

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);

Handle dynamically-loaded files that already exist

To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.

Ulteriori limitazioni relative all'avvio di attività in background

Per le app che hanno come target Android 14 (livello API 34) o versioni successive, il sistema limita ulteriormente i casi in cui le app possono avviare attività in background:

  • Quando un'app invia un PendingIntent utilizzando PendingIntent#send() o metodi simili, deve attivarla se vuole concedere i propri privilegi di lancio delle attività in background per avviare l'intent in attesa. Per attivare la funzionalità, l'app deve passare un ActivityOptions bundle con setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED).
  • Quando un'app visibile lega un servizio di un'altra app in background utilizzando il metodo bindService(), ora l'app visibile deve attivare l'opzione se vuole concedere i propri privilegi di lancio delle attività in background al servizio legato. Per attivare la funzionalità, l'app deve includere il flag BIND_ALLOW_ACTIVITY_STARTS quando chiama il metodo bindService().

Queste modifiche ampliano l'insieme esistente di limitazioni per proteggere gli utenti impedendo alle app dannose di usare impropriamente le API per avviare attività in background che possono causare interruzioni.

Zip path traversal

Per le app che hanno come target Android 14 (livello API 34) o versioni successive, Android impedisce la vulnerabilità di traversale del percorso ZIP nel seguente modo: ZipFile(String) e ZipInputStream.getNextEntry() genera un ZipException se i nomi delle voci dei file ZIP contengono ".." o iniziano con "/".

Le app possono disattivare questa convalida chiamando dalvik.system.ZipPathValidator.clearCallback().

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 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:

  1. Invoke VirtualDisplay#resize with the new width and height.
  2. Provide a new Surface with the new width and height to VirtualDisplay#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.

Limitazioni non SDK aggiornate

Android 14 include elenchi aggiornati di interfacce non SDK con limitazioni in base alla collaborazione con gli sviluppatori Android e ai test interni più recenti. Ove possibile, ci assicuriamo che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.

Se la tua app non ha come target Android 14, alcune di queste modifiche potrebbero non interessarti immediatamente. Tuttavia, anche se al momento puoi utilizzare alcune interfacce non SDK (a seconda del livello API target della tua app), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di interruzione dell'app.

Se non sai con certezza se la tua app utilizza interfacce non SDK, puoi testarla per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare una migrazione ad alternative SDK. Tuttavia, ci rendiamo conto 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à della tua app, devi richiedere una nuova API pubblica.

Per scoprire di più sulle modifiche in questa release di Android, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 14. Per scoprire di più sulle interfacce non SDK in generale, consulta Limitazioni relative alle interfacce non SDK.