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

Come le release precedenti, Android 15 include modifiche del comportamento che potrebbero interessare la tua app. Le seguenti modifiche del comportamento si applicano esclusivamente alle app che: che hanno come target Android 15 o versioni successive. Se la tua app ha come target Android 15 o versioni successive, devi modificare l'app per supportare correttamente questi comportamenti, dove applicabile.

Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano tutte le app. su Android 15 indipendentemente dall'targetSdkVersion dell'app.

Funzionalità di base

Android 15 modifica o espande varie funzionalità di base del sistema Android.

Modifiche ai servizi in primo piano

我们将在 Android 15 中对前台服务进行以下更改。

数据同步前台服务超时行为

Android 15 introduce un nuovo comportamento di timeout in dataSync per il targeting per app Android 15 (livello API 35) o versioni successive. Questo comportamento vale anche per i nuovi mediaProcessing tipo di servizio in primo piano.

Il sistema consente l'esecuzione dei servizi dataSync di un'app per un totale di 6 ore in un periodo di 24 ore, dopodiché il sistema chiama Metodo Service.onTimeout(int, int) (introdotto su Android 15). Al momento, il servizio ha alcuni secondi di tempo per chiamare Service.stopSelf() Quando viene chiamato Service.onTimeout(), il parametro non è più considerato un servizio in primo piano. Se il servizio non chiama Service.stopSelf(), il sistema genera un'eccezione interna. La viene registrata in Logcat con il seguente messaggio:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

Per evitare problemi con questa modifica del comportamento, puoi eseguire una o più delle seguenti operazioni seguenti:

  1. Fai in modo che il tuo servizio implementi il nuovo metodo Service.onTimeout(int, int). Quando la tua app viene richiamata, assicurati di chiamare il numero stopSelf() entro un per alcuni secondi. Se non interrompi subito l'app, il sistema genera errore).
  2. Assicurati che i servizi dataSync della tua app non vengano eseguiti per un totale di più di 6 ore in un periodo di 24 ore (a meno che l'utente non interagisca con l'app, reimpostare il timer).
  3. Avvia dataSync servizi in primo piano solo da un utente diretto interazione; poiché l'app è in primo piano all'avvio del servizio, il servizio ha tutte le sei ore dopo che l'app è passata in background.
  4. Anziché utilizzare un servizio in primo piano dataSync, usa un'istanza API alternativa.

Se i servizi in primo piano dataSync della tua app sono stati eseguiti per 6 ore nelle ultime 6 ore 24, non puoi avviare un altro servizio in primo piano dataSync a meno che l'utente ha messo la tua app in primo piano (operazione che reimposta il timer). Se provi a avviare un altro servizio in primo piano dataSync, il sistema genera ForegroundServiceStartNotAllowedException con un messaggio di errore del tipo "Limite di tempo già esaurito per il servizio in primo piano digita dataSync".

Test

Per verificare il comportamento della tua app, puoi attivare i timeout per la sincronizzazione dei dati anche se l'app non abbia come target Android 15 (purché l'app sia installata su un dispositivo Android 15) dispositivo). Per abilitare i timeout, esegui questo comando adb:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

Puoi anche regolare il periodo di timeout per verificare più facilmente come l'app si comporta quando viene raggiunto il limite. Per impostare un nuovo periodo di timeout, esegui il comando seguente comando adb:

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

新建媒体处理前台服务类型

Android 15 introduce un nuovo tipo di servizio in primo piano, mediaProcessing. Questo è appropriato per operazioni come la transcodifica di file multimediali. Per Ad esempio, un'app multimediale può scaricare un file audio e deve convertirlo in un un formato diverso prima di riprodurlo. Puoi utilizzare un primo piano mediaProcessing per assicurarti che la conversione continui anche mentre l'app è sfondo.

Il sistema consente l'esecuzione dei servizi mediaProcessing di un'app per un totale di 6 in un periodo di 24 ore, dopodiché il sistema chiama Metodo Service.onTimeout(int, int) (introdotto su Android 15). Al momento, il servizio ha alcuni secondi di tempo per chiamare Service.stopSelf() Se il servizio non chiama Service.stopSelf(), il sistema genera un'eccezione interna. La viene registrata in Logcat con il seguente messaggio:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

