La Rubrica dei Lettori: Project Treble perchè è cosi importante su Android

13 Novembre 2017 85

Torniamo oggi con l’appuntamento della Rubrica dei Lettori è una sezione del blog che permette a tutti gli utenti di porre i propri dubbi, quesiti, prove, test e pensieri ai fan del mondo Mobile. Tutti i contenuti di questa rubrica sono realizzati dagli utenti e, pertanto, non sono opera della redazione e/o esprimono pensieri e opinioni del sito. Oggi Oliver Thomas Cervera ci parla di Project Treble.

Project Treble può sembrare a prima vista una novità per smanettoni, di poca rilevanza o destinata ad essere dimenticata. In realtà è molto di più, e chiunque con un dispositivo Android che (non) riceve aggiornamenti dovrebbe sapere cosa è Project Treble.

Dato che non se ne è parlato molto, ho deciso di riassumere ciò che viene detto nel video sopra dall’Ingegnere Google che è a capo di Project Treble e di unirlo alla mia esperienza su Android. Vi sconsiglio di guardare il video: oltre a durare mezz’ora è molto noioso. L’Ingegnere è poco reattivo e fa allusioni sul fatto che ha sonno arretrato: sicuramente stava smanettando, su Project Treble! Le slide che seguiranno in questo articolo sono sempre del nostro amico Ingegnere.

È un cambiamento epocale

Google non ha mai agito in modo efficiente per combattere la frammentazione del Robottino verde: ricordo solo il PDK, Platform Development Kit, rilasciato tanti anni fa con scarso successo. Iniziamo con una domanda basilare: perché impegnarsi a combattere la frammentazione, quando è possibile arginarla parzialmente grazie all’aggiornamento delle app di sistema, o ignorarla come è stato fatto finora?

Chiaramente gli utenti vogliono l'ultima versione di Android sul proprio dispositivo, ma ci sono altri fattori che hanno spinto Google a lavorare sodo: più sicurezza e migliori implementazioni di Android, che si traducono in maggiore soddisfazione del cliente finale.

Standardizzare l'implementazione di Android

Prima di Oreo l'implementazione di Android non era facile. Va premesso che AOSP (Android Open Source Project) è un progetto alquanto astratto che nessun dispositivo può eseguire correttamente. Sì, so che ve lo state chiedendo, ma né i Nexus né i Pixel hanno AOSP in versione pulita, ma bensì Android “stock”, termine utilizzato per definire Android senza evidenti personalizzazioni dell’interfaccia utente. Per essere più precisi ogni Nexus/Pixel ha piccole funzionalità esclusive aggiunte da Google.

Per far funzionare l’AOSP, gli OEM (Samsung, Huawei, Sony) devono integrare il codice proprietario del Vendor (o chip-maker: Qualcomm, Mediatek, etc). In teoria la situazione dovrebbe essere così:


Purtroppo questo passaggio richiede molto tempo e risorse, perché l'implementazione Vendor-AOSP non è mai stata ben definita da Google e quindi si verificano degli intoppi nel “collegare” i due codici. Inoltre gli OEM devono maneggiare codice proprietario dei Vendor ai fini dell’implementazione di Android. I Vendor hanno sempre fornito il minor numero di informazioni possibile, perché il loro codice contiene informazioni riservate. Ne risulta che gli OEM hanno poche informazioni durante un processo che è già complesso di suo, rallentando ulteriormente l’implementazione di Android. La seguente slide rispecchia meglio la realtà:


È come fare una traduzione di latino senza dizionario, o assemblare un puzzle senza immagine di riferimento: concludi il lavoro male e lentamente.

I più smanettoni avranno incontrato almeno una volta il termine HAL, che rientra in questa categoria: definisce in modo generico il codice proprietario del Vendor necessario a far funzionare determinate funzioni hardware.


Terminata la faticosa implementazione del codice Vendor e fatti funzionare i componenti hardware, gli OEM devono procedere ad aggiungere le loro interfacce (TouchWiz, MIUI), funzionalità ecc. I tempi variano per ogni OEM dato che non tutti hanno queste interfacce ma si concentrano su piccole ottimizzazioni. Project Treble non si occupa delle interfacce personalizzate degli OEM, almeno non direttamente.

La ciliegina sulla torta arriva al momento di aggiornare Android: devono rifare tutto daccapo.

