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

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 continua il lavoro 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 a gruppi non validi non possono ora seguire meglio la semantica di OpenJDK. Potresti notare nuovi casi in cui la classe java.util.regex.Matcher genera un valore IllegalArgumentException, quindi assicurati di testare la tua app per individuare aree che utilizzano espressioni regolari. Per attivare o disattivare questa modifica durante il test, attiva/disattiva il flag DISALLOW_INVALID_GROUP_REFERENCE utilizzando gli strumenti del framework di compatibilità.
  • Gestione dell'UUID: il metodo java.util.UUID.fromString() ora esegue controlli più rigorosi durante la convalida dell'argomento di input, quindi potresti vedere una IllegalArgumentException durante la deserializzazione. Per attivare o disattivare questa modifica durante il test, attiva/disattiva il flag ENABLE_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 tenti di ridurre, offuscare e ottimizzare la tua app utilizzando ProGuard. Il problema ha origine da una libreria Kotlin che modifica il comportamento di runtime a seconda che Class.forName("java.lang.ClassValue") restituisca o meno una classe. Se la tua app è stata sviluppata su una versione precedente del runtime senza la classe java.lang.ClassValue disponibile, queste ottimizzazioni potrebbero rimuovere il metodo computeValue dalle classi derivate da java.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.

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

Con Android 11 (livello API 30), qualsiasi app può usare Notification.Builder.setFullScreenIntent per inviare intent a schermo intero quando lo smartphone è bloccato. Puoi concedere automaticamente l'autorizzazione al momento dell'installazione dell'app dichiarando l'autorizzazione USE_FULL_SCREEN_INTENT nel file AndroidManifest.

Le notifiche di intent a schermo intero sono progettate per notifiche con priorità estremamente elevata che richiedono l'attenzione immediata dell'utente, ad esempio le impostazioni di una telefonata o di una sveglia configurate dall'utente. Per le app che hanno come target Android 14 (livello API 34) o versioni successive, le app a cui è consentito utilizzare questa autorizzazione sono limitate a quelle che offrono soltanto chiamate e sveglie. Il Google Play Store revoca le autorizzazioni USE_FULL_SCREEN_INTENT predefinite per tutte le app che non rientrano nel 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 dell'utente 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 intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT per lanciare la pagina delle impostazioni in cui gli utenti possono concedere l'autorizzazione.

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 utilizzando PendingIntent#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 bundle ActivityOptions con setPendingIntentBackgroundActivityStartMode(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 flag BIND_ALLOW_ACTIVITY_STARTS quando chiami il metodo bindService().

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

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

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

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

  1. Richiama VirtualDisplay#resize con la nuova larghezza e l'altezza.
  2. Fornisci un nuovo Surface con la nuova larghezza e l'altezza per VirtualDisplay#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.