Supporto per le decorazioni del sistema

Gli aggiornamenti apportati a queste aree specifiche della visualizzazione sono riportati di seguito:

Decorazioni del sistema

Android 10 aggiunge il supporto per la configurazione secondaria display per mostrare alcune decorazioni del sistema, come sfondo, barra di navigazione e Avvio app. Per impostazione predefinita, il display principale mostra tutte le decorazioni del sistema e i display secondari mostrano quelli attivati facoltativi. Supporto per un editor del metodo di input (IME) può essere impostato separatamente dalle altre decorazioni del sistema.

Usa DisplayWindowSettings#setShouldShowSystemDecorsLocked() per aggiungere il supporto per le decorazioni del sistema su un display specifico o fornire un valore predefinito in /data/system/display_settings.xml. Ad esempio: consulta Impostazioni della finestra di visualizzazione.

Implementazione

DisplayWindowSettings#setShouldShowSystemDecorsLocked() è esposto anche in WindowManager#setShouldShowSystemDecors() per i test. Attivazione di questo metodo con l'intento di abilitare decorazioni del sistema, non vengono aggiunte finestre di decorazione che sono in precedenza mancanti o rimuoverli se erano presenti in precedenza. Nella maggior parte dei casi, casi, la modifica del supporto delle decorazioni del sistema diventa pienamente effettiva solo dopo riavvio dispositivo.

Verifica il supporto delle decorazioni del sistema nel codebase WindowManager in genere percorre DisplayContent#supportsSystemDecorations(), mentre verifica la presenza di servizi esterni (come l'UI di sistema per controllare se la barra di navigazione) devono essere mostrati) utilizza WindowManager#shouldShowSystemDecors(). Per capire cosa è controllato da questa impostazione, esplora i punti di contatto questi metodi.

Finestre di arredamento dell'interfaccia utente di sistema

Android 10 aggiunge il supporto per l'arredamento del sistema per le finestre solo per la barra di navigazione, perché è essenziale per navigare tra attività e app. Per impostazione predefinita, la barra di navigazione mostra Inviti per il rientro a casa. Viene incluso solo se il display di destinazione supporta decorazioni del sistema (vedi DisplayWindowSettings).

La barra di stato è una finestra di sistema più complicata contiene anche l'area notifiche, le Impostazioni rapide e la schermata di blocco. Su Android 10, la barra di stato non è supportata sui display secondari. Pertanto, le notifiche, le impostazioni e un blocco tastiera completo sono disponibili solo display principale.

La finestra di sistema Panoramica/Recenti non è supportata su schermate. In Android 10, AOSP mostra la sezione Recenti visualizzazione predefinita e contiene le attività di tutte le visualizzazioni. Se avviato da Di recente, un'attività che era su un display secondario viene mostrata in primo piano su che vengono visualizzate per impostazione predefinita. Questo approccio presenta alcuni problemi noti, tra cui la aggiornate immediatamente quando le app vengono visualizzate su altre schermate.

Implementazione

Per implementare funzionalità aggiuntive dell'interfaccia utente di sistema, i produttori di dispositivi devono utilizzare una singolo componente dell'interfaccia utente di sistema che rimane in ascolto dell'aggiunta/rimozione di display e presenti contenuti appropriati.

Un componente dell'interfaccia utente di sistema che supporta l'opzione Multi-Display (MD) deve gestire i seguenti casi:

  • Inizializzazione di più display all'avvio
  • Display aggiunto in fase di esecuzione
  • Display rimosso in fase di esecuzione

Quando l'UI di sistema rileva l'aggiunta di una visualizzazione prima di WindowManager, crea una gara. Per evitare questo problema, puoi implementare un callback personalizzato WindowManager all'interfaccia utente di sistema quando viene aggiunta una visualizzazione anziché effettuare l'iscrizione Eventi DisplayManager.DisplayListener. Per un'implementazione di riferimento, vedi CommandQueue.Callbacks#onDisplayReady per il supporto della barra di navigazione e WallpaperManagerInternal#onDisplayReady per gli sfondi.

Inoltre, Android 10 offre i seguenti aggiornamenti:

  • La classe NavigationBarController controlla tutte le funzionalità specifiche per le barre di navigazione.
  • Per visualizzare una barra di navigazione personalizzata, consulta CarStatusBar.
  • TYPE_NAVIGATION_BAR non è più limitato a una singola e può essere utilizzato per ogni visualizzazione.
  • IWindowManager#hasNavigationBar() è stato aggiornato per includere Parametro displayId solo per l'UI di sistema.

Avvio app

In Android 10, ogni display configurato per il supporto le decorazioni del sistema hanno uno stack della casa dedicato per le attività di avvio applicazioni con WindowConfiguration#ACTIVITY_TYPE_HOME, per impostazione predefinita. Ogni display utilizza un'istanza separata dell'attività in Avvio applicazioni.

Figura 1. Esempio di Avvio app multi-display per platform/development/samples/MultiDisplay

La maggior parte degli launcher esistenti non supporta più istanze e non è ottimizzata per schermi di grandi dimensioni. Inoltre, spesso ci si aspetta un tipo di esperienza diverso su display secondari/esterni. Per offrire un'attività dedicata ai schermate, Android 10 introduce la categoria SECONDARY_HOME nell'intent filtri corretti. Le istanze di questa attività vengono usate su tutti i display che supportano il sistema decorazioni, una per display. 

