A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Guida all'integrazione della libreria dell'interfaccia utente dell'auto
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Il toolkit per l'interfaccia utente (UI) dell'auto fornisce un framework di sviluppo UI che puoi utilizzare per assicurarti che le app presenti nelle auto (app Google e di sistema e del fornitore) possano raggiungere:
Coerenza dell'UI/UX del sistema di infotainment. L'autoconsistenza è la capacità di un
utente di prevedere come interagire con un sistema di infotainment in base alle esperienze precedenti
di interazione con lo stesso sistema.
Personalizzazione. Gli OEM possono modificare l'aspetto del sistema per integrare al meglio la funzionalità con l'interno e l'hardware del veicolo.
Per scoprire di più sull'integrazione della libreria UI per auto, consulta queste pagine:
Informazioni sulla libreria dell'interfaccia utente dell'auto
La libreria dell'interfaccia utente dell'auto è una libreria collegata in modo statico che fornisce un insieme di componenti e risorse che puoi utilizzare per implementare:
App di sistema e OEM (Gerrit)
App per Android Automotive (AAOS)
Questa libreria funge da:
API di personalizzazione di:
Definire quali risorse possono essere personalizzate, inclusi colori, dimensioni e elementi grafici.
Trattare le risorse come un'API con garanzie di compatibilità con le versioni precedenti.
Livello di compatibilità tra la soluzione a breve termine fornita in Android 9 e Android 10 e la
soluzione a lungo termine attualmente in fase di sviluppo.
Overlay delle risorse
Al momento Android offre diversi modi per applicare le personalizzazioni senza dover apportare modifiche ai sottosistemi e alle app interessati:
Overlay in fase di compilazione. Questa personalizzazione viene applicata al momento della compilazione dell'immagine di sistema Android. Durante la compilazione, tutte le app del sistema ricevono le risorse dalla rispettiva
cartella res e dalle cartelle overlay definite nei file make del target.
Overlay di runtime dinamici (RRO dinamici). Questi APK speciali contengono
solo risorse e un file manifest per indicare quale
APK target interesseranno. Gli RRO dinamici vengono compilati e di cui viene eseguito il deployment indipendentemente dall'immagine di sistema e possono essere attivati e disattivati. Quando il sistema esegue una ricerca di risorse per un'app specifica, controlla anche se è presente qualsiasi RRO che ha come target l'app e se l'RRO contiene una risorsa con lo stesso nome.
Overlay del runtime statici (RRO statici). Simili per struttura alle RRO dinamiche,
sono sempre attive, il che significa che non possono essere disinstallate o aggiornate senza eseguire un
upgrade completo dell'immagine di sistema. Gli RRO statici fungono da intermedi tra gli overlay di compilazione e di runtime dinamici.
Oltre ai componenti dell'interfaccia utente, la libreria UI Car fornisce un meccanismo per sovrapporre direttamente le risorse (collegate in modo statico a ogni app) con le risorse OEM, utilizzando un insieme di RRO statici. Gli OEM devono fornire una cartella contenente gli overlay delle risorse e un elenco di app di destinazione. Durante una compilazione, l'infrastruttura della libreria UI dell'auto utilizza queste informazioni per generare un RRO statico per ogni app scelta come target.
Figura 1. Componenti della libreria dell'interfaccia utente dell'auto
Nell'immagine sopra:
Verde. Personalizzazione fornita dall'OEM, una combinazione di risorse overlay di compilazione e di runtime.
Giallo. Supporto fornito dalla libreria UI dell'auto, tra cui risorse sovrapponibili
, componenti (codice Java) e supporto per la compilazione per generare gli RRO necessari.
Blu. Target personalizzabili, tra cui il framework, le app di sistema, le app del fornitore e le app GAS che utilizzano la libreria dell'interfaccia utente dell'auto per personalizzare gli elementi dell'interfaccia utente.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-27 UTC."],[],[],null,["# Car UI library integration guide\n\nThe Car User Interface (UI) toolkit provides a UI development framework you can use to\nensure apps present in cars (Google apps *and* system and vendor apps) can attain:\n\n- **Infotainment UI/UX self-consistency.** Self-consistency is the ability for a\n user to predict how to interact with an infotainment system based on previous experiences\n interacting with the same system.\n\n- **Customization.**OEMs can modify the look-and-feel of the system to best\n integrate functionality with vehicle interior and hardware.\n\nTo learn more about Car UI Library integration, see these pages:\n\n- [Integrate the Car UI library into apps](/docs/automotive/hmi/car_ui/integrate)\n- [Customize apps](/docs/automotive/hmi/car_ui/customize)\n- [Add custom fonts](/docs/automotive/hmi/car_ui/fonts)\n- [Customize Car UI preferences](/docs/automotive/hmi/car_ui/caruipreference)\n- [CarUiListItem](/docs/automotive/hmi/car_ui/caruilistitem)\n- [Customize CarUiRecyclerView](/docs/automotive/hmi/car_ui/caruirecyclerview)\n- [Troubleshoot runtime resource overlays](/docs/core/runtime/rro-troubleshoot)\n- [Release notes](/docs/automotive/hmi/car_ui/release_notes)\n- [Appendix A, work with RROs](/docs/automotive/hmi/car_ui/appendix)\n- [Appendix B, customization guidelines](/docs/automotive/hmi/car_ui/appendix_b)\n\nAbout the Car UI library\n------------------------\n\nThe Car UI library is a statically linked library, which provides a set of components and\nresources you can use to implement:\n\n- System and OEM apps (Gerrit)\n- Android Automotive (AAOS) apps\n\nThis library serves as a:\n\n- Customization API by:\n\n - Defining which resources can be customized including, colors, dimensions, and drawables.\n - Treating the resources as an API with backwards-compatible guarantees.\n- Compatibility layer between the short-term provided in Android 9 and Android 10 and the longer term solution currently being developed.\n\nResource overlays\n-----------------\n\nAndroid currently provides several ways to apply customizations without additional work needed to\nthe affected subsystems and apps:\n\n- **Build-time overlays.** This customization is applied at Android system image\n build time. During the build, all apps in the system receive resources from their\n `res` folder and from `overlay` folders defined in the target\n makefiles.\n\n- **Dynamic runtime overlays (dynamic RRO).** These special APKs contain\n *only* resources and a manifest file to indicate which *target APK* they will\n affect. Dynamic RROs are compiled and deployed independently of the system image and can be\n toggled on and off. When the system performs a resource lookup for a specific app, the\n system also checks for *any* RRO targeting it and if the RRO contains a resource with the\n same name.\n\n- **Static runtime overlays (static RRO).** Similar to dynamic RROs in structure,\n these are always *on*, meaning they can't be uninstalled or updated without performing a\n full system image upgrade. Static RROs serve as an intermediate of build-time and dynamic\n runtime overlays.\n\nIn addition to UI components, the Car UI library provides a mechanism to directly overlay\nresources (statically linked into each app) with the OEM resources, using a *set of static\nRROs*. OEMs must provide a folder containing their resource overlays and a list of targeted\napps. During a build, the Car UI library infrastructure would use this information to\ngenerate one static RRO for each targeted app.\n| **Note:** This mechanism will become obsolete in Android 11 (and higher) when RROs can target Android libraries.\n\n**Figure 1**. Car UI library components\n\nIn the image above:\n\n- **Green**. Customization provided by the OEM, a mix of build-time and run-time\n overlay resources.\n\n- **Yellow.** Support provided by Car UI library, including *overlayable*resources, components (Java code) and build support to generate the necessary RROs.\n\n- **Blue.** *Customizable* targets including the framework, system\n apps, vendor apps and GAS apps that use the Car UI library to\n *customize* UI elements."]]