In Android Oreo il funzionamento dei componenti (chiamati server nella slide qui sotto) che interagiscono con l'hardware è stato standardizzato e isolato dal codice del Vendor. Questo permette di inserire il codice Vendor e farlo funzionare direttamente con l'AOSP. Questo è un cambiamento epocale: in precedenza, oltre a doverlo adattare all’AOSP, la complessità variava a seconda della piattaforma hardware e della versione di Android.


Velocizzare l'implementazione di Android

Grazie a Project Treble il processo di far funzionare Android AOSP su un dispositivo viene completato molto rapidamente. Da sola questa conquista permette un ingente risparmio di risorse umane, tempo e soldi. Le aziende hanno risorse limitate da dedicare agli aggiornamenti, le stesse devono lavorare anche sui nuovi prodotti, che hanno una importanza maggiore: le aziende fanno soldi vendendo prodotti, non aggiornandoli.

L'impatto di un aggiornamento Android passa attraverso tanti settori di una azienda, quasi come se fosse un nuovo prodotto. Molti OEM non aggiornano tanti dispositivi perché prima di Treble non era economicamente sostenibile. Sony ha documentato il processo in questa iconografia pubblicata da HDBlog nei giorni scorsi.


Non è solo una funzione da supportare

Project Treble e Oreo vanno a braccetto. E qui viene il bello: tutti i dispositivi lanciati con Oreo devono supportare Treble per ottenere la certificazione Google. Si applica anche se il SoC è vecchio: se un OEM volesse lanciare un dispositivo con Android Oreo e Snapdragon 625 dovrà supportare Treble.

Supportare Treble significa poter eseguire una versione non modificata del codice AOSP con la semplice aggiunta del codice del Vendor, e superare i test CTS e i nuovi VTS. I Test CTS (Compatibility Test Suite) verificano innumerevoli aspetti del sistema, per citarne alcuni: API, applicazioni di sistema, fotocamera. Servono ad assicurare la corretta compatibilità con l’ecosistema Android, ma soprattutto che i requisiti imposti da Google nel CDD (Compatibility Definition Document) siano stati rispettati. In questo documento Google elenca ciò che un OEM deve, non deve o può fare per poter procedere nel processo di certificazione.

I test VTS (Vendor Test Suite) sono concentrati sul processo di implementazione di Android (Oreo) su una determinata piattaforma hardware. In particolare vengono testati il kernel e l’HAL, per verificare la loro corretta implementazione secondo gli standard di Treble.

Treble non è obbligatorio per i dispositivi che vengono aggiornati a Oreo, ma è comunque possibile implementarlo: Google ha assistito alcuni OEM durante questo processo. Chiaramente verrà fatto solo sui dispositivi che l'OEM intende supportare attivamente. Richiede comunque un impegno di risorse dato che c'è una riscrittura pressoché totale dell'implementazione Android sul dispositivo che supporterà Treble. Per fare un esempio banale, è possibile che il Galaxy Note 8 supporti Treble dato che è un top gamma che Samsung intende supportare.

Più funzioni per tutti!

Google spera che gli OEM adottino più spesso un codice AOSP pulito dato che devono comunque usarlo per i test. A mio parere questa tendenza si può già apprezzare. HTC che è diventata con il tempo sempre più stock; Motorola, Sony e OnePlus lo sono sempre state; nuove realtà hanno deciso di essere rimanere stock come Nokia, Essential e Razer (forse le ultime due sono davvero troppo piccole). Rimangono i fantastici quattro: Samsung, Huawei, LG e Xiaomi; ma Google ha pensato anche a loro. Prendendo atto che le interfacce personalizzate sono qui per rimanere, Google sta collaborando con gli OEM per integrare funzioni ideate da loro nell'AOSP. Un esempio sono i contributi di Sony in Android 8.0 con l’integrazione definitiva di OMS (Overlay Manager Service, il sistema temi alla base di Substatum) e dei i codec audio Bluetooth LDAC. Chiaramente l'OEM deve permettere l’integrazione, ma la risposta è stata positiva. Oltre a disincentivare l’uso di interfacce personalizzate, ci sono due chiari vantaggi con questa operazione: più funzioni per tutti in AOSP e un’unica versione di esse senza creare ulteriore frammentazione. Quante versioni degli screenshot estesi avete visto? E quante dei temi? Se necessario verranno poi create delle API standard per tutti per interagire con queste nuove funzioni.

Più sicurezza per tutti!

