Android è il sistema operativo che trovi su gran parte degli smartphone non Apple, ma definirlo semplicemente “il software del telefono” lascia fuori il punto più importante. La piattaforma è composta da più livelli: codice open source, servizi di sistema, runtime per le app, componenti hardware, personalizzazioni dei produttori e, su molti dispositivi, app e servizi Google aggiunti separatamente.
Capire questa struttura spiega perché un Samsung Galaxy, un Google Pixel e uno smartphone Xiaomi possono usare la stessa piattaforma e allo stesso tempo apparire molto diversi. Spiega anche perché Google Play non è sinonimo del sistema operativo, perché gli aggiornamenti non arrivano a tutti nello stesso momento e perché la release installata non coincide con la patch di sicurezza o con l’aggiornamento di sistema Google Play.
In questa guida partiamo quindi da cos’è Android e arriviamo a come funziona davvero, quali componenti lo formano, dove viene utilizzato, come si aggiorna e quali differenze contano quando lo confronti con iOS.
Cos’è Android e cosa significa davvero
Android è una piattaforma software open source progettata per dispositivi di form factor differenti. Nel linguaggio comune lo chiamiamo “sistema operativo Android”, ed è corretto, ma tecnicamente comprende uno stack più ampio del solo nucleo: framework, servizi, runtime, librerie, livello di astrazione hardware e kernel lavorano insieme per permettere alle app di utilizzare display, memoria, fotocamera, rete, sensori e altre risorse del dispositivo.
La documentazione dell’Android Open Source Project descrive proprio questa architettura a livelli. È un dettaglio utile perché evita un equivoco frequente: parliamo di una piattaforma software, non di una singola app o della marca dello smartphone.
Android è un sistema operativo, non una marca di smartphone
Un telefono basato su Android può essere prodotto da Google, Samsung, Xiaomi, Motorola, Nothing, Honor e molti altri marchi. Il sistema operativo fornisce una base comune, mentre il produttore sceglie hardware, interfaccia, applicazioni preinstallate, servizi aggiuntivi e politica di aggiornamento.
Per questo dire “ho un Android” identifica soprattutto la piattaforma software, non un modello preciso. Due dispositivi con la stessa release possono differire molto per funzioni disponibili, grafica, fotocamera, gestione energetica e perfino posizione delle impostazioni.
È anche il motivo per cui non conviene usare “Android” e “Google Pixel” come sinonimi. I Pixel sono dispositivi Google con servizi e funzionalità proprie, mentre la piattaforma è utilizzata da un ecosistema molto più ampio di produttori.
Android, AOSP e Google non sono la stessa cosa
Il cuore aperto della piattaforma è AOSP, Android Open Source Project. Il codice AOSP è disponibile pubblicamente e può essere modificato per creare un sistema destinato a un dispositivo specifico. Google guida il progetto, mentre produttori e altre aziende contribuiscono all’ecosistema e possono adattare la piattaforma ai propri prodotti.
Questa distinzione è fondamentale: Android non coincide con l’insieme delle app Google. AOSP fornisce una piattaforma funzionante, ma non include automaticamente Gmail, YouTube, Google Maps, Google Play Store o tutti i servizi cloud che normalmente associ a uno smartphone commerciale.
In altre parole, il rapporto corretto è più vicino a questo:
AOSP → base della piattaforma → personalizzazione del produttore → eventuali servizi e app Google
Google Mobile Services e Play Store: cosa viene aggiunto ad AOSP
Sui dispositivi commerciali certificati trovi spesso i Google Mobile Services (GMS), una raccolta di applicazioni e API Google concessa in licenza separatamente. Google specifica nella pagina dedicata ai Google Mobile Services che GMS non fa parte di AOSP.
Questo chiarisce anche perché Google Play Store non è il sistema operativo. È uno dei servizi che possono essere presenti su un dispositivo compatibile e certificato, ma la piattaforma open source non dipende concettualmente dal Play Store per esistere.
La distinzione può sembrare teorica finché non incontri un dispositivo basato su AOSP senza i servizi Google, oppure un produttore che sostituisce parte delle app standard con soluzioni proprie. A quel punto diventa evidente che piattaforma open source ed ecosistema Google descrivono livelli collegati ma diversi.
Come nasce Android: dalla startup alla piattaforma di Google
Il progetto nasce fuori da Google, all’interno di Android Inc. Google acquisisce la società nel 2005 e negli anni successivi ne fa il nucleo di una piattaforma mobile aperta sviluppata insieme all’ecosistema riunito attorno alla Open Handset Alliance.
L’AOSP descrive la propria governance come un progetto guidato da Google ma costruito per permettere a più aziende di collaborare su un’implementazione comune, mantenendo la possibilità di adattarla ai propri dispositivi.
Android Inc., Google e Open Handset Alliance
Il passaggio decisivo non è stato soltanto creare un sistema operativo per smartphone. Il modello scelto ha separato il più possibile la piattaforma di base dall’hardware di un singolo produttore, consentendo a molte aziende di costruire dispositivi differenti sopra una base software condivisa.
Con la nascita della Open Handset Alliance, annunciata nel 2007, il progetto diventa quindi un ecosistema. Google mantiene un ruolo centrale nello sviluppo, ma il successo della piattaforma dipende anche da produttori di dispositivi, aziende di semiconduttori, operatori, sviluppatori di app e fornitori di componenti.
Dal primo HTC Dream all’ecosistema attuale
I primi dispositivi commerciali basati su Android arrivano nel 2008. Da quel punto il sistema si allontana rapidamente dall’idea di “software per un solo tipo di telefono”: cresce il numero di produttori, cambiano dimensioni e form factor, aumentano le API disponibili e la piattaforma viene adattata a categorie di dispositivo molto diverse.
Questa storia spiega una caratteristica che ancora oggi definisce la piattaforma: è contemporaneamente una base comune e un sistema progettato per essere adattato. È un vantaggio quando vuoi scelta e varietà; diventa una complessità quando devi gestire compatibilità e aggiornamenti su hardware differenti.
Come funziona Android: dalle app all’hardware
Per capire come funziona Android conviene evitare l’idea di un unico blocco software. Quando tocchi un pulsante in un’app, quella semplice azione può attraversare diversi livelli prima di produrre un risultato sul display, accedere alla fotocamera o comunicare con un sensore.
La struttura completa è molto più articolata, ma il modello mentale utile è questo:
app → framework e servizi di sistema → runtime/librerie → HAL → kernel → hardware
Ogni livello riduce la quantità di dettagli che quello superiore deve conoscere. Un’app non deve sapere come è implementato il driver di ogni fotocamera esistente: utilizza le API offerte dalla piattaforma, mentre i livelli inferiori gestiscono la comunicazione con l’hardware concreto.
App, framework e servizi di sistema
Le app utilizzano le API del framework per accedere alle funzionalità del sistema. Quando un’app deve mostrare una notifica, utilizzare la posizione, aprire la fotocamera o salvare un file, non comunica normalmente con l’hardware in modo diretto: passa attraverso interfacce e servizi messi a disposizione dalla piattaforma.
I servizi di sistema svolgono funzioni specializzate e fanno da ponte tra le API visibili alle applicazioni e i componenti più bassi dello stack. È uno dei motivi per cui Android può applicare un modello centralizzato di permessi, lifecycle e gestione delle risorse invece di lasciare ogni app libera di controllare il dispositivo senza mediazione.
Android Runtime, librerie native e HAL
Un componente importante dello stack è ART, Android Runtime. ART esegue il codice delle app e gestisce aspetti come compilazione ed esecuzione del bytecode, memoria e garbage collection. Il modello attuale è molto diverso dalle descrizioni storiche basate principalmente su Dalvik: continuare a presentare Dalvik come runtime corrente significa spiegare una piattaforma che non esiste più in quella forma.
Sotto il runtime trovi librerie e daemon nativi che svolgono funzioni di basso livello. Più vicino all’hardware entra in gioco l’Hardware Abstraction Layer (HAL), che definisce interfacce standard attraverso le quali il framework può utilizzare implementazioni specifiche dei produttori.
Il vantaggio è pratico. Il sistema può richiedere l’accesso a una funzione hardware attraverso un’interfaccia prevista dalla piattaforma senza incorporare nel framework ogni dettaglio del componente montato su ogni singolo telefono.
Il kernel Linux e il rapporto con l’hardware
Alla base dello stack c’è il kernel Linux. Il kernel gestisce funzioni fondamentali come processi, memoria, sicurezza, networking e comunicazione con l’hardware. Se vuoi approfondire questo livello, nella guida dedicata trovi cos’è un kernel e come gestisce le risorse del sistema.
Dire che Android utilizza Linux non significa però che sia una normale distribuzione GNU/Linux per smartphone. Sopra il kernel costruisce un proprio user space, un proprio framework applicativo, propri servizi di sistema e un modello specifico per app e compatibilità hardware.
Anche il kernel moderno è più complesso del vecchio schema “Android usa Linux 2.6” che compare ancora in molte guide. La piattaforma utilizza Android Common Kernels e, sulle generazioni recenti, il modello Generic Kernel Image per ridurre la frammentazione fra parti generiche e componenti specifici del produttore.
Perché Android cambia tra Samsung, Pixel, Xiaomi e altri produttori
Una delle domande più utili per capire la piattaforma è questa: se il sistema operativo è lo stesso, perché un Pixel e un Galaxy possono sembrare due prodotti diversi?
La risposta è che esiste una piattaforma comune, non un’interfaccia identica obbligatoria per ogni dispositivo.
AOSP, produttori e compatibilità Android
Un produttore può partire dalla base AOSP e adattarla al proprio hardware. Per partecipare pienamente all’ecosistema compatibile deve però rispettare requisiti tecnici e superare test di compatibilità previsti dalla piattaforma.
Questo equilibrio serve a consentire personalizzazione senza trasformare ogni telefono in un sistema completamente incompatibile con gli altri. Se un’app utilizza API Android standard e rispetta i requisiti previsti, dovrebbe poter funzionare su dispositivi molto diversi senza che lo sviluppatore debba riscriverla da zero per ogni marchio.
Interfacce e personalizzazioni del produttore
Sopra la base comune, i produttori aggiungono il proprio livello di esperienza. Cambiano launcher, icone, menu, app di sistema, funzioni della fotocamera, strumenti di produttività, gestione energetica e integrazioni con altri dispositivi del marchio.
È qui che nascono interfacce come One UI sui Samsung Galaxy o le personalizzazioni adottate da altri OEM. Non sono sistemi operativi completamente separati da Android: sono implementazioni e interfacce costruite sopra la piattaforma, con componenti e servizi propri.
Perché due telefoni con la stessa versione Android possono essere diversi
Il numero di versione ti dice quale generazione della piattaforma è installata, ma non descrive da solo l’esperienza completa del dispositivo.
Contano anche la versione dell’interfaccia del produttore, le patch installate, i componenti aggiornabili, l’hardware disponibile e le funzioni abilitate dal vendor. Perfino la posizione di una voce nelle Impostazioni può cambiare da un marchio all’altro.
Per questo una guida che dice “vai esattamente in questo menu su Android” senza specificare il dispositivo rischia di essere troppo categorica. Le procedure di base sono simili, ma il percorso concreto può variare.
Dove viene utilizzato Android oltre agli smartphone
Android è conosciuto soprattutto per gli smartphone, ma la piattaforma e i suoi componenti vengono adattati a più categorie di dispositivi. Non significa che ogni form factor esegua esattamente la stessa interfaccia del telefono: la base Android viene specializzata in funzione dell’hardware e del contesto d’uso.
Tablet, pieghevoli e altri form factor
Tablet e dispositivi pieghevoli usano la piattaforma Android con interfacce pensate per schermi più grandi, multitasking e layout adattivi. Il punto importante non è soltanto “avere uno schermo più grande”: le applicazioni devono reagire correttamente a dimensioni, orientamenti e modalità finestra differenti.
Questo aspetto è diventato sempre più centrale nello sviluppo Android. Un’app progettata come se ogni dispositivo fosse un telefono verticale di dimensioni fisse rischia di funzionare male su tablet, foldable e ambienti desktop-like.
TV, auto e dispositivi indossabili: cosa appartiene davvero all’ecosistema Android
L’ecosistema comprende anche Android TV OS, Wear OS e Android Automotive OS. Sono piattaforme specializzate che condividono componenti e principi della base comune ma introducono vincoli e interfacce adatte al dispositivo.
Nel settore automotive serve anche una distinzione importante: Android Auto e Android Automotive OS non sono la stessa cosa. Il primo utilizza lo smartphone per portare un’esperienza compatibile sul display dell’auto; il secondo è un sistema basato sulla piattaforma integrato direttamente nel veicolo e può eseguire app installate sull’auto.
Questa varietà è una delle ragioni per cui parlare oggi della piattaforma come semplice “sistema operativo per telefoni” è riduttivo.
Versioni Android: qual è l’ultima e cosa significa avere Android 17
La release stabile corrente della piattaforma è Android 17. Google l’ha resa disponibile inizialmente sulla maggior parte dei Pixel supportati e ha pubblicato nello stesso momento il relativo codice nell’Android Open Source Project. La pagina ufficiale di rilascio resta il riferimento più affidabile per verificare lo stato della release.
Questo non significa che ogni smartphone debba già avere Android 17. Il percorso di aggiornamento dipende dal modello, dal produttore e, in alcuni casi, dall’operatore.
Android 17 è la release stabile corrente
Quando Google pubblica una nuova versione, la piattaforma entra in una nuova generazione di API e comportamenti. I produttori devono poi integrarla con driver, interfaccia, servizi e test relativi ai propri dispositivi prima di distribuirla.
Per l’utente la conseguenza è semplice: “ultima versione della piattaforma” e “ultima versione disponibile per il mio telefono” non sono sempre la stessa cosa.
Un dispositivo può essere ancora pienamente supportato e ricevere patch importanti pur non avendo ricevuto immediatamente la release maggiore più recente.
Numero di versione, build e patch di sicurezza non sono la stessa cosa
Nelle impostazioni del dispositivo puoi trovare più numeri e date che descrivono livelli diversi del software.
La versione Android indica la release principale della piattaforma. Il numero build identifica più precisamente la compilazione software installata dal produttore. L’aggiornamento della sicurezza indica invece il livello delle patch di sicurezza applicate. A questi si aggiunge lo stato dell’aggiornamento di sistema Google Play, che riguarda componenti aggiornabili attraverso un canale distinto.
Questa separazione è importante: uno smartphone non diventa automaticamente “non aggiornato” soltanto perché non cambia spesso il numero della release Android.
Come funzionano gli aggiornamenti Android
Gli aggiornamenti del sistema non sono un unico pacchetto con una sola origine. Esistono almeno tre livelli che per l’utente possono sembrare simili ma svolgono funzioni differenti: aggiornamenti del sistema operativo distribuiti dal produttore, patch di sicurezza e aggiornamenti di componenti modulari del sistema.
Aggiornamenti del sistema operativo e OTA del produttore
L’aggiornamento principale viene normalmente adattato e distribuito dal produttore del dispositivo tramite OTA, cioè over the air. L’update può includere la nuova release della piattaforma insieme a modifiche dell’interfaccia, driver, firmware e componenti specifici del modello.
È qui che nasce gran parte della differenza nei tempi di distribuzione. Google può pubblicare una release, ma ogni produttore deve gestire il proprio portafoglio di dispositivi e la propria pipeline di test.
La durata del supporto è quindi una caratteristica concreta da valutare quando acquisti uno smartphone: due modelli con hardware simile possono ricevere politiche di aggiornamento molto diverse.
Patch di sicurezza
Le patch di sicurezza correggono vulnerabilità senza richiedere necessariamente una nuova major release di Android. Il livello patch che trovi nelle impostazioni serve proprio a capire fino a quale aggiornamento di sicurezza è arrivato il dispositivo.
Per questo guardare soltanto il numero della major release non basta per valutare lo stato software di un telefono. Un dispositivo con la stessa major release può avere un livello patch più recente o più vecchio rispetto a un altro.
Google Play system update e Android Mainline
A partire da Android 10, il progetto Mainline ha reso modulari alcuni componenti, permettendo di aggiornarli al di fuori del normale ciclo della release principale. La documentazione ufficiale su Mainline spiega che questi moduli possono essere distribuiti attraverso l’aggiornamento di sistema Google Play oppure tramite un meccanismo OTA del partner.
È un cambiamento strutturale importante perché riduce la dipendenza da un unico aggiornamento monolitico per correggere o migliorare determinati componenti.
Non significa che Google possa aggiornare da sola ogni parte di qualunque smartphone. Driver, firmware, interfaccia del produttore e molte altre componenti restano fuori da questo meccanismo. Significa però che una parte del sistema è diventata più modulare di quanto suggerisca il vecchio modello “nuova versione Android una volta, poi solo patch”.
Come controllare versione e aggiornamenti sul proprio dispositivo
Google indica nella guida ufficiale agli aggiornamenti che le informazioni principali si trovano nelle Impostazioni del dispositivo, nella sezione relativa alle informazioni sul telefono o tablet e agli aggiornamenti software.
I nomi esatti dei menu possono cambiare in base al produttore. In generale, cerca le voci relative a Versione Android, Aggiornamento della sicurezza Android, Aggiornamento di sistema Google Play e Numero build.
Se il dispositivo non propone una nuova major release non conviene forzare firmware trovati casualmente online. Prima verifica il supporto ufficiale del modello: installare immagini non previste dal produttore può comportare perdita di dati, problemi di compatibilità o procedure di ripristino non banali.
App Android, Google Play e APK: cosa succede quando installi un’app
Una piattaforma mobile vive soprattutto attraverso le sue applicazioni, ma anche qui è utile separare Android da Google Play.
Le app interagiscono con il sistema attraverso le API della piattaforma e vengono eseguite in un ambiente controllato che applica isolamento, permessi e regole di lifecycle. Fotocamera, microfono, posizione e altri dati sensibili non dovrebbero essere accessibili liberamente senza passare dal modello di autorizzazione previsto dal sistema.
Play Store non è sinonimo di Android
Google Play è il canale di distribuzione più diffuso sui dispositivi con GMS, ma non è l’unico modo tecnicamente possibile per distribuire applicazioni Android.
AOSP stesso documenta la piattaforma separatamente dai servizi Google. Il Play Store aggiunge un ecosistema di distribuzione, aggiornamenti, firma, pagamenti, protezione e servizi collegati, ma non definisce da solo la piattaforma.
Questa distinzione diventa particolarmente importante quando valuti dispositivi senza GMS, store alternativi o installazioni manuali.
APK, AAB, installazione e permessi
L’APK è il formato installabile ed eseguibile di un’app. Un Android App Bundle (AAB) è invece un formato di pubblicazione: non viene installato direttamente sul dispositivo, ma viene elaborato dal distributore per generare gli APK necessari alla configurazione dell’utente. La documentazione ufficiale su AAB e APK chiarisce esplicitamente questa differenza.
Quando installi un’app dal Play Store, quindi, non devi necessariamente ricevere un unico APK identico a quello di ogni altro dispositivo. Google Play può generare pacchetti ottimizzati per architettura, lingua, densità dello schermo e altre caratteristiche.
Una volta installata, l’app resta sottoposta al modello di sicurezza della piattaforma. I permessi servono a controllare l’accesso a risorse sensibili e le versioni moderne di Android hanno progressivamente aumentato la granularità di queste autorizzazioni.
Chi sviluppa le app Android e quali strumenti usa
Lo sviluppo applicativo è un livello distinto dal funzionamento del sistema operativo. Oggi il percorso nativo ruota soprattutto attorno a Kotlin, Android Studio, SDK e Jetpack Compose, insieme a testing, architettura, sicurezza e distribuzione.
Se vuoi passare dalla comprensione della piattaforma alla creazione di software, la guida dedicata all’Android Developer approfondisce proprio strumenti, competenze e percorso per sviluppare app moderne.
È meglio tenere separati i due intenti: qui stiamo spiegando come funziona Android come piattaforma; nella guida per sviluppatori il problema diventa come costruire correttamente un’app per quella piattaforma.
Android vs iOS: le differenze che contano davvero
Android e iOS risolvono lo stesso problema generale — offrire una piattaforma moderna per smartphone e altri dispositivi mobili — ma lo fanno con modelli industriali differenti.
| Aspetto | Android | iOS |
|---|---|---|
| Hardware | molti produttori e fasce di prezzo | dispositivi Apple |
| Base della piattaforma | AOSP open source + componenti e servizi aggiuntivi | piattaforma proprietaria Apple |
| Personalizzazione del produttore | ampia e variabile tra OEM | controllata direttamente da Apple |
| Aggiornamenti | tempi e durata dipendono anche dal produttore e dal modello | distribuzione centralizzata da Apple sui dispositivi supportati |
| Store e distribuzione | Google Play è centrale sui dispositivi GMS, ma Android supporta anche altri canali | ecosistema più controllato, con modalità di distribuzione definite da Apple e variabili anche in base alla regione |
| Varietà dei dispositivi | molto ampia | gamma più circoscritta e integrata |
Dispositivi, personalizzazione ed ecosistema
Se vuoi molta scelta su prezzo, formato, hardware e interfaccia, la piattaforma offre un ventaglio molto più ampio. Puoi trovare dispositivi economici, top di gamma, pieghevoli, gaming phone e modelli con priorità molto diverse.
Questa varietà significa però che l’esperienza non è identica su tutti i marchi. Chi passa da un Pixel a un Galaxy può ritrovare le stesse fondamenta ma abitudini, menu e servizi differenti.
iOS segue il modello opposto: Apple controlla sia il sistema operativo sia l’hardware principale sul quale viene eseguito. Il risultato è una maggiore uniformità, ma una scelta più limitata di produttori e personalizzazioni profonde.
Aggiornamenti e controllo della piattaforma
La differenza di struttura incide direttamente sugli update. Apple gestisce il ciclo software dei propri dispositivi. Nell’ecosistema, Google sviluppa la piattaforma e diversi componenti, mentre il produttore del dispositivo gestisce un’altra parte essenziale dell’integrazione e della distribuzione.
Non significa che la piattaforma sia necessariamente “peggiore negli aggiornamenti”. Alcuni produttori offrono oggi finestre di supporto molto lunghe. Significa che la politica di update va verificata modello per modello, invece di dedurla dal solo nome Android.
Quale scegliere in base allo scenario
Sceglierei Android se per te contano soprattutto varietà di hardware, possibilità di scegliere tra produttori diversi, maggiore libertà di personalizzazione e accesso a fasce di prezzo molto ampie.
Sceglierei iPhone e iOS se preferisci un ecosistema hardware-software più uniforme, vuoi rimanere dentro prodotti Apple già utilizzati oppure consideri prioritaria la coerenza dell’esperienza fra modelli supportati.
La scelta non dipende quindi da quale sistema sia “migliore in assoluto”, ma da quanto controllo vuoi avere sulla scelta del dispositivo e quanto valore attribuisci all’integrazione di un ecosistema più chiuso.
Vantaggi e limiti di Android
Il vantaggio principale e il suo limite più evidente derivano dalla stessa scelta architetturale: permettere a molti produttori di costruire sopra una piattaforma comune.
Dove la flessibilità è un vantaggio reale
La flessibilità permette di scegliere fra hardware molto diversi senza rinunciare allo stesso ecosistema applicativo di base. Un produttore può differenziarsi su fotocamera, display, form factor, funzioni software, accessori e integrazione con altri dispositivi.
Per l’utente questo crea concorrenza e possibilità di scelta. Per gli sviluppatori significa poter raggiungere una grande varietà di dispositivi utilizzando API e strumenti comuni invece di creare un sistema completamente diverso per ogni marca.
È anche una delle ragioni per cui la piattaforma ha potuto espandersi oltre lo smartphone e adattarsi a tablet, TV, auto, wearable e nuovi form factor.
Frammentazione, aggiornamenti e differenze tra produttori
La stessa apertura rende più complessa la compatibilità. Versioni diverse, personalizzazioni OEM, dimensioni dello schermo, capacità hardware e politiche di aggiornamento obbligano produttori e sviluppatori a testare più combinazioni.
“Frammentazione” non significa però che ogni dispositivo sia incompatibile con gli altri. Il progetto mantiene regole, API e test di compatibilità proprio per creare una base comune. Il problema reale è il numero di variabili che devono convivere sopra quella base.
Per l’utente il criterio pratico è semplice: quando scegli uno smartphone non guardare soltanto processore, memoria e fotocamera. Controlla anche durata del supporto software, frequenza delle patch e qualità dell’interfaccia del produttore. Sono parte del prodotto quanto l’hardware.
Conclusione
Android è molto più di “il sistema degli smartphone Samsung” o “il software di Google”. È una piattaforma a livelli: AOSP fornisce la base open source, il framework e i servizi collegano le app alle funzioni del sistema, ART esegue le applicazioni, HAL e kernel gestiscono il rapporto con l’hardware, mentre produttori e servizi Google aggiungono ulteriori livelli all’esperienza finale.
Capire questa separazione risolve quasi tutti gli equivoci più comuni. Google Play non coincide con il sistema operativo; Pixel non coincide con AOSP; avere la stessa release non rende due telefoni identici; una patch di sicurezza non è la stessa cosa di una major release; Android Auto non è Android Automotive OS.
Se devi scegliere un telefono, guarda quindi la piattaforma insieme al produttore che lo implementa e alla sua politica di supporto. Se invece vuoi capire cosa succede sotto l’interfaccia, il passaggio chiave è ricordare lo stack: app → framework → runtime e servizi → HAL → kernel → hardware. È lì che Android smette di essere soltanto un nome sulla confezione e diventa comprensibile come sistema operativo.