Per evitare questa eccezione, puoi procedere in uno dei seguenti modi:

  1. Fai in modo che il tuo servizio implementi il nuovo metodo Service.onTimeout(int, int). Quando la tua app viene richiamata, assicurati di chiamare il numero stopSelf() entro un per alcuni secondi. Se non interrompi subito l'app, il sistema genera errore).
  2. Assicurati che i servizi mediaProcessing della tua app non vengano eseguiti per più di un totale di 6 ore in un periodo di 24 ore (a meno che l'utente non interagisca con l'app, reimpostando il timer).
  3. Avvia mediaProcessing servizi in primo piano solo dall'utente diretto interazione; poiché l'app è in primo piano all'avvio del servizio, il servizio ha tutte le sei ore dopo che l'app è passata in background.
  4. Anziché utilizzare un servizio in primo piano mediaProcessing, usa una alternativa API, come WorkManager.

Se i servizi in primo piano mediaProcessing della tua app sono stati eseguiti da 6 ore in ultimi 24, non puoi avviare un altro mediaProcessing servizio in primo piano a meno che l'utente ha messo in primo piano la tua app (operazione che reimposta il timer). Se provare ad avviare un altro servizio in primo piano mediaProcessing, il sistema restituisce ForegroundServiceStartNotAllowedException con un messaggio di errore del tipo "Limite di tempo già esaurito per il servizio in primo piano tipo mediaProcessing".

Per ulteriori informazioni sul tipo di servizio mediaProcessing, consulta l'articolo Modifiche a tipi di servizi in primo piano per Android 15: elaborazione dei contenuti multimediali.

Test

Per testare il comportamento della tua app, puoi attivare i timeout per l'elaborazione dei contenuti multimediali anche se la tua app non ha come target Android 15 (purché l'app sia in esecuzione su un dispositivo Android 15). Per abilitare i timeout, esegui questo comando adb:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

Puoi anche regolare il periodo di timeout per verificare più facilmente come l'app si comporta quando viene raggiunto il limite. Per impostare un nuovo periodo di timeout, esegui il comando seguente comando adb:

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

对启动前台服务的 BOOT_COMPLETED 广播接收器实施限制

在启动 BOOT_COMPLETED 广播接收器方面存在新限制 前台服务。BOOT_COMPLETED 接收器不能启动 以下类型的前台服务：

如果 BOOT_COMPLETED 接收器尝试启动任何上述类型的前台 服务，系统会抛出 ForegroundServiceStartNotAllowedException。

测试

如需测试应用的行为，您可以启用这些新限制，即使您的应用并未以 Android 15 为目标平台（只要应用在 Android 15 设备上运行）也是如此。运行以下 adb 命令：

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

如需在不重启设备的情况下发送 BOOT_COMPLETED 广播，请运行以下 adb 命令：

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name

限制在应用拥有 SYSTEM_ALERT_WINDOW 权限时启动前台服务

In precedenza, se un'app aveva l'autorizzazione SYSTEM_ALERT_WINDOW, poteva avviarsi un servizio in primo piano anche se l'app era attualmente in background (ad esempio, discusso in Esenzioni dalle limitazioni relative all'avvio in background.

Se un'app ha come target Android 15, l'esenzione è ora più limitata. L'app ora deve per avere l'autorizzazione SYSTEM_ALERT_WINDOW e avere anche un overlay visibile finestra. Questo significa che l'app deve prima avviare TYPE_APPLICATION_OVERLAY finestra e finestra deve essere visibile prima di avviare un servizio in primo piano.

Se la tua app tenta di avviare un servizio in primo piano in background senza che soddisfano questi nuovi requisiti (e non prevede altre esenzioni), i genera ForegroundServiceStartNotAllowedException.

Se la tua app dichiara l'autorizzazione SYSTEM_ALERT_WINDOW e avvia i servizi in primo piano in background, potrebbe essere interessato da questa modifica. Se la tua app riceve un ForegroundServiceStartNotAllowedException, controlla l'ordine di operazioni dell'app e assicurati che abbia già un indirizzo prima che tenti di avviare un servizio in primo piano dall' sfondo. Puoi verificare se la finestra dell'overlay è attualmente visibile chiamando il numero View.getWindowVisibility() oppure può eseguire l'override di View.onWindowVisibilityChanged() di ricevere una notifica ogni volta che la visibilità cambia.