Come se non fosse abbastanza, Google ha sentito la necessità di lavorare sul Kernel Linux, che è alla base di Android. Il problema principale è che il Kernel Linux LTS (Long Term Support) ha una durata di supporto di due soli anni. In media passa più di un anno (nel migliore dei casi) dall'annuncio di un kernel LTS e l'annuncio del primo dispositivo che lo esegue: in questa situazione un nuovo dispositivo si trova davanti pochi mesi di supporto lato Kernel. Molti problemi di sicurezza sono risolvibili con un kernel aggiornato, quindi Google ha convinto la fondazione Linux a supportare le versioni LTS del Kernel per 6 anni, così i dispositivi potranno rimanere aggiornati più a lungo. Dato che Project Treble semplifica l'implementazione del codice Vendor, sarà facilissimo per gli OEM aggiornalo, e quindi mantenere anche il Kernel aggiornato.


Non assisteremo più al cherry picking: OEM che “back-portano” patch di sicurezza da versioni più nuove del Kernel a quella attualmente utilizzata (lo fa spesso Samsung), come è intuibile questo processo richiede molto lavoro.

Può sembrare che estendere il supporto del Kernel vada contro l’obiettivo di Treble, ma ciò facendo si assicura più sicurezza e aggiornamenti ai dispositivi. È necessario specificare che se un dispositivo nasce con il kernel 4.4, concluderà il suo ciclo vitale su quel ramo, non è possibile passare al 4.9 (LTS successivo) a causa dell’implementazione di esso da parte del Vendor (Sviluppatori su XDA hanno sfatato questa regola in rari casi).

A questo punto dovrebbe essere chiara l’importanza di un kernel supportato per 6 anni.

Se i Pixel 2 hanno tre anni di supporto garantito non è un caso.

Il primo kernel con supporto LTS a 6 anni è la versione 4.4, già montata sui SoC di quest'anno, a cui seguirà la 4.9.

L’estensione del kernel LTS a 6 anni non riguarda solo Android: porta vantaggi in altri settori dove è difficile fornire aggiornamenti, come i dispositivi IoT o i Router.

Il futuro

Secondo le slide dell’Ingegnere Google, sono state già pianificate sei implementazioni di Treble, fra nuovi prodotti e aggiornamenti, senza però fornire ulteriori dettagli, in quanto alcune devono essere ancora annunciate.

Il lavoro di Google non finisce qui. Project Treble sembra essere in evoluzione, esattamente come Android. Google continuerà a lavorare con i Vendor, OEM e la fondazione Linux per ottenere ulteriori miglioramenti.

C’è un particolare impegno verso il Kernel Linux e il processo di implementazione di esso nei SoC da parte dei Vendor. Treble non tocca questo aspetto, e dopotutto Qualcomm e affini ci mettono sempre un anno per implementare una versione del Kernel.


Riflessioni Finali

È probabile che Google, diventando OEM in prima persona con i Pixel, si sia resa conto di cosa significa implementare Android in un dispositivo e quindi abbia deciso di intervenire per cambiare la situazione.

Fra i vantaggi di Project Treble vale la pena menzionare che gli sviluppatori delle app saranno maggiormente incentivati a integrare le novità presentate dalle ultime API, fornendo più funzionalità da sfruttare e finalmente smetteranno di utilizzare quelle di Lollipop.

Ci aspettano grandi cose su Android: Google ha imposto Project Treble, e un motivo ci sarà. È arrivato il momento in cui la maggior parte dei dispositivi riceveranno patch mensili subito e major release entro tre mesi? Forse sì, se avete un dispositivo no brand, ma è troppo presto per dirlo: appuntamento fra 6 mesi con Android 8.1 e patch di sicurezza di maggio 2018.

realizzato da Oliver Thomas Cervera

L'iPhone più potente di sempre con il design più classico di sempre? Apple iPhone 8, in offerta oggi da Phone Strike Shop a 540 euro oppure da Unieuro a 670 euro.

85

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
Kaovilla

A me la Miui è l'unica che permette di usare due app in multi window che funzionino entrambe in contemporanea mentre interagisco con una delle due. Per es. un giochino posso lasciarlo andare, mentre utilizzo whatsapp. Con Android stock mentre utilizzo una delle due app l'altra si freeza, si blocca lo sfondo, non so come spiegarlo.

efremis

