Come le release precedenti, Android 14 include modifiche del comportamento che potrebbero influire sulla tua app. Le seguenti modifiche del 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 modificare l'app per supportare correttamente questi comportamenti, ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano tutte le app
eseguite su Android 14 a prescindere
dalla 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 all'interno dell'app. 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 con un certo tipo soddisfino un particolare 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 i job di trasferimento di dati avviati dall'utente.
Applicazione dell'autorizzazione BLUETOOTH_CONNECT nell'adattatore Bluetooth
Android 14 applica l'autorizzazione BLUETOOTH_CONNECT
quando chiami il metodo
BluetoothAdapter
getProfileConnectionState()
per le app che hanno come target
Android 14 (livello API 34) o versioni successive.
Questo metodo richiede già l'autorizzazione BLUETOOTH_CONNECT
, ma non è stata applicata. Assicurati che la tua app dichiari BLUETOOTH_CONNECT
nel file
AndroidManifest.xml
dell'app 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 thejava.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 theDISALLOW_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 anIllegalArgumentException
during deserialization. To enable or disable this change while testing, toggle theENABLE_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 whetherClass.forName("java.lang.ClassValue")
returns a class or not. If your app was developed against an older version of the runtime without thejava.lang.ClassValue
class available, then these optimizations might remove thecomputeValue
method from classes derived fromjava.lang.ClassValue
.
JobScheduler rafforza il comportamento di callback e 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 viene eseguito troppo a lungo, si arresta e non viene eseguito correttamente. Se la tua app ha come target Android 14 (livello API 34) o versioni successive e supera il tempo consentito sul thread principale, l'app attiva un errore ANR con il messaggio di errore "Nessuna risposta a onStartJob
" o "Nessuna risposta a onStopJob
". Valuta la possibilità di eseguire la migrazione a WorkManager, che fornisce supporto per l'elaborazione asincrona o la migrazione di eventuali attività pesanti in un thread in background.
JobScheduler
introduce anche un requisito per dichiarare l'autorizzazione ACCESS_NETWORK_STATE
se utilizzi il vincolo setRequiredNetworkType
o setRequiredNetwork
. Se la tua app non dichiara l'autorizzazione
ACCESS_NETWORK_STATE
durante la pianificazione del job e ha come target
Android 14 o versioni successive, genererà SecurityException
.
API Tiles Launch
Per le app che hanno come target 14 e versioni successive,
TileService#startActivityAndCollapse(Intent)
è deprecato e ora genera
un'eccezione quando viene richiamato. Se la tua app avvia le attività dai riquadri, usa invece
TileService#startActivityAndCollapse(PendingIntent)
.
Privacy
Accesso parziale a foto e video
Android 14 introduces Selected Photos Access, which allows users to grant apps access to specific images and videos in their library, rather than granting access to all media of a given type.
This change is only enabled if your app targets Android 14 (API level 34) or higher. If you don't use the photo picker yet, we recommend implementing it in your app to provide a consistent experience for selecting images and videos that also enhances user privacy without having to request any storage permissions.
If you maintain your own gallery picker using storage permissions and need to
maintain full control over your implementation, adapt your implementation
to use the new READ_MEDIA_VISUAL_USER_SELECTED
permission. If your app
doesn't use the new permission, the system runs your app in a compatibility
mode.
Esperienza utente
Notifiche di intent a schermo intero sicure
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.
Sicurezza
Limitazioni 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 a componenti interni delle app nei seguenti modi:
- Gli intent impliciti vengono inviati solo ai componenti esportati. Le app devono utilizzare un intent esplicito per la pubblicazione in componenti non esportati o contrassegnare il componente come esportato.
- Se un'app crea un intent in attesa modificabile con un intent che non specifica un componente o un pacchetto, il sistema genera un'eccezione.
Queste modifiche impediscono alle app dannose di intercettare intent impliciti destinati a essere utilizzati dai componenti interni di un'app.
Ad esempio, ecco un filtro intent che potrebbe essere dichiarato nel file manifest dell'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 l'app tentasse di avviare questa attività utilizzando un intent implicito, verrà generata un'eccezione:
Kotlin
// Throws an exception when targeting Android 14. context.startActivity(Intent("com.example.action.APP_ACTION"))
Java
// Throws an exception when targeting Android 14. context.startActivity(new Intent("com.example.action.APP_ACTION"));
Per avviare l'attività non esportata, la tua app deve 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 destinatari delle trasmissioni registrate in runtime devono specificare il comportamento di esportazione
Per le app e i servizi che hanno come target Android 14 (livello API 34) o versioni successive e che utilizzano ricevitori registrati in contesto è necessario specificare un flag che indichi se il destinatario deve essere esportato o meno in tutte le altre app sul dispositivo: rispettivamente RECEIVER_EXPORTED
o RECEIVER_NOT_EXPORTED
.
Questo requisito consente di proteggere le app dalle vulnerabilità della sicurezza sfruttando le funzionalità di questi ricevitori introdotte in Android 13.
Eccezione per i ricevitori che ricevono solo trasmissioni di sistema
Se la tua app registra un ricevitore solo per le trasmissioni di sistema tramite metodi Context#registerReceiver
, come Context#registerReceiver()
, non dovrebbe specificare un flag durante la registrazione del ricevitore.
Caricamento del codice dinamico più sicuro
Se la tua app ha come target Android 14 (livello API 34) o versioni successive e utilizza il caricamento dinamico del codice (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 il caricamento dinamico del codice ogni volta che è possibile, in quanto ciò aumenta notevolmente il rischio che un'app venga compromessa a causa dell'inserimento o della manomissione del codice.
Se devi caricare il codice in modo dinamico, utilizza il seguente approccio per impostare il file caricato dinamicamente (ad esempio un file DEX, JAR o APK) come di sola lettura non appena il file viene aperto e prima che venga scritto un contenuto:
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 già esistenti
Per evitare che vengano generate eccezioni per i file esistenti caricati dinamicamente, ti consigliamo di eliminarli e ricrearli prima di provare a caricarli di nuovo nell'app in modo dinamico. Quando ricrei i file, segui le linee guida precedenti per contrassegnare i file come di sola lettura al momento della scrittura. In alternativa, puoi rietichettare 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 con un valore attendibile), per proteggere la tua app da azioni dannose.
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 alle app è consentito avviare attività in background:
- Quando un'app invia un elemento
PendingIntent
utilizzandoPendingIntent#send()
o metodi simili, l'app deve eseguire l'attivazione se vuole concedere i propri privilegi di avvio per l'attività in background per avviare l'intent in sospeso. Per l'attivazione, l'app deve trasmettere un bundleActivityOptions
consetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
. - Quando un'app visibile associa un servizio di un'altra app in background
con il metodo
bindService()
, ora l'app visibile deve essere attivata se vuole concedere i propri privilegi di avvio delle attività in background al servizio associato. Per l'attivazione, l'app deve includere il flagBIND_ALLOW_ACTIVITY_STARTS
quando chiami il metodobindService()
.
Queste modifiche ampliano l'insieme di limitazioni esistenti per proteggere gli utenti impedendo alle app dannose di utilizzare in modo illecito le API di avviare attività di disturbo in background.
Attraversamento percorso zip
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()
.
Consenso dell'utente richiesto per ogni sessione di acquisizione MediaProjection
Per le app che hanno come target Android 14 (livello API 34) o versioni successive, un valore SecurityException
viene generato da MediaProjection#createVirtualDisplay
in uno dei seguenti scenari:
- L'app memorizza nella cache l'elemento
Intent
restituito daMediaProjectionManager#createScreenCaptureIntent
e lo passa più volte aMediaProjectionManager#getMediaProjection
. - L'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 sessione di acquisizione singola è una singola chiamata su MediaProjection#createVirtualDisplay
e ogni istanza 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 la modifica delle dimensioni dello schermo), puoi seguire questi passaggi per aggiornare VirtualDisplay
per l'istanza MediaProjection
esistente:
- Richiama
VirtualDisplay#resize
con la nuova larghezza e l'altezza. - Fornisci un nuovo
Surface
con la nuova larghezza e l'altezza perVirtualDisplay#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. A questo scopo, implementa Callback#onStop
e rilascia all'app eventuali risorse correlate (ad esempio VirtualDisplay
e Surface
).
Se la tua app non registra questo callback, MediaProjection#createVirtualDisplay
genera un IllegalStateException
quando l'app lo richiama.
Limitazioni non SDK aggiornate
Android 14 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.
If your app does not target Android 14, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.
If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.
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 Restrizioni sulle interfacce non SDK.