Test

Per verificare il comportamento della tua app, puoi attivare queste nuove limitazioni anche se le tue L'app non ha come target Android 15 (purché l'app sia installata su un Android 15) dispositivo). Per attivare queste nuove limitazioni all'avvio dei servizi in primo piano: in background, esegui questo comando adb:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

Modifiche relative a quando le app possono modificare lo stato globale della modalità Non disturbare

Le app destinate ad Android 15 non possono più modificare lo stato o il criterio globale della modalità Non disturbare su un dispositivo (modificando le impostazioni utente o disattivando la modalità DND). Le app devono però fornire un codice AutomaticZenRule, che il sistema combina in un criterio globale con lo schema con il criterio più restrittivo e vincente. Le chiamate alle API esistenti che in precedenza influenzavano lo stato globale (setInterruptionFilter, setNotificationPolicy) comportano la creazione o l'aggiornamento di un elemento AutomaticZenRule implicito, che viene attivato e disattivato a seconda del ciclo di chiamata di queste chiamate API.

Tieni presente che questa modifica influisce solo sul comportamento osservabile se l'app chiama setInterruptionFilter(INTERRUPTION_FILTER_ALL) e si aspetta che quella chiamata disattivi un AutomaticZenRule che era stato precedentemente attivato dai rispettivi proprietari.

Modifiche all'API OpenJDK

Android 15 continua il lavoro di aggiornamento delle librerie principali di Android per allineare con le funzionalità delle ultime release di OpenJDK LTS.

Alcune di queste modifiche possono influire sulla compatibilità delle app per il targeting per app Android 15 (livello API 35):

  • Modifiche alle API di formattazione delle stringhe: convalida di indice di argomenti, flag la larghezza e la precisione sono ora più rigide quando si utilizza API String.format() e Formatter.format():

    Ad esempio, la seguente eccezione viene generata quando un indice di argomento è 0 (%0 nella stringa di formato):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

    In questo caso, il problema può essere risolto utilizzando un indice di argomento pari a 1 (%1 nella stringa di formato).

  • Modifiche al tipo di componente di Arrays.asList(...).toArray(): quando si utilizza Arrays.asList(...).toArray(), il tipo di componente dell'array risultante è ora Object, non il tipo di elementi dell'array sottostante. Quindi, seguente codice genera un ClassCastException:

    String[] elements = (String[]) Arrays.asList("one", "two").toArray();

    In questo caso, per mantenere String come tipo di componente nel risultato puoi utilizzare Collection.toArray(Object[]):

    String[] elements = Arrays.asList("two", "one").toArray(new String[0]);

  • Modifiche alla gestione del codice lingua: quando utilizzi l'API Locale, i codici lingua per ebraico, yiddish e indonesiano non vengono più convertiti alle loro forme obsolete (ebraico: iw, yiddish: ji e indonesiano: in). Quando specifichi il codice lingua per una di queste lingue, utilizza i codici ISO 639-1 (ebraico: he, Yiddish: yi e indonesiano: id).

  • Modifiche alle sequenze int casuali: l'applicazione delle modifiche apportate in https://bugs.openjdk.org/browse/JDK-8301574, i seguenti I metodi Random.ints() ora restituiscono una sequenza di numeri diversa rispetto a i metodi Random.nextInt():

    In genere, questa modifica non deve portare a un comportamento in grado di rompere gli utenti, ma nel codice non deve aspettarsi che la sequenza generata dai metodi Random.ints() corrispondono a Random.nextInt().

La nuova API SequencedCollection può influire sulla compatibilità della tua app dopo aver aggiornato compileSdk nella configurazione della build dell'app per utilizzare Android 15 (livello API 35):

  • Collisione con MutableList.removeFirst() e Funzioni dell'estensione MutableList.removeLast() in kotlin-stdlib

    Il tipo List in Java è mappato al tipo MutableList in Kotlin. Poiché le API List.removeFirst() e List.removeLast() sono state introdotte in Android 15 (livello API 35), il compilatore Kotlin risolve le chiamate di funzione, ad esempio list.removeFirst(), in modo statico le nuove API List anziché le funzioni di estensione in kotlin-stdlib.

    Se un'app viene ricompilata con compileSdk impostato su 35 e minSdk impostato su 34 o versioni precedenti, quindi l'app viene eseguita su Android 14 e versioni precedenti, viene visualizzato un errore:

    java.lang.NoSuchMethodError: No virtual method
removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;

    L'opzione lint NewApi esistente nel plug-in Android Gradle può rilevare questi nuovi utilizzi dell'API.

    ./gradlew lint

MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
      list.removeFirst()

    Per correggere l'eccezione di runtime e gli errori di lint, i valori removeFirst() e Le chiamate di funzione removeLast() possono essere sostituite con removeAt(0) e removeAt(list.lastIndex) rispettivamente a Kotlin. Se utilizzi Android Studio Ladybug | 2024.1.3 o versioni successive, fornisce anche una correzione rapida per questi errori.

    Valuta la possibilità di rimuovere @SuppressLint("NewApi") e lintOptions { disable 'NewApi' } se l'opzione lint è stata disattivata.

  • Collisione con altri metodi in Java

    Nei tipi esistenti sono stati aggiunti nuovi metodi, ad esempio List e Deque. Questi nuovi metodi potrebbero non essere compatibili con i metodi con lo stesso nome e tipi di argomento in altre interfacce e corsi. Nel caso di una collisione tra firme di metodo e incompatibilità, il compilatore javac restituisce un errore in fase di build. Per esempio:

    Esempio di errore 1:

    javac MyList.java

MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List
  public void removeLast() {
              ^
  return type void is not compatible with Object
  where E is a type-variable:
    E extends Object declared in interface List

    Esempio di errore 2:

    javac MyList.java

MyList.java:7: error: types Deque<Object> and List<Object> are incompatible;
public class MyList implements  List<Object>, Deque<Object> {
  both define reversed(), but with unrelated return types
1 error

    Esempio di errore 3:

    javac MyList.java

MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible;
public static class MyList implements List<Object>, MyInterface<Object> {
  class MyList inherits unrelated defaults for getFirst() from types List and MyInterface
  where E#1,E#2 are type-variables:
    E#1 extends Object declared in interface List
    E#2 extends Object declared in interface MyInterface
1 error

    Per correggere questi errori di generazione, il corso che implementa queste interfacce deve sostituisci il metodo con un tipo restituito compatibile. Ad esempio:

    @Override
public Object getFirst() {
    return List.super.getLast();
}

Sicurezza

Android 15 include modifiche che promuovono la sicurezza del sistema per contribuire a proteggere le app e gli utenti di app dannose.

Lanci di attività in background protette

Android 15 protegge gli utenti da app dannose e offre loro un maggiore controllo i propri dispositivi aggiungendo modifiche che impediscano ad app in background dannose di mettere in primo piano altre app, aumentare i loro privilegi e abusare interazione dell'utente. I lanci di attività in background sono stati limitati dal giorno Android 10 (livello API 29).

Impedisci alle app che non corrispondono all'UID principale nell'impilare di avviare attività

Le app dannose possono avviare l'attività di un'altra app all'interno della stessa attività, quindi sovrapporsi, creando l'illusione di essere quell'app. Questo attacco di "pirateria dell'attività" aggira le attuali limitazioni di lancio in background perché avviene all'interno della stessa attività visibile. Per ridurre questo rischio, Android 15 aggiunge un un flag che impedisce l'avvio delle app che non corrispondono all'UID principale nello stack attività. Per attivare tutte le attività delle app, aggiorna le allowCrossUidActivitySwitchFromBelow nel file AndroidManifest.xml dell'app:

<application android:allowCrossUidActivitySwitchFromBelow="false" >

Le nuove misure di sicurezza sono attive se tutte le seguenti condizioni sono vere:

  • L'app che esegue il lancio ha come target Android 15.
  • L'app nella parte superiore dello stack di attività ha come target Android 15.
  • Per qualsiasi attività visibile sono state attivate le nuove protezioni

Se le misure di sicurezza sono attive, le app potrebbero tornare alla schermata Home anziché all'ultima app visibile se completano la propria attività.

Altre modifiche

Oltre alla limitazione per la corrispondenza dell'UID, anche queste altre modifiche vengono inclusi:

  • Modifica i creator di PendingIntent in modo che blocchino l'avvio delle attività in background per impostazione predefinita. In questo modo è possibile impedire alle app di creare accidentalmente un PendingIntent che potrebbero essere utilizzati in modo illecito da malintenzionati.
  • Non mettere un'app in primo piano a meno che il mittente PendingIntent lo consente. Questa modifica ha lo scopo di impedire alle app dannose di utilizzare in modo illecito possibilità di avviare attività in background. Per impostazione predefinita, alle app non è consentito portare la serie di attività in primo piano, a meno che il creator non consenta i privilegi di lancio delle attività in background o che il mittente non disponga di questi privilegi.
  • Controlla il modo in cui l'attività principale di uno stack di attività può completarne le attività. Se attività principale completa un'attività, Android torna all'attività precedente l'ultima attività. Inoltre, se un'attività non principale completa la propria attività, Android torna alla home page; non bloccherà la finitura di questa parte non superiore attività.
  • Impedisci di avviare attività arbitrarie da altre app alla tua. un'attività. Questa modifica impedisce alle app dannose di applicare phishing agli utenti creando attività che sembrano provenire da altre app.
  • Impedire che le finestre non visibili vengano prese in considerazione per l'attività in background Google Cloud. In questo modo è possibile evitare che app dannose utilizzino in modo illecito lo sfondo. viene avviata un'attività per mostrare agli utenti contenuti indesiderati o dannosi.

Intent più sicuri

Android 15 引入了新的安全措施，可让 intent 更加安全且更安全 稳健。这些变更旨在防范潜在的漏洞和 可能会被恶意应用利用的 intent 滥用。有两个主要的 Android 15 中对 intent 安全性的改进：

  • 匹配目标 intent 过滤器：针对特定组件的 intent 准确匹配目标的 intent 过滤器规范。如果您发送 intent 来启动另一个应用的 activity，则目标 intent 组件需要 与接收 activity 声明的 intent 过滤器保持一致。
  • intent 必须具有操作：没有操作的 intent 将不再匹配 任何 intent 过滤器。也就是说，用于启动 activity 或 服务都必须有明确定义的操作。
  • 待处理 intent：待处理 intent 的创建者为 被视为封装 intent 的发送者，而非待处理 intent 的发送者 意图
。

Kotlin


fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

Java


public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

Esperienza utente e UI di sistema

Android 15 include alcune modifiche volte a creare un un'esperienza utente intuitiva.

Modifiche agli riquadri delle finestre

Esistono due modifiche relative ai riquadri di finestre in Android 15: edge-to-edge è applicato per impostazione predefinita e esistono anche modifiche alla configurazione, ad esempio la configurazione predefinita delle barre di sistema.

全面实施政策

Le app sono edge-to-edge per impostazione predefinita sui dispositivi con Android 15, se sono che hanno come target Android 15 (livello API 35).

Un'app che ha come target Android 14 e non è edge-to-edge su un Dispositivo Android 15.


Un'app che ha come target Android 15 (livello API 35) ed è edge-to-edge su un dispositivo Android 15. Questa app utilizza principalmente i componenti Compose Material 3 che applicano automaticamente i riquadri. Questa schermata non è influenzata negativamente dal Applicazione edge-to-edge di Android 15.

Si tratta di una modifica che provoca un errore che potrebbe influire negativamente sull'UI della tua app. La interessano le seguenti aree dell'interfaccia utente:

  • Barra di navigazione con gestione dei gesti
      .
    • Trasparente per impostazione predefinita.
    • L'offset inferiore è disattivato, quindi i contenuti vengono spostati dietro la navigazione del sistema barra, a meno che non vengano applicati inserti.
    • setNavigationBarColor e R.attr#navigationBarColor sono è deprecata e non influisce sulla navigazione tramite gesti.
    • setNavigationBarContrastEnforced e R.attr#navigationBarContrastEnforced continuano a non avere alcun effetto navigazione tramite gesti.
  • Navigazione con tre pulsanti
      .
    • Opacità impostata su 80% per impostazione predefinita, con un colore che potrebbe corrispondere alla finestra sfondo.
    • Offset inferiore disattivato in modo che i contenuti vengano visualizzati dietro la barra di navigazione del sistema a meno che non vengano applicati inserti.
    • setNavigationBarColor e R.attr#navigationBarColor sono impostato in modo che corrisponda allo sfondo della finestra per impostazione predefinita. Lo sfondo della finestra deve essere un colore disegnabile per applicare questo valore predefinito. Questa API è è deprecata, ma continua a influire sulla navigazione con tre pulsanti.
    • setNavigationBarContrastEnforced e Per impostazione predefinita, R.attr#navigationBarContrastEnforced è impostato su true e aggiunge un Sfondo opaco all'80% nella navigazione con tre pulsanti.
  • Barra di stato
      .
    • Trasparente per impostazione predefinita.
    • L'offset superiore è disattivato, quindi i contenuti vengono disegnati dietro la barra di stato a meno che i riquadri.
    • setStatusBarColor e R.attr#statusBarColor sono è deprecata e non ha alcun effetto su Android 15.
    • setStatusBarContrastEnforced e I R.attr#statusBarContrastEnforced sono deprecati, ma hanno ancora un su Android 15.
  • Staglio display
      .
    • Il layoutInDisplayCutoutMode di finestre non mobili deve essere LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. SHORT_EDGES, NEVER e DEFAULT vengono interpretati come ALWAYS in modo che gli utenti non vedano un colore nero causata dal ritaglio display e appare edge-to-edge.

L'esempio seguente mostra un'app prima e dopo il targeting Android 15 (livello API 35) e prima e dopo l'applicazione dei riquadri.

Un'app che ha come target Android 14 e non è edge-to-edge su un Dispositivo Android 15.
di Gemini Advanced.
Un'app che ha come target Android 15 (livello API 35) ed è edge-to-edge su un dispositivo Android 15. Tuttavia, molti elementi sono ora nascosti dallo stato barra, barra di navigazione con tre pulsanti o ritaglio display a causa di Android 15 delle applicazioni edge-to-edge. L'UI nascosta include Material 2 barra delle app in alto, pulsanti di azione fluttuanti ed elementi dell'elenco.
di Gemini Advanced.
Un'app che ha come target Android 15 (livello API 35) è edge-to-edge un dispositivo Android 15 e applica i riquadri in modo che l'UI nascosti.
Cosa controllare se la tua app è già edge-to-edge

Se la tua app è già edge-to-edge e applica inserti, in gran parte non interessate, tranne che nei seguenti scenari. Tuttavia, anche se pensi non sei interessato, ti consigliamo di testare l'app.

  • Hai una finestra non mobile, ad esempio una Activity che utilizza SHORT_EDGES, NEVER o DEFAULT invece di LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. Se l'app ha un arresto anomalo all'avvio, potrebbe essere dovuto alla schermata iniziale. Puoi eseguire l'upgrade delle dipendenza della schermata iniziale a 1.2.0-alpha01 o una data successiva oppure imposta window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always.
  • Potrebbero esserci schermate con traffico ridotto con UI nascosta. Verifica questi gli schermi meno visitati non hanno un'interfaccia utente nascosta. Le schermate con traffico ridotto includono:
    • Schermate di onboarding o di accesso
    • Pagine Impostazioni
Cosa controllare se la tua app non è già edge-to-edge

Se la tua app non è già edge-to-edge, è molto probabile che il problema riguardi il tuo. Nella oltre agli scenari per le app già edge-to-edge, dovresti tieni in considerazione quanto segue:

  • Se la tua app utilizza i componenti Material 3 ( androidx.compose.material3) nella modalità di scrittura, ad esempio TopAppBar, BottomAppBar e NavigationBar, è probabile che questi componenti non interessati perché gestiscono automaticamente gli inserti.
  • Se la tua app utilizza componenti Material 2 ( androidx.compose.material) in Compose, questi componenti non gestiscono automaticamente gli inserti. Tuttavia, puoi accedere ai riquadri e applicarle manualmente. In androidx.compose.material 1.6.0 e in seguito, usa il parametro windowInsets per applicare manualmente i riquadri BottomAppBar, TopAppBar, BottomNavigation e NavigationRail. Allo stesso modo, utilizza il parametro contentWindowInsets per Scaffold
  • Se la tua app utilizza viste e componenti Material (com.google.android.material), la maggior parte dei materiali basati sulle visualizzazioni Componenti come BottomNavigationView, BottomAppBar, NavigationRailView o NavigationView, che gestiscono i riquadri e non richiedono lavoro aggiuntivo. Tuttavia, devi aggiungere android:fitsSystemWindows="true" se utilizzi AppBarLayout.
  • Per gli elementi componibili personalizzati, applica i riquadri manualmente come spaziatura interna. Se le tue i contenuti si trovano all'interno di un Scaffold, puoi utilizzare i riquadri utilizzando il Scaffold valori di spaziatura interna. In caso contrario, applica la spaziatura interna utilizzando uno dei WindowInsets
  • Se la tua app utilizza visualizzazioni e BottomSheet, SideSheet o personalizzate dei container, applica la spaziatura interna ViewCompat.setOnApplyWindowInsetsListener Per RecyclerView, applica la spaziatura interna utilizzando questo listener e aggiungi anche clipToPadding="false".
Cosa controllare se l'app deve offrire una protezione in background personalizzata

Se la tua app deve offrire una protezione personalizzata in background per la navigazione con tre pulsanti oppure la barra di stato, devi posizionare una visualizzazione componibile o dietro la barra di sistema utilizzando WindowInsets.Type#tappableElement() per ottenere i tre pulsanti altezza della barra di navigazione o WindowInsets.Type#statusBars.

Risorse edge-to-edge aggiuntive

Vedi le sezioni Visualizzazioni edge to Edge e Scrittura Edge to Edge guide per ulteriori considerazioni sull'applicazione dei riquadri.

API deprecate

Le seguenti API sono state ritirate:

稳定配置

Se la tua app ha come target Android 15 (livello API 35) o versioni successive, Configuration non escludendo più le barre di sistema. Se utilizzi le dimensioni dello schermo Classe Configuration per il calcolo del layout, devi sostituirla con una migliore alternative come ViewGroup, WindowInsets WindowMetricsCalculator a seconda delle tue esigenze.

Configuration è disponibile a partire dall'API 1. In genere viene ottenuto Activity.onConfigurationChanged. Fornisce informazioni come la densità della finestra, orientamento e dimensioni. Una caratteristica importante delle dimensioni delle finestre restituito da Configuration significa che in precedenza le barre di sistema sono state escluse.

Le dimensioni della configurazione vengono in genere utilizzate per la selezione delle risorse, ad esempio /res/layout-h500dp e questo è ancora un caso d'uso valido. Tuttavia, utilizzarlo per il calcolo del layout è sempre stato sconsigliato. In questo caso, devi spostare lontano da lì. Devi sostituire l'utilizzo di Configuration con qualcosa più adatti a seconda del caso d'uso.

Se lo utilizzi per calcolare il layout, usa un valore ViewGroup appropriato, come CoordinatorLayout o ConstraintLayout. Se la utilizzi per determinare l'altezza della barra di navigazione del sistema, utilizza WindowInsets. Se vuoi conoscere la dimensione attuale della finestra dell'app, usa computeCurrentWindowMetrics.

Di seguito sono elencati i campi interessati da questa modifica:

L'attributo eleganteTextHeight è impostato su true per impostazione predefinita

Per le app che hanno come target Android 15, l'attributo elegantTextHeight TextView diventa true per impostazione predefinita, sostituendo il carattere compatto usato per impostazione predefinita con alcuni script che hanno metriche verticali di grandi dimensioni con una molto più leggibile. Il carattere compatto è stato introdotto per evitare interruzioni nei layout. Android 13 (livello API 33) impedisce molte di queste interruzioni consentendo al layout del testo di estendere l'altezza verticale utilizzando l'attributo fallbackLineSpacing.

In Android 15, il carattere compatto rimane ancora nel sistema, pertanto la tua app può impostare elegantTextHeight su false per avere lo stesso comportamento di prima, ma è improbabile che sia supportato nelle prossime release. Pertanto, se la tua app supporta i seguenti script: arabo, laotiano, Myanmar, tamil, gujarati, kannada, malayalam, Odia, telugu o thailandese, testa l'app impostando elegantTextHeight su true.

Comportamento di elegantTextHeight per le app che hanno come target Android 14 (livello API 34) e versioni precedenti.
Comportamento di elegantTextHeight per le app destinate ad Android 15.

Cambia la larghezza di TextView per forme di lettere complesse

Nelle versioni precedenti di Android, alcuni caratteri o linguaggi corsivi con una forma complessa può tracciare le lettere nell'area del carattere precedente o successivo. In alcuni casi, queste lettere venivano tagliate nella posizione iniziale o finale. A partire da Android 15, TextView alloca la larghezza per disegnare spazio sufficiente tali caratteri e consente alle app di richiedere spaziature interne aggiuntive a sinistra evitare il ritaglio.

Poiché questa modifica influisce sul modo in cui TextView decide la larghezza, TextView alloca più larghezza per impostazione predefinita se l'app ha come target Android 15 (livello API 35) oppure in alto. Puoi abilitare o disabilitare questo comportamento richiamando il metodo API setUseBoundsForWidth su TextView.

Poiché l'aggiunta di una spaziatura interna a sinistra potrebbe causare un disallineamento per i layout esistenti, La spaziatura interna non viene aggiunta per impostazione predefinita anche per le app destinate ad Android 15 o versioni successive. Tuttavia, puoi aggiungere spaziatura interna extra per evitare il ritaglio chiamando setShiftDrawingOffsetForStartOverhang.

I seguenti esempi mostrano come queste modifiche possono migliorare il layout del testo per alcuni caratteri e lingue.

Layout standard per il testo inglese con carattere corsivo. Alcuni dei le lettere sono tagliate. Ecco il codice XML corrispondente:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
Layout per lo stesso testo in inglese con larghezza e spaziatura interna. Ecco il codice XML corrispondente:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
Layout standard per testo tailandese. Alcune lettere sono tagliate. Ecco il codice XML corrispondente:

<TextView
    android:text="คอมพิวเตอร์" />
Layout per lo stesso testo in tailandese con larghezza e spaziatura interna. Ecco il codice XML corrispondente:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Altezza della riga predefinita sensibile alle impostazioni internazionali per EditText

在以前的 Android 版本中，文本布局拉伸了文本的高度，使其适应与当前语言区域匹配的字体的行高。例如，如果内容是日语，由于日语字体的行高比拉丁字体的行高略大，因此文本的高度就略大了。不过，尽管行高存在这些差异，但无论使用何种语言区域，EditText 元素的大小都是一致的，如下图所示：

三个表示 EditText 元素的框，这些框可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 的文本。EditText 的高度相同，即使这两种语言的行高不同。

对于以 Android 15 为目标平台的应用，系统现在会为 EditText 预留最小行高，以匹配指定语言区域的参考字体，如下图所示：

三个表示 EditText 元素的框，这些框可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 的文本。EditText 的高度现在包含空间，可适应这些语言字体的默认行高。

如果需要，您的应用可以通过将 useLocalePreferredLineHeightForMinimum 属性设置为 false 来恢复之前的行为，并且可以通过 Kotlin 和 Java 中的 setMinimumFontMetrics API 设置自定义最小行业指标。

Fotocamera e contenuti multimediali

Android 15 apporta le seguenti modifiche al comportamento della fotocamera e dei contenuti multimediali per le app che hanno come target Android 15 o versioni successive.

Limitazioni relative alla richiesta di focus audio

Le app destinate ad Android 15 devono essere quelle di primo livello o avere un servizio in primo piano per poter richiedere lo stato attivo dell'audio. Se un'app tenta di richiedere lo stato attivo quando non soddisfa uno di questi requisiti, la chiamata restituisce AUDIOFOCUS_REQUEST_FAILED.

Puoi scoprire di più sulla messa a fuoco audio su Gestire il focus audio.

Limitazioni non SDK aggiornate

Android 15 包含更新后的受限非 SDK 列表 基于与 Android 开发者之间的协作以及最新的 内部测试在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 15 为目标平台，其中一些变更可能不会立即对您产生影响。不过，虽然您的应用可以访问一些非 SDK 接口（具体取决于应用的目标 API 级别），但如果您使用任何非 SDK 方法或字段，应用无法运行的风险始终会很高。

如果您不确定自己的应用是否使用了非 SDK 接口，可以 测试您的应用，找出答案。如果您的应用依赖于非 SDK 接口，则应开始计划迁移到 SDK 替代方案。 尽管如此，我们了解到，某些应用具有 非 SDK 接口。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，则应请求新的公共 API。

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