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 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" />
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 introduce l'Accesso alle foto selezionate, che consente agli utenti di concedere alle app l'accesso a immagini e video specifici nella loro raccolta, anziché concedere l'accesso a tutti i contenuti multimediali di un determinato tipo.
Questa modifica viene 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, che migliori anche la privacy dell'utente senza dover richiedere autorizzazioni di archiviazione.
Se gestisci il tuo selettore galleria utilizzando le autorizzazioni di archiviazione e devi mantenere il controllo completo sull'implementazione, adatta l'implementazione per utilizzare la nuova autorizzazione READ_MEDIA_VISUAL_USER_SELECTED
. Se l'app non utilizza la nuova autorizzazione, il sistema esegue l'app in una modalità di compatibilità.
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
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
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
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
PendingIntent
usingPendingIntent#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 anActivityOptions
bundle 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_STARTS
flag 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.
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 include elenchi aggiornati di interfacce non SDK limitate in base alla collaborazione con gli sviluppatori Android e agli ultimi test interni. Quando possibile, ci assicuriamo che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.
Se la tua app non è destinata ad Android 14, alcune di queste modifiche potrebbero non essere applicate immediatamente. Tuttavia, anche se al momento puoi utilizzare alcune interfacce non SDK (a seconda del livello API target della tua app), l'utilizzo di metodi o campi non SDK comporta sempre un rischio elevato di danneggiare la tua app.
Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare l'app per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare una migrazione alle alternative SDK. Ciononostante, 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.
Per scoprire di più sulle modifiche introdotte in questa release di Android, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 14. Per saperne di più sulle interfacce non SDK in generale, consulta Limitazioni per le interfacce non SDK.