Ottimo e d'accordo su tutto tranne che sulle unificazioni delle interfacce. Sono veramente le uniche cose che differenziano un Android dai mille altri. E personalmente molte le preferisco ad Android stock.

FabrizioSilveri

L'una e l'altra cosa però non si escludono: se il requisito per essere certificato Treble è l'uso "pulito" di AOSP la cosa si può fare sia direttamente, se input e output dell'hardware sono compilati adeguatamente, sia con un HAL in mezzo, e sta al vendor decidere quale implementare.
Ovviamente l'implementazione diretta sarebbe più efficiente computazionalmente, ma non è quello l'obiettivo primario: la cosa più importante è che tutti (vendor e OEM) supportino Treble il prima possibile, standardizzando quindi al massimo le funzioni di Android senza complicare la vita agli OEM.

ROOT

Rileggi l'articolo allora.

Lorenzo Ori

Siamo a 3.18.82 con le patch kernel side per KRACK

Oliver Cervera

Il filtro luce blu c'è su Android stock: non c'è sui Nexus 5X/6P per una scelta politica. Gli screenshot continui non ci sono, e sarebbe una bella aggiunta.

Oliver Cervera

Con Treble gli HAL saranno forward-compatible (compatibili per le versioni future)

Oliver Cervera

Eheh infatti, alcuni stanno cercando di fare i furbi

Francesco Bramato

L'unica personalizzazione che sopporto è la TouchWiz (ora Samsung experience), solo per la gestione delle impostazioni e del pannello di controllo. Android stock non mi fa impazzire da questo punto di vista.

Oliver Cervera

Immagino che un motivo ci sia, vuoi per la sicurezza, scalabilità o altro.
No, non so come funziona i moduli kernel Linux, la mia conoscenza è limitata a riguardo, sono solo un consulente, non ho mai programmato né studiato a fondo il Kernel Linux

Lorenzo Ori

Il 3.18 lo conosco bene, sto supportando con l'aiuto di BQ la maggior parte dei device commercializzati con un custom kernel che ha come features principale l'ultima versione Linux disponibile.

La stessa cosa l'ho fatta sul loro tab (mtk) partendo da 3.18.22 > 3.18.81-rc1; la differenza si percepisce subito

Dea1993

ahh giusto è vero il 3.18 è stato molto usato negli smartphone 2016, pure il mio xperia X ha quella versione

Dea1993

ah giusto in effetti pure il mio xperia X si basa sul kernel 3.18.

ghost

Io veramente parlavo per me xD

Lorenzo Ori

Si ok ma vedo quale problema possa esserci tenendo conto che la totalitá dei qcom è basato su 3.18.31

Dea1993

si comunque è questione di poco prima che venga abbandonato

Lorenzo Ori

Parziali

Lorenzo Ori

Il 3.18 ha ricevuto il tag EOL ma non è ancora "morto", proprio 5 ore fa è uscita la 3.18.81

Lorenzo Ori

Dipende da OEM a OEM, non tutti sono uguali

Lorenzo Ori

Si va di backport e hack per rendere compatibile l'OS con il SOC

Lorenzo Ori

Tutto molto bello sulla carta ma la maggior parte degli oem può sospendere l'avanzamento del device senza avviso per cui con o senza Treble la situazione non cambierebbe

All'interno dell'articolo manca la parte inerente alla pratica dell'upstream del kernel linux che permette di anticipare la maggior parte delle problematiche prima che vengano chiuse con il loro identificativo CVE

zdnko

Ecco perché escono tutti con android N!

Leon94

Non mi piace a prescindere iOS e nè gli iPhone in generale. Hanno un design standard e innovazione 0. Solo iPhone X mi incuriosisce, ma a questo punto scelgo LG V30

Johnny g16

Tutte le funzioni specifiche di quel componente non sarebbero presenti nelle API di android e quindi non avrebbero neanche un server per gestirle all'interno di aosp.

L'unico caso in cui ho qualche dubbio su quello che ho detto e quindi ci potrebbero essere problemi per un hal standardizzato, è la fotocamera.
Ma solo perché ultimamente va di moda utilizzare una fotocamera doppia e ci sono troppe implementazioni differenti.

In quel caso penso, ma non ne sono sicuro, che ci potrebbero essere due driver differenti (uno per camera) combinati dall'hall ma non ne sono sicuro; visto che la doppia fotocamera viene venduta come unico componente, potrebbe avere anche un unico driver e anche in quel caso si potrebbe usare un hal standard

