In questo articolo esploriamo la verità sul motivo per cui i dispositivi Snapdragon 801 non ricevono Android Nougat. Dai produttori di chipset ai venditori, i problemi sono molti!
Aggiornato per riflettere i requisiti Vulkan o OpenGL ES 3.1 per Android 7.0
Recentemente sono stati scritti molti articoli sugli aggiornamenti delle versioni, sulle interazioni tra fornitore e produttore di chipset e su cosa ciò significherà per i dispositivi futuri. Perché questo problema è aumentato questa settimana?
Ebbene, questa settimana è emerso che il venerabile Nexus 5 non riceverà l'aggiornamento ad Android 7.0 (Nougat), e Qualcomm ha annunciato che non lo sarà fornendo supporto per MSM8974 (più comunemente noto come Snapdragon 801) su 7.0. Questo articolo è stato scritto in collaborazione con XDA Recognized Sviluppatore calabrone.
L'argomento ha attirato un discreto interesse da vari siti di notizie, ma molti perdono le sottili sfumature di ciò che sta realmente accadendo dietro le quinteS. Questo articolo spiegherà qualcosa in più su come funzionano gli aggiornamenti software, utilizzando la nostra esperienza nella collaborazione con gli OEM sui loro aggiornamenti firmware ufficiali. Ti guideremo attraverso ciò che accade dietro le quinte (e perché) e perché potresti non riuscire a ottenere il software più recente sul tuo telefono.
Il primo passo nella vita di un aggiornamento del firmware Android è l'aggiornamento upstream. Questo è ciò su cui Google lavora internamente. A differenza dei "flussi di lavoro aperti", Android viene sviluppato utilizzando un flusso di lavoro chiuso, con il codice sorgente gettato al muro circa ogni anno, quando esce una nuova versione. Inizialmente, Google aveva affermato che ciò serviva a prevenire la frammentazione da parte di persone che eseguivano versioni all'avanguardia mentre le cose si stavano evolvendo rapidamente nei primi giorni, ma sembra che abbiano mantenuto questa politica posto.
Ad un certo punto, di solito prima dell'annuncio pubblico di un aggiornamento (anche se con la recente introduzione delle beta pubbliche, questi tempi stanno cambiando), Gli OEM verranno informati di un prossimo aggiornamento. Riceveranno quindi il codice sorgente in un secondo momento per l'aggiornamento finale (in passato era a volte un po' prima del lancio, anche se siamo a conoscenza di casi in cui non c'è anticipo pubblicazione).
I repository AOSP upstream contengono il supporto dispositivo solo per un numero limitato di dispositivi. Questi sono in genere i tuoi dispositivi Nexus. Tuttavia, per ragioni che saranno chiare a breve, è significativo notare che Google non ha il controllo hardware completo su questi dispositivi; i dispositivi sono prodotti da un OEM e tale OEM acquisterà un System-on-Chip (SoC) da un produttore di chipset.
Una volta rilasciato il codice sorgente, il team del firmware dell'OEM si siederà (in senso figurato) e alzerà i piedi. L'albero dei sorgenti principale di Android non dispone del supporto hardware per la miriade di chipset utilizzati nei dispositivi in vendita. Ad esempio, molto probabilmente il tuo chipset Qualcomm non è supportato in AOSP. Il tuo Exynos sicuramente non lo è. Mediatek o HiSilicon? Lasci perdere!
Il BSP contiene i driver e i livelli di astrazione hardware (HAL) necessari per far funzionare Android
Ciò che serve ora è a Pacchetto di supporto scheda (BSP). Si tratta di un pacchetto super confidenziale di componenti proprietari, consegnato da un produttore di chipset a un OEM. Il BSP contiene il codice sorgente necessario per consentire agli OEM di creare Android e i driver necessari per il proprio dispositivo.
Vale la pena notare qui che OEM come Qualcomm non si fidano necessariamente completamente dei loro partner OEM: il BSP è reso disponibile in base alla "necessità di sapere". Gli OEM di solito non hanno accesso al codice sorgente di alcune delle parti super segrete del dispositivo (come il software in esecuzione sulla banda base). Anche la chiusura di questa parte presenta sicuramente dei potenziali problemi, come dimostrato dal vicino abbondante E ricorrente ASN.1 analisi delle vulnerabilità.
Il BSP contiene i driver e i livelli di astrazione hardware (HAL) necessari per far funzionare Android sul tuo dispositivo. AOSP contiene una serie di HAL, che fungono da definizioni di ciò che il sistema operativo si aspetta che i driver implementino. Per usare un esempio ridicolmente semplificato (e inventato, a scopo dimostrativo), immaginiamo la torcia sul tuo telefono.
Un esempio di HAL: la tua torcia
Immaginiamo che il tuo dispositivo abbia una torcia sul retro (se hai un Nexus 7 2013, dovrai immaginare un po' più di chiunque altro, scusa!). Questo è controllato da un autista. Per il nostro esempio incredibilmente semplice, supponiamo che l'HAL v1 dica che dovresti avere una funzione chiamata "setLED" che accetta un singolo parametro, lo stato della luce. È un valore booleano: vero o falso. In C, questo sarebbe simile a questo:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Questa funzione è definita all'interno del codice sorgente BSP. Il BSP viene quindi compilato dall'OEM durante la creazione della ROM e questo diventa una delle librerie proprietarie ".so" nella partizione o nell'area del fornitore del dispositivo. Ciò consente a un OEM di mantenere segrete alcune parti del funzionamento del proprio dispositivo. Per ora, supponiamo che vogliano impedire a tutti di vedere come accendono e spengono quel LED.
Ora immagina che Google rilasci una versione aggiornata dei propri HAL in una futura versione di Android. Ora decidono che sarebbe carino permetterti di aggiornare la luminosità del tuo LED, piuttosto che semplicemente accenderlo o spegnerlo. Forse è per il flash adattivo o forse è solo per forzare un aggiornamento HAL e mantenere in attività i produttori di chipset? Lasceremo a te, lettore, la tua opinione su questo. Alcuni aggiornamenti HAL hanno evidenti vantaggi (come il nuovo HAL Fotocamera che espone riprese grezze e simili), mentre altri hanno uno scopo un po' meno chiaro.
Con questo nuovo HAL (immaginario) per la luminosità, supponiamo che Google dica che è necessario esporre nuovamente una funzione chiamata setLED, ma questa volta con un numero intero passato per la luminosità. Ora, 0 lo spegnerebbe e 255 lo metterebbe al massimo.
Se sei l'OEM, puoi prendere il tuo codice super segreto per accendere quel LED e inserirlo in questa nuova funzione. Potresti anche utilizzare la modulazione di larghezza di impulso per regolare la luminosità del LED in base al numero. Ora modifichi la funzione in modo che appaia in questo modo:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
E allora? Bene, ora questa nuova versione di Android è incompatibile con i "blob" esistenti. Il tuo OEM deve utilizzare questi nuovi BLOB, perché il sistema operativo Android si aspetta di vedere la nuova definizione di funzione e non "troverà" quella vecchia quando cercherà un modo per impostare il LED.
A questo punto, facciamo una breve pausa per vedere come si comportano le ROM personalizzate (create dal sorgente). È ciò che gli astuti tra voi urleranno davanti al vostro schermo in questo momento: dopo tutto, siamo XDA, la casa dei HTCHD2, il telefono più longevo al mondo... (giusto per la cronaca, quei pazzi geni laggiù stanno scappando Android 6.0 sull'HD2 in questi giorni! Non male per un telefono originariamente fornito con Windows Mobile 6.5 nel 2009)
Sono stati adottati vari approcci: a volte gli sviluppatori hackerano la ROM e dicono al sistema operativo di utilizzare le vecchie definizioni di funzione. È un po' complicato e richiede molte modifiche da mantenere. L'altro approccio consiste nello "spellare" il binario OEM.
L'approccio "shim" consiste nello scrivere e creare da soli una nuova piccola libreria, che contiene la definizione della funzione prevista: per il nostro esempio, supporteremo l'intero per la luminosità. Quindi, all'interno dello spessore, questo viene tradotto per soddisfare i requisiti del vecchio HAL. Quindi, per il nostro esempio, potremmo dire che qualsiasi luminosità richiesta superiore a 128 accenderà il LED e qualsiasi cosa al di sotto lo spegnerà. Oppure potresti dire qualsiasi cosa diversa da zero lo accenderà. Dipende dallo sviluppatore. Compilano lo shim e fanno in modo che Android lo utilizzi al posto di quello nativo. Lo spessore richiama quindi il blob OEM.
Un rapido "adb push" e un riavvio dovrebbero far funzionare lo spessore e consentirti di controllare il tuo LED immaginario, anche se hai solo il vecchio HAL.
Il problema è che questo è chiaramente un processo imperfetto. Ora avrai delle stranezze: questo dispositivo avrà un flash piuttosto scadente, che sarà completamente acceso o completamente spento. Non è l'ideale: il sistema operativo pensa che stia producendo una luce molto delicata, ma al LED vero e proprio viene detto che sta gareggiando in una gara di luce solare artificiale e sta cercando di accecarti. Ma ehi, la vita non è perfetta e ora hai un LED funzionante sul tuo vecchio telefono!
(Sì, questo è uno dei motivi per cui ci sono stranezze e bug quando gli utenti e gli sviluppatori XDA gestiscono le loro folli e insane imprese di abilità di porting. Voglio dire, diamine, il Galaxy SII sta portando con sé un oggetto apparentemente utilizzabile ROM Android 6.0 ora. Molti telefoni rilasciati l'anno scorso non hanno ancora la versione 6.0!)
Torniamo alla prospettiva dell'OEM. Purtroppo, la maggior parte degli OEM sta già lavorando con almeno 1 telefono in anticipo rispetto a dove ci troviamo adesso. La loro attenzione è rivolta al prossimo telefono che stanno per vendere: non puoi davvero biasimarli, dato che guadagnano solo sui dispositivi che vendono. Non guadagnano nulla dai dispositivi venduti uno o due anni fa, quindi devono continuare a rilasciare nuovi dispositivi per esistere. Questo è uno dei motivi per cui HTC e Blackberry sono nei guai: non importa quanti dirigenti mantengono una presa mortale sul loro vecchio Blackberry Curve, poiché lì non riescono a vendere un nuovo dispositivo.
Se l'OEM non ottiene un BSP, non seguirà l'approccio XDA di hackerare insieme una build. Perché? BENE, devono supportare questo firmware per i loro clienti. Se rilasciano un firmware che funziona a metà, gli utenti li odieranno, si lamenteranno e si delirano e manterranno le loro linee di supporto attive per giorni.
Anche gli OEM devono vedersela con i trasportatori, almeno nei mercati extraeuropei. Gli operatori non vogliono che i clienti abbiano problemi con gli aggiornamenti software. In effetti, gli operatori spesso preferiscono non rilasciare aggiornamenti software.
Per capirlo, immagina la tua prozia Alice. È lei che ti telefona nelle ore scomode della giornata per chiederti aiuto con "quella cosa del computer". Quindi descrivi come fare clic sul "menu Start" e devi identificarlo come la "grande bandiera nell'angolo in basso a sinistra" e incontri confusione. Circa 45 minuti (e molta frustrazione) dopo, emerge che zia Alice ha trascinato il menu di avvio sul bordo destro dello schermo e doveva semplicemente trascinarlo indietro. Sì, con il tasto sinistro del mouse!
Adesso immagina di avere mille zie Alice'. Stanno tutti telefonando al tuo servizio clienti, non riescono a trovare Candy Crush sul loro telefono, preoccupati che un hacker lo abbia cancellato dal loro telefono. Oh, e le icone ora sembrano un po' diverse: forse l'hacker è ancora nel loro telefono?
Sì, questo vuole essere un po' di umorismo spensierato, ma finché non sperimenterai i motivi per cui le persone chiamano il loro operatore telefonico per ricevere supporto, non crederai ai problemi che hanno. Un aggiornamento software che modifica il funzionamento del telefono o la posizione delle cose causerà un notevole sovraccarico di supporto. Come minimo, richiede la riqualificazione del personale di supporto (perché la maggior parte di loro non sono i tuoi avidi lettori di XDA, purtroppo).
Una volta che l'OEM ottiene il BSP, trasferirà la propria ROM e applicherà tutte le modifiche alla ROM. Accumuleranno il loro bloatware e aggiungeranno un'orribile skin da cartone animato che sembrerebbe più a suo agio nell'anime di un adolescente. Poi lo testeranno.
Molto.
Ci sono tutti i tipi di requisiti a cui il tuo telefono deve conformarsi. Le reti mobili sono progettate per garantire che l'apparecchiatura dell'utente (quello che chiamiamo telefono) si comporti correttamente. Ciò significa che sono necessari molti test per ottenere l'approvazione del dispositivo. Gli aggiornamenti software rischiano di modificare i comportamenti, quindi è necessario testare nuovamente le cose. Questo è il motivo per cui in genere vedrai informazioni sui prossimi aggiornamenti software Sony da servizi di test esterni, che confermano che il firmware è conforme ai requisiti di test.
Ora... cosa succede dopo uno o due aggiornamenti (o in alcuni casi, nessuno)? Il produttore del SoC non fornirà all'OEM un BSP aggiornato. Dopotutto, il produttore del SoC non otterrà molto da questo. L'OEM non guadagna più dal tuo telefono da quando è stato venduto. E a questo punto, il tuo telefono non riceve più aggiornamenti di versione principali.
Ridurre il numero di BSP che l'OEM desidera fornire è un ottimo modo per risparmiare denaro, se hai bisogno solo di quello attuale e non intendi fornire alcuna versione principale aumenta, ciò farà risparmiare denaro sull'acquisto iniziale del SoC e sulla licenza, ma a scapito di alcuni nerd arrabbiati su XDA in futuro, chiedendosi perché non hanno ottenuto un aggiornamento.
Gli aggiornamenti sono complessi. Ci sono molte persone diverse coinvolte nella catena. Niente di tutto ciò giustifica gli OEM dall'attuale stato apatico e patetico degli aggiornamenti su Android. Tuttavia, ci sono alcune sfide reali qui.
Molti OEM sono responsabili di promesse eccessive e il l’inevitabile sotto-realizzazione che ora associamo. La triste realtà è che per la maggior parte degli OEM gli aggiornamenti software sono solo un fastidio di cui potrebbero fare a meno.
Il settore mobile è per lo più bloccato nella mentalità dei feature phone. Cioè, dove un dispositivo non riceve mai alcun aggiornamento. Provalo una volta, spediscilo e non guardarti mai indietro. Con i problemi di sicurezza dei moderni smartphone e l'enorme complessità di gestire un sistema operativo completo, con centinaia di librerie esterne, questa non è più un'opzione. O almeno non dovrebbe Essere. Google ha compiuto alcuni passi verso la risoluzione di questo problema, almeno pubblicando bollettini sulla sicurezza e patch per le versioni esistenti di Android (ricorda che fino a poco tempo fa l'unico modo per ottenere aggiornamenti di sicurezza era tramite una nuova versione principale del sistema operativo Android!)
Ahimè, però, questo non è davvero sufficiente. Anche se Google continua a rilasciare aggiornamenti, la sicurezza del tuo dispositivo dipende ancora dal produttore del SoC, dal momento che i produttori di SoC sono così pietrificati qualcuno che scopre come accendere un paio di LED o emettere un suono attraverso un altoparlante, invia enormi quantità di blob binari sul proprio dispositivi. Questi BLOB contengono codice terribilmente insicuro (basta dare un'occhiata ai precedenti bollettini sulla sicurezza di Google se pensi che sia un'esagerazione!) e devono essere aggiornati. Ciò significa che sono necessari BSP aggiornati.
I computer desktop (e per estensione i laptop) hanno un'architettura completamente diversa dai dispositivi mobili. Il tuo telefono cellulare o tablet è in effetti un pezzo di silicio fortemente proprietario, progettato in fretta da alcune persone che hanno buone intenzioni, ma non hanno nemmeno il tempo sufficiente per creare qualcosa di buono. Il mercato si muove così rapidamente che difficilmente riescono a tenere il passo con il ritmo con cui il marketing richiede il lancio di nuovi prodotti.
Ciò significa che vengono prese delle scorciatoie: non troverai il tuo telefono supportato dal kernel Linux principale e scoprirai che ogni telefono ha un modo diverso di avviarsi. Sul tuo laptop o desktop, tuttavia, i fornitori hanno optato per alcuni modi standard di avvio: in precedenza era MBR (master boot record) con un BIOS, e ora è UEFI. Questa standardizzazione consente di eseguire lo stesso software su ciascun dispositivo.
Anche se recentemente sono stati fatti alcuni passi in questa direzione, soprattutto con il programma di sensibilizzazione di Sony e il loro nucleo unificato, non è pratico eseguire un kernel principale sulla maggior parte dei telefoni, a causa dell'enorme numero di nuovi hack specifici del fornitore introdotti su ciascun dispositivo.
Hai collegato il jack delle cuffie nel modo sbagliato? Basta hackerarlo nei driver! Non c'è tempo per sistemarlo nella progettazione della produzione.
Il team di produzione ha montato il modulo telecamera capovolto nel lotto di produzione 1? Inserisci un hack per controllare il codice della versione interna e gira il video se è la versione 1!
Hack come questi risolvono il problema immediato, ma raschiano solo la superficie dei cambiamenti strani e specifici del prodotto in corso. Cavolo, a volte ci sono anche chip completamente diversi in diverse revisioni dello stesso telefono, a causa di decisioni commerciali. Ciò ha portato ad attacchi informatici ai conducenti e a strane decisioni che avevano senso solo in quel momento, per far funzionare il telefono in modo che potesse essere spedito la settimana successiva.
Sebbene sia in corso il lavoro per il supporto principale dei chip ARM a 64 bit da avviare tramite UEFI, finora c'è stato nessun movimento chiaro verso un modo più standardizzato per avviare i dispositivi ARM. E questo è triste, perché significa che i telefoni continueranno ad essere buttati via ben prima della fine del loro ciclo di vita vite lavorative, perché è semplicemente troppo costoso mantenere il debito tecnico e l'onere che grava su di loro Software.
D'altra parte, però, se un OEM guadagna solo dalla vendita di un dispositivo, non deve garantire che le persone continuino ad acquistare nuovi telefoni? Il mercato dei PC si sposterebbe verso questo modello se non ci fossero 30 anni di slancio e software legacy già disponibili che utilizzano la piattaforma e lo standard PC aperti?
Questa è una domanda difficile senza la conoscenza interna di Qualcomm, che purtroppo al momento non abbiamo. Tuttavia, possiamo trarre alcune informazioni dai requisiti API del driver Android 7.0 e CTS. I requisiti CTS specificano cosa si aspetta Google da un dispositivo che esegue un determinato firmware. Il "grande martello" utilizzato per far rispettare questi requisiti è la licenza di Google per utilizzare il pacchetto proprietario di Google Play Services: se non rispetti, non potrai spedire Google Apps sul dispositivo. Mentre, per alcuni, questo potrebbe essere visto come un vantaggio, questo ovviamente non è ciò che gli utenti desiderano e si aspettano da un dispositivo.
Android 7.0 non ha aggiunto molto in termini di modifiche all'HAL o ai driver (come descritto sopra), quindi è improbabile che qualsiasi incompatibilità provenga specificamente da lì. Ciò che è più probabile che ponga un problema, tuttavia, è l’introduzione di a nuovo requisito per l'API grafica Vulkan o GLES 3.1, essere disponibile per superare il CTS.
Al momento, molti Systems-on-Chip (SoC) non hanno il supporto Vulkan sul proprio processore grafico, incluso l'MSM8974. È molto probabile che questo sia anche il punto in cui sorgerà il problema della compatibilità con Android 7.0. Ancora una volta, però, senza le conoscenze interne di Qualcomm e i loro piani futuri, è difficile per noi fornire una dichiarazione definitiva senza qualificarla. Al momento, tuttavia, riteniamo probabile che questo sia il "semplice" caso in cui Qualcomm interrompe il supporto il (ai loro occhi) vecchio chipset MSM8974 e non fornisce un BSP (pacchetto di supporto della scheda) per 7.0 su quella piattaforma. Se così fosse, significherebbe che gli OEM sarebbero quasi certi di non fornire la versione 7.0 sul dispositivo: dovrebbero in qualche modo trovare il supporto Vulkan o GLE 3.1 per la loro GPU e la sorgente GPU. è una delle parti ridicolmente sorvegliate degli stack mobili (senza una vera ragione, aggiungeremmo: vedi AMD, open source del proprio driver AMDGPU sul desktop per Linux). Purtroppo, però, la grafica Vulkan e quella accelerata (GLES) in generale sono un po' più complesse di un semplice LED, quindi non è qualcosa per cui vedremo degli spessori per introdurre la compatibilità.
Dato che la versione 7.0 non è uscita da molto tempo, esiste una reale possibilità che altri chipset (oltre al piccolo numero all'interno dello stesso AOSP) vengano lasciati indietro rispetto alla 6.0, a causa di problemi hardware e driver (ovvero assenza di BSP aggiornato) o della mancanza di supporto del fornitore SoC per quanto riguarda Vulkan o GLES 3.1 API. Al momento né lo Snapdragon 800 né l'801 supportano uno di questi.
La soluzione migliore è guardare questo spazio - Gli sviluppatori su XDA stanno già facendo buoni progressi con i port non ufficiali alla versione 7.0 per molti dei dispositivi che non ricevono il supporto ufficiale alla versione 7.0 da Google. Questi però non supportano Vulkan o GLES 3.1 - forse gli sviluppatori di giochi su Android inizieranno a farlo provare frustrazione a causa della frammentazione se un numero sufficiente di utenti inizia a eseguire ROM personalizzate senza Vulkan o GLES 3.1 supporto?
Apple tende a supportare la propria linea iPhone sull'ultima versione di iOS da circa 5 anni: l'iPhone 4s è stato lanciato nell'ottobre 2011 ed è stato aggiornato fino a iOS 9. Tuttavia, non riceverà il prossimo aggiornamento iOS 10, che darebbe al telefono una durata effettiva di 5 anni, supponendo che iOS 10 venga lanciato intorno a ottobre. Vale la pena notare che Apple non sempre supporta il backport dell'API grafica: iPhone 4s e iPhone 5 no presentano l'API grafica Metal di Apple, che è uno scenario in qualche modo simile a quello visto con Android in Vulcano. L'unica differenza è che Apple ha continuato a supportare i dispositivi più vecchi senza la nuova API grafica.
Cosa ne pensi? Installerai una ROM personalizzata sul tuo telefono per prolungarne la durata? Hai detto nei commenti qui sotto.