<activity>
    ...
    <intent-filter>
        <category android:name="android.intent.category.SECONDARY_HOME" />
        ...
    </intent-filter>
</activity>

L'attività deve avere una modalità di avvio che non impedisca e si adatti alle diverse dimensioni degli schermi. Modalità di avvio non può essere singleInstance o singleTask.

Implementazione

In Android 10, RootActivityContainer#startHomeOnDisplay() seleziona automaticamente il componente e l'intent desiderati a seconda del tipo da cui viene avviata la schermata Home. RootActivityContainer#resolveSecondaryHomeActivity() contiene la logica per cercare il componente Attività Avvio app a seconda del tipo ha selezionato Avvio app e può usare l'impostazione predefinita di sistema, se necessario (vedi ActivityTaskManagerService#getSecondaryHomeIntent()).

Limitazioni di sicurezza

Oltre alle limitazioni che si applicano alle attività su display secondari, per evitare la possibilità che un'app dannosa crei un display virtuale con Decorazioni del sistema e leggendo dalla piattaforma informazioni sensibili, Avvio app appare solo su display virtuali di proprietà del sistema. In Avvio applicazioni non vengono visualizzati contenuti su display virtuali non di sistema.

Sfondi

In Android 10 (e versioni successive) sono supportati gli sfondi sui display secondari:

Figura 2. Sfondo animato per elementi interni (sopra) ed esterni visualizza (sotto)

Gli sviluppatori possono dichiarare il supporto della funzionalità sfondo fornendo android:supportsMultipleDisplays="true" in Definizione XML WallpaperInfo. Inoltre, gli sviluppatori di sfondi si prevede che caricherà gli asset utilizzando il contesto di visualizzazione WallpaperService.Engine#getDisplayContext().

Il framework crea un'istanza WallpaperService.Engine per display, in modo che ogni motore abbia una piattaforma e un contesto di visualizzazione specifici. La sviluppatore deve assicurarsi che ogni motore possa disegnare in modo indipendente, diverse frequenze fotogrammi, rispettando VSYNC.

Selezionare gli sfondi per le singole schermate

Android 10 non offre un supporto diretto della piattaforma per la selezione degli sfondi per i singoli schermi. A questo scopo, viene usato un identificatore display stabile necessarie per mantenere le impostazioni dello sfondo per ogni display. Display#getDisplayId() è dinamico, quindi non c'è garanzia che un il display fisico avrà lo stesso ID dopo il riavvio.

Tuttavia, Android 10 ha aggiunto DisplayInfo.mAddress, che contiene identificatori stabili per i display fisici e può essere utilizzato per un implementazione in futuro. Purtroppo è troppo tardi per implementare la logica per Android 10. La soluzione suggerita:

  1. Utilizza l'API WallpaperManager per impostare gli sfondi.
  2. WallpaperManager è ottenuto da un Context e ogni oggetto Context contiene informazioni sull'oggetto display (Context#getDisplay()/getDisplayId()). Pertanto, puoi ottieni displayId da un'istanza WallpaperManager senza aggiungere nuovi metodi.
  3. Sul lato del framework, usa displayId ottenuto da un Context e mappalo a un identificatore statico (come una porta di un display fisico). Utilizza l'identificatore statico per mantenere lo sfondo scelto.

Questa soluzione alternativa utilizza le implementazioni esistenti per i selettori di sfondi. Se è stata aperta su un display specifico e usa il giusto contesto, per impostare uno sfondo, il sistema può identificare automaticamente il display.

Se serve impostare lo sfondo per un display diverso da quello attuale display, quindi crea un nuovo oggetto Context per la visualizzazione target (Context#createDisplayContext) e ottieni WallpaperManager istanza da quel display.

Limitazioni di sicurezza

Il sistema non mostrerà sfondi virtuali che non sono di sua proprietà. Ciò è dovuto a un problema di sicurezza secondo cui un'app dannosa potrebbe creare un'istanza display con le decorazioni di sistema attive supporta e legge una risposta informazioni dalla piattaforma (come una foto personale).

Implementazione

In Android 10, IWallpaperConnection#attachEngine() e IWallpaperService#attach() accettano i displayId per creare connessioni per display. WallpaperManagerService.DisplayConnector incapsula un singolo display motore dello sfondo e connessione. In WindowManager, i controller dello sfondo vengono creato per ogni oggetto DisplayContent in fase di costruzione, invece di una WallpaperController singolo per tutti i display.

Alcune implementazioni pubbliche del metodo WallpaperManager (ad esempio WallpaperManager#getDesiredMinimumWidth()) sono stati aggiornati per eseguire il calcolo e fornire informazioni per i display corrispondenti. WallpaperInfo#supportsMultipleDisplays() e un valore corrispondente è stato aggiunto l'attributo resource, in modo che gli sviluppatori di app possano segnalare sono pronti per più schermi.

Se il servizio di sfondi mostrato sul display predefinito non supporta più display, il sistema mostra lo sfondo predefinito sui vengono visualizzati i video.

Figura 3. Logica di fallback dello sfondo per i display secondari