gfux64

si le patch mensili arrivano puntuali

gfux64

ovvio, non parliamo di problema. Le patch di sicurezza arrivano puntuali.
Il fatto è che il progetto AndroidOne, proprio come questo Treble e altri prima di lui, prometteva di diminuire la frammentazione, garantendo per 18 mesi l'ultima release disponibile appena uscita. Ci si aspettava un ciclo di release simile ai vecchi nexus

an-cic

sarà, ma questi sono i fatti

Simone Dalmonte

Bah, è abbastanza inspiegabile...

an-cic

il grattacapo lo hanno da 3 mesi...e siamo già a metà novembre. probabilmente salteranno anche questo

Simone Dalmonte

Pensa che S7 nobrand ita l'ho aggiornato allle patch di ottobre già da 10gg. Avranno avuto qualche grattacapo, sui nobrand di solito samsung ne spara 1 al mese di regola: c'è la lista firmware su sammobile e per s7 è stata un'orologio

Simone Dalmonte

Come se il 98% delle persone che acquista ios o android sia a conoscdnza di queste belle novità da nerd...

Batuffolino

passa da IOS e non avrai questi problemi

Darkat

Non voglio azzardare ipotesi, ma credo che l'hal serva all'oem per avere piu controllo sull'hardware e poter implementare funzioni sull'hardware specifiche. Ma sto campando un ipotesi così. In effetti comunque Android è stato pensato in maniera un po' macchinosa, forse dovuto al fatto [battuta, perdonatemi] che il progetto è partito da sviluppatori java

Adriano

Ragazzi, domanda da chi è più informato sulle custom. Ho la nitro nougat stable. Sulla versione oro in lavorazione sta cosa immagino ci sia, giusto?

Oliver Cervera
Per l'oem basterebbe prendere aosp senza modifiche e compilare il kernel inserendo i moduli forniti dai vendor


è quello che dovrebbe accadere con Treble. Non voglio azzardare i 30 minuti / 1 dipendente, ma Google fa capire che gli HAL forniti dai Vendor con Treble diventano standard e quindi dovrebbe bastare una semplice compilazione...

Oliver Cervera

Il 3.18 è stato usato dai SoC mobile nel 2016!
Per il resto il tuo ragionamento fila, ma non ho molto da aggiungere dato che non so altro XD

rsMkII

Aspettare 2 mesi non crea chissà quali problemi, basta che le patch siano sempre aggiornate.

rsMkII

Eh, ci vorrebbe davvero un Pixel come il Nexus 4, a un prezzo onesto. Secondo me un buon dispositivo, supportato per 3 anni che costi massimo 400€ si potrebbe fare senza nessun problema.

Johnny g16

La loro implementazione del kernel è uguale all'implementazione di un qualsiasi kernel linux, con qualche differenza nella gestione della memoria.

Il lavoro del kernel è proprio quello di astrarre l'hardware sottostante, introdurre un ulteriore layer di astrazione è inutile e non doveva essere inserito fin dall'inizio.

Se si elimina l'HAL introducendo delle chiamate al kernel standardizzate per i componenti che utilizzano API standard (camera, audio, sensori, display) l'astrazione verrebbe gistita tutta dai moduli del kernel.

Per l'oem basterebbe prendere aosp senza modifiche e compilare il kernel inserendo i moduli forniti dai vendor.

Tempi di sviluppo per gli OEM: 30 minuti, 1 dipendente.

Tempi di sviluppo per il vendor: pressoché invariato perché tanto avrebbero comunque dovuto fare il codice per l'astrazione mantenendo le caratteristiche segrete (come dici nell'articolo)

Naturalmente tutti i componento non standard tipo, una telecamera aggiuntiva a infrarossi per il riconoscimento facciale, richiederebbero un lavoro di sviluppo da parte dell'OEM, perché oltre al modulo del kernel servirebbe il relativo server (che all'interno di aosp non c'è) che faccia da intermediario tra l'app e il kernel

Leon94

Mi chiedo una cosa.....
Se Linux aggiorna i kernel e Google AndroidOS, ma se Qualcomm dovesse comportarsi come con il suo processore Snapdragon 801 che non ha più sviluppato i driver come si farà?

an-cic

che vantaggio ne ha google? a google interessa che android sia diffuso per poter raccogliere più dati possibili e inimicarsi gli oem è l'ultima cosa che vuole

an-cic

5 anni farlocchi

an-cic

samsung s8 italia fermo ad agosto...

Dea1993

a questo punto mi viene da pensare che se certi kernel hanno un supporto così lungo è a causa di debian.
il 2.6.32 era utilizzato da debian (ora chiedermi in quale release è troppo xD) così come il kernel 3.2 era usato in debian (mi sembra nella prima versione in cui approdò gnome shell), poi mi sembra che il kernel 3.16 fu utilizzato in debian 8 e ora il kernel 4.9 in debian 9.
ed effettivamente le varie release del kernel supportate più a lungo coincidono con le varie release di debian.
però comunque non capisco perchè anche il 3.18 abbia avuto un supporto più lungo dei 2 anni citati nei vari articoli (visto che come ho detto a dicembre farebbe 3 anni) e non mi pare ci sia nessuna distribuzione di interesse che la usi, perchè ubuntu 14.04 (preceente LTS) usava il 3.13 (anche perchè il 3.18 non era ancora uscito) mentre l'ultima LTS la 16.04 ha usato il kernel 4.4.

Oliver Cervera

Come ho detto nell'articolo Google continua la collaborazione e cerca di spostarla sui Vendor. Il problema è che la loro implementazione del kernel richiede fin troppo tempo. Comunque in generale il vendor

Oliver Cervera

Hai ragione, la situazione non è chiara. È vero che i kernel che hai citato vengono aggiornati nonostante siano fuori LTS, ma questo accade perché c'è chi vuole aggiornarli, e soprattutto non viene fatto in maniera costante ma solo quando necessario. In IT si usa il termine "best effort" per definire questa pratica. La fondazione Linux non ha interesse ad aggiornare le versioni fuori LTS, vengono aggiornati da collaboratori esterni o comunque quando c'è una azienda che paga.
Quelli EOL vengono definitivamente cannati, come il 3.4 o il 3.18.

tuamadre

Vero, sarebbe fico avere 5 anni di aggiornamenti sui Pixel, ma quello che tentavo di dirti è che neanche Apple ha 5 anni di aggiornamenti. Perché di fatto negli ultimi 3 cambiano solo i numeri nelle info software e le prestazioni dimezzate. Qualsiasi terminale non è fatto per durare più di 3 anni. Il software, si appesantisce e cambiano le esigenze. Il mio Nokia N900 funziona alla perfezione anche adesso, nonostante gli 8 anni sul groppone, ma non mi sarei mai sognato di usarlo fino a 3 anni fa. Nemmeno se l'avessero aggiornato. Un iPhone 4s, o 5 o 5s, non avevano batteria all'uscita, figurati adesso con tutti gli aggiornamenti come stanno messi. Se li usi per telefonare e mandare whatsapp ti credo che si possano ancora usare, ma altrimenti sei un masochista. E poi parliamone di essersi presi un iphone per telefonare e mandare whatsapp, significa essere furbi. Non so se mi sono spiegato, ma credo che aggiornare per 5 anni sia solo uno spreco di denaro e risorse per le ditte e un'inutile castrazione per l'utente. 3 anni sono più che sufficienti.
ps se poi contiamo che le batterie sono garantite 600-800 cicli se va bene, quanto vuoi andare avanti?

Dea1993

anche io odio le personalizzazioni così marcate, però se sono ben ottimizzate, è giusto che esistano, non tutti apprezzano android stock, per alcuni ha troppe poche funzioni.
a me sinceramente manca solo il filtro luce blu e gli screenshot continui, ma per il resto android stock lo trovo infinitamente meglio

Lonza

a me le personalizzazioni spinte dei 4 fanno schifo.
Detto questo è una loro scelta legittima e bisogna pur dire che nel sovraffollato mondo Android bisogna pur differenziarsi in qualche modo

Enrico Garro

Mi riferivo più che altro agli anni di supporto. Ora come ora un pixel è supportato per 3 anni, un iPhone 5. Se Google riuscisse a colmare questo gap darebbe quanto meno un senso ai suoi stessi prodotti

Xiaomi Mi Mix 3 (3.200mAh): live batteria | Inizio ore 8.00

LG V40 ThinQ al CES in attesa del suo debutto in Italia | Video anteprima

SNAPDRAGON 855 su Lenovo Z5 Pro GT e SLIDER | Video Anteprima

Recensione Oppo RX17 Pro: ricarica lampo e super foto notturne