Link alla notizia: http://www.hwupgrade.it/news/telefonia/quasi-tutti-gli-smartphone-android-contengono-almeno-una-falla-di-sicurezza_59185.html

La colpa non è di Google, che rilascia prontamente i fix di sicurezza, ma dei produttori degli smartphone che non aggiornano i propri dispositivi

Click sul link per visualizzare la notizia.

"l'87% dei campioni è stato trovato vulnerabile ad almeno uno degli 11 bug diffusi pubblicamente negli scorsi cinque anni"

Se Google avesse proposto aggiornamenti "stile microsoft", indipendenti dal produttore/modello/piattaforma il problema non ci sarebbe.
Un servizio "google update" con permessi di root che può installare aggiornamenti di sicurezza senza cambiare versione dell'OS. Mi importa relativamente se android installato sia il 4.4.x il 5.1 o il 6, l'importante sia aggiornato sul fronte bug sicurezza. E non dite che è difficile, windows e linux lo fanno da anni a prescindere dall'hw installato e dalla versione dell'OS. Ma a google e ai produttori questo non interessa, prima diventa vecchio il telefono prima lo cambi, prima guadagnano.

"vulnerabili ad almeno una falla"

:doh:

"vulnerabili ad almeno una falla"

:doh:

Infatti non ha senso!!! NINOOOO correggi!!!!

Il grafico é praticamente inutile. La parte verde dei dispositive "sicuri" non ha senso: la falla c'era giá ma semplicemente non era ancora pubblica. Una volta scoperta la falla, il dispositivo da "verde" diventa "rosso".

si ma anche la, la brandizzazione del tel..

e standardizzatela

quattro sfondi del menga, qualche icona..

cosi' sono contenti sti operatori ma almeno se uno fa un update non salta tutto

Quasi tutti gli smartphone Android sono vulnerabili ad almeno una falla
certo, e
Quasi tutti gli smartphone iOS sono vulnerabili ad almeno una falla

Quasi tutti gli smartphone Windows mobile sono vulnerabili ad almeno una falla

TUTTI gli smartphone sono vulnerabili ad almeno una falla.
:tapiro: :tapiro: :tapiro:

La situazione e' sconfortante. Per l'utente l'unica speranza e' il supporto di rom alternative come cyanogenmod.

vale anche per il nexus 5 con tutte le patch di sicurezza installate ?

abbiamo capito che sei innamorato, Nino, ma, mi spiace, certo che la colpa è di Google (o almeno in buonissima parte), perché se da domani imponesse certe specifiche ai produttori relative alla personalizzazione del sistema e alla tempestività degli aggiornamenti, "altrimenti non ti faccio usare il mio android", tutto questo non succederebbe, e potrebbe farlo subito. Perché non lo fa? Perché questo avrebbe un costo per i produttori che si lamenterebbero e Google, essendo una società a scopo di lucro come tutte le altre (ebbene sì, non lavora per il bene del mondo come tutti pensano) non vuole pungolarli, temendo di perderne qualcuno per strada, con gli utenti del produttore che finirebbero con l'usare meno i vari chrome, gmail, gdrive, G+ eccetera eccetera... Sarebbero certamente pochi, ma mamma G non vuole perdere nemmeno quelli.

Il problema comunque sembra essere più a monte e pare che ci sia confusione nel capire chi è che deve rilasciare le patch di sicurezza dopo la pubblicazione da parte di Google
Non è questo quello che dicono nell'articolo.
Diamine lo traducete anche correttamente con:
C'è asimmetria nelle informazioni fra il produttore, che sa se il dispositivo è sicuro e riceverà aggiornamenti di sicurezza, e il cliente, che non lo sa

Questo significa che chi compra non ha idea delle probabilità che il suo device riceva aggiornamenti di sicurezza, non che ci siano dubbi su chi deve fare gli aggiornamenti per i device.

Il sorgente dei firmware dei vari device e/o i driver non sono mica accessibili a Google, come fa a fare le patch, magari firmarle con le chiavi crittografiche giuste a seconda del produttore e poi mandarle in giro?

Se Google avesse proposto aggiornamenti "stile microsoft", indipendenti dal produttore/modello/piattaforma il problema non ci sarebbe.Sai vero quale sarebbe la prima risposta dei produttori quando (non SE, dico proprio QUANDO) una patch inchioda le loro customizzazioni merdacchiose? Assumendo che non lo tolgano proprio nei loro firmware per evitare rogne o ragioni commerciali?

Già ci sono casi di Samsung che facevano i furbini e disattivavano Windows Update, figurati con Google che l'OS è opensource e a gratis.

Ma a google e ai produttori questo non interessa, prima diventa vecchio il telefono prima lo cambi, prima guadagnano.
Dall'articolo:
È interessante notare come lo studio sia stato in parte promosso dalla stessa Google che, probabilmente, vuole dare un segnale molto forte ai partner che producono smartphone e tablet Android.

La parte verde dei dispositive "sicuri" non ha senso: la falla c'era giá ma semplicemente non era ancora pubblica. Una volta scoperta la falla, il dispositivo da "verde" diventa "rosso".Il problema è che se usi "data di creazione della falla" come parametro, diventa tutto rosso a prescindere su qualsiasi OS, quindi il grafico puoi anche non farlo.

Anche su Windows escono falle che colpiscono tutti gli OS da Vista in su, quindi fare paragoni sul da quando esistono le falle scoperte X anni dopo non avrebbe alcun senso.

Usare il momento in cui la falla è pubblica è una ragionevole approssimazione, visto che di meglio non si può fare.

"altrimenti non ti faccio usare il mio android", tutto questo non succederebbe, e potrebbe farlo subito. Perché non lo fa?Perchè chiunque con una VM di Ubuntu aggiornata può andare sul sito di AOSP, tirare giù i sorgenti e compilarsi il suo firmware Android non pagando una cippa e in modo totalmente legale.

Quello che succederebbe è che i produttori cambiano nome all'OS e levano magari la mascotte di Android, e tutto prosegue come prima.

Se Google avesse proposto aggiornamenti "stile microsoft", indipendenti dal produttore/modello/piattaforma il problema non ci sarebbe.
Se l'avesse fatto con tutta probabilità Android non si sarebbe diffuso come è invece avvenuto. ;)

Ora però ci sono le premesse per forzare la mano, e trovo incredibile come i grandi produttori non si rendano conto di come migliorare questo aspetto non farebbe che bene alla qualità dei propri dispositivi (con conseguente maggiore soddisfazione del cliente e magari migliori vendite).

Se l'avesse fatto con tutta probabilità Android non si sarebbe diffuso come è invece avvenuto. ;)

Ora però ci sono le premesse per forzare la mano, e trovo incredibile come i grandi produttori non si rendano conto di come migliorare questo aspetto non farebbe che bene alla qualità dei propri dispositivi (con conseguente maggiore soddisfazione del cliente e magari migliori vendite).

non trovarlo incredibile: La maggior parte della gente, l'acquirente medio che va da mediaworld per capirci, a stento sa cosa siano gli aggiornamenti né tantomeno se arrivano presto o tardi, quindi non ha sta gran percezione di una qualità inferiore del prodotto. Per il produttore, invece, fare aggiornamenti tempestivi quando quello che distribuisci non è lo stesso android che dà google ma una versione che tu (produttore) hai personalizzato, è costoso. Avranno fatto le loro stime di costi/benefici e avranno valutato che non è conveniente, la gente fa prima a comprare un nuovo telefono.

"vulnerabili ad almeno una falla"

:doh:

fixed: "vulnerabili ad almeno un fallo"

:asd:

Fedele a Windows Phone con aggiornamenti costanti!
E chi se ne frega delle applicazioni mancanti che sono tutte uguali o sono cloni dei siti mobili

Quello che succederebbe è che i produttori cambiano nome all'OS e levano magari la mascotte di Android, e tutto prosegue come prima.

non è lo stesso motivo che ho detto io, scusa? che i produttori si sgancerebbero da google e sarebbero pertanto meno incentivati a proporre l'uso nativo delle app di google (come qualcuno tipo samsung ha già provato a fare). Quello che intendevo quando ho detto google dovrebbe imporsi è proprio NON ti faccio usare il mio codice (android) se non rispetti certe regole, non è che puoi prenderlo e cambiargli nome.

non è lo stesso motivo che ho detto io, scusa? che i produttori si sgancerebbero da google e sarebbero pertanto meno incentivati a proporre l'uso nativo delle app di google (come qualcuno tipo samsung ha già provato a fare). Quello che intendevo quando ho detto google dovrebbe imporsi è proprio NON ti faccio usare il mio codice (android) se non rispetti certe regole, non è che puoi prenderlo e cambiargli nome.

Essendo rilasciato sotto GPL non possono impedire l'accesso al codice di Android AOSP.

Ergo non esiste codice DI google che google può non rendere disponibile per far si che un produttore non usi android.

Essendo rilasciato sotto GPL non possono impedire l'accesso al codice di Android AOSP.Minore precisazione che non cambia il senso del discorso:

Il kernel è GPL in quanto kernel linux.

il resto di Android è quasi tutto sotto licenza Apache 2.0, che al contrario della GPL non forza nessuno a rilasciare i sorgenti di quello che ci fa.

Quindi permette ai produttori di fare prodotti closed source, nasconderci dentro le loro preziose modifiche merdacchiose e piene di bug, e fare dei firmware senza che nessuno sappia esattamente cosa è stato cambiato, basta che pubblichino i sorgenti del kernel e va bene.

Se fosse tutto sotto GPL col cavolo che si diffondeva, ma fare patch di terze parti sarebbe stato un attimo.

https://source.android.com/source/licenses.html

Essendo rilasciato sotto GPL non possono impedire l'accesso al codice di Android AOSP.

Ergo non esiste codice DI google che google può non rendere disponibile per far si che un produttore non usi android.

Questo non e' del tutto vero: i google play services (che non sono parte di Android AOSP) e' closed source e se un OEM vuole installarli deve sottostare ad una licenza ed accettare delle condizioni.

Questo non e' del tutto vero: i google play services (che non sono parte di Android AOSP) e' closed source e se un OEM vuole installarli deve sottostare ad una licenza ed accettare delle condizioni.

Infatti mi riferivo ad android AOSP, qunto impiegherebbe un produttore a fare come amazon o Nokia?


Minore precisazione che non cambia il senso del discorso:

Il kernel è GPL in quanto kernel linux.

il resto di Android è quasi tutto sotto licenza Apache 2.0, che al contrario della GPL non forza nessuno a rilasciare i sorgenti di quello che ci fa.

Quindi permette ai produttori di fare prodotti closed source, nasconderci dentro le loro preziose modifiche merdacchiose e piene di bug, e fare dei firmware senza che nessuno sappia esattamente cosa è stato cambiato, basta che pubblichino i sorgenti del kernel e va bene.

Se fosse tutto sotto GPL col cavolo che si diffondeva, ma fare patch di terze parti sarebbe stato un attimo.

https://source.android.com/source/licenses.html

Non lo sapevo.
In realtà cambia molto, Google potrebbe effettivamente non rilasciare più i sorgenti completi a chi non rispetta certe condizioni, ma a quel punto i produttori se ne fregherebbero ed andrebbero avanti a sviluppare i loro fork (basati sui sorgenti che ora hanno) rendendo il tutto ancora peggiore.

Un servizio "google update" con permessi di root che può installare aggiornamenti di sicurezza senza cambiare versione dell'OS.Comunque è un pezzo che Google sta migrando funzioni dell'OS indipendenti dall'hardware in Google Play Services, che è una "app" (tecnicamente) che viene aggiornata automaticamente dallo store.
http://arstechnica.com/gadgets/2013/09/balky-carriers-and-slow-oems-step-aside-google-is-defragging-android/

Questo non e' del tutto vero: i google play services (che non sono parte di Android AOSP) e' closed source e se un OEM vuole installarli deve sottostare ad una licenza ed accettare delle condizioni.E pagare qualcosa, tipo 1 euro a dispositivo. http://www.theguardian.com/technology/2014/jan/23/how-google-controls-androids-open-source

Ma è uno store, non è l'OS. Ce ne sono vari, e Samsung spinge molto il suo http://www.digitaltrends.com/mobile/android-app-stores/2/

Finché il mobile non avrà la standardizzazione presente sui pc e la secca divisione tra hardware / bios / sistema operativo, non sarà possibile aggiornare quest'ultimo se non passando dagli oem, e finché si passerà dagli oem, non sarà possibile correggere i bug di sicurezza in tempo breve.

(tra l'altro, UEFI su PC è un passo indietro da questo punto di vista, e lo dimostra il fatto che sia già un buon posto dove un malware possa fare danni e sopravvivere ad un FORMAT!)

Finché il mobile non avrà la standardizzazione presente sui pc e la secca divisione tra hardware / bios / sistema operativo, non sarà possibile aggiornare quest'ultimo se non passando dagli oem, e finché si passerà dagli oem, non sarà possibile correggere i bug di sicurezza in tempo breve.

(tra l'altro, UEFI su PC è un passo indietro da questo punto di vista, e lo dimostra il fatto che sia già un buon posto dove un malware possa fare danni e sopravvivere ad un FORMAT!)
Questo vale solo per una minima parte delle vulnerabilita', come quelle del kernel. Ma se esaminiamo le vulnerabilita' testate, gingerbreak riguarda adb, vold asec riguarda vold, fakeid, apk duplicate file, apk unchecked name, apk unsigned short riguardano librerie di sistema scritte in java... non hanno nulla a che fare con la divisione hardware/bios/sistema operativo, se non sono state risolte e' perche' Android e' progettato da cani, senza uno straccio di sistema di pacchettizzazione che comprenda l'intero sistema. Dpkg esiste dal 1994, installpkg dal 1993... eppure Google pensa di pacchettizzare webwiew solo 20 anni dopo, nel 2014. Forse tra altri 20 anni pacchettizzera' anche gli altri componenti di sistema. Nel frattempo, a meno di passare a sistemi proprietari, ci tocchera' limitarci ad usare lo smartphone per scrivere su facebook cosa abbiamo mangiato a colazione, perche' usarlo per gestire dati importanti e' come giocare alla roulette russa.

Finché il mobile non avrà la standardizzazione presente sui pc e la secca divisione tra hardware / bios / sistema operativo, non sarà possibile aggiornare quest'ultimo se non passando dagli oem, e finché si passerà dagli oem, non sarà possibile correggere i bug di sicurezza in tempo breve.

Infatti, molti non sanno che che Android si appoggia su un BSP (Board Support Package) basato su Linux fornito di solito in una versione "base" come SDK dal produttore del SoC (in cui integrare il supporto per gli altri componenti, se non sono già forniti nell'SDK)
che poi l'OEM (o un azienda che lavora su commissione) adatta all'hardware finale.
Se cambia il SoC (o più frequentemente, la famiglia di SoC, cambia il BSP).

Per questo con Windows Phone 7 e 8 ed ora con Windows 10 "per arm" per ora Microsoft usa solo SoC Qualcomm (deve supportare solo una famiglia di BSP "per Windows" relativamente simili tra loro).

questo è il senso della vera Inc. Cool 8 !!!

Questo vale solo per una minima parte delle vulnerabilita', come quelle del kernel. Ma se esaminiamo le vulnerabilita' testate, gingerbreak riguarda adb, vold asec riguarda vold, fakeid, apk duplicate file, apk unchecked name, apk unsigned short riguardano librerie di sistema scritte in java... non hanno nulla a che fare con la divisione hardware/bios/sistema operativo, se non sono state risolte e' perche' Android e' progettato da cani, senza uno straccio di sistema di pacchettizzazione che comprenda l'intero sistema.

Sinceramente non credo che alcun produttore OEM accetterebbe, senza una netta divisione tra la fine dell'hardware e l'inizio del sistema operativo, che quest'ultimo si aggiorni al di fuori del loro controllo.

Supponiamo che un update rilasciato da google non vada a buon fine (in windows update è successo parecchie volte), e supponiamo che il telefono rifiuti di avviarsi. Samsung/LG/... mica accetterebbero di riparare in garanzia il software.

Diverso è il discorso windows (android) si impalla, formatto il computer (telefono) e lo reinstallo daccapo.

Con questo non voglio giustificare il fatto che android non abbia una gestione pacchetti... solo cercare di capire per quale motivo non è stata neanche prevista....

"l'87% dei campioni è stato trovato vulnerabile ad almeno uno degli 11 bug diffusi pubblicamente negli scorsi cinque anni"
---cut---
Ma a google e ai produttori questo non interessa, prima diventa vecchio il telefono prima lo cambi, prima guadagnano.

:ave:

Comunque è un pezzo che Google sta migrando funzioni dell'OS indipendenti dall'hardware in Google Play Services, che è una "app" (tecnicamente) che viene aggiornata automaticamente dallo store.
http://arstechnica.com/gadgets/2013/09/balky-carriers-and-slow-oems-step-aside-google-is-defragging-android/

Questa è una cosa preoccupante IMHO: da un lato è vero che così la sicurezza di Android dipende sempre meno dalla velocità dei produttori a rilasciare gli aggiornamenti, ma c'è il problema di aumentare di parecchio le differenze tra l'Android di Google e AOSP, rendendo quest'ultimo sempre più svantaggioso (e per rispondere a qualcuno sopra, fare come Nokia ed Amazon diventa sempre più costoso e pericoloso)

Questa è una cosa preoccupante IMHO: da un lato è vero che così la sicurezza di Android dipende sempre meno dalla velocità dei produttori a rilasciare gli aggiornamenti, ma c'è il problema di aumentare di parecchio le differenze tra l'Android di Google e AOSP, rendendo quest'ultimo sempre più svantaggioso Al contrario.

In questo modo tutte le funzioni in lista sono installate/aggorinate automaticamente in tutti i dispositivi che hanno il Play Store Google.

Così è come avrebbe dovuto essere dal day 1, ma erano impreparati e lo stanno facendo ora.

AOSP o no è irrilevante come anche la versione di Android (entro certi limiti), se è Android quella roba gira.

(e per rispondere a qualcuno sopra, fare come Nokia ed Amazon diventa sempre più costoso e pericoloso)Sì, potrebbe diventare un'arma per costringere i produttori a fare la loro parte e non frammentare a capocchia.

Non mi dispiacerebbe affatto, ma comunque, un tizio sta facendo una versione open, http://liliputing.com/2015/10/free-and-open-source-android-framework-attempts-to-replace-google-play-services.html

Non dico che sia una strada per l'utente finale eh, ma che se messo alle strette un OEM probabilmente fa di meglio di un tizio a caso che lavora nel tempo libero quindi se ne esce con la sua versione (e di nuovo problemi di aggiornamento :muro: ).

Supponiamo che un update rilasciato da google non vada a buon fine (in windows update è successo parecchie volte), e supponiamo che il telefono rifiuti di avviarsi. Samsung/LG/... mica accetterebbero di riparare in garanzia il software.Tecnicamente dovrebbero anche per Windows eh, ma sappiamo quanto pagliacciata sia una garanzia.

Con questo non voglio giustificare il fatto che android non abbia una gestione pacchetti... solo cercare di capire per quale motivo non è stata neanche prevista.... Ne parla LMCH poco sopra, i driver per i SoC e tutte le infrastrutture di basso livello sono closed e soprattutto non li danno a nessuno se non paga un cifrone.

Ne parla LMCH poco sopra, i driver per i SoC e tutte le infrastrutture di basso livello sono closed e soprattutto non li danno a nessuno se non paga un cifrone.
Qui ci stiamo nascondendo dietro a un dito, solo alcune componenti di Android necessitano della collaborazione dell'OEM per essere aggiornate. O ritieni davvero che componenti come questa (https://android.googlesource.com/platform/system/core/+/master/libsysutils/src/) (che conteva la falla zergrush) o questa (https://android.googlesource.com/platform/external/dhcpcd/+/master) (che conteneva quest'altra (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7912) falla) necessitino dei driver del SoC per essere aggiornate?

Al contrario.

In questo modo tutte le funzioni in lista sono installate/aggorinate automaticamente in tutti i dispositivi che hanno il Play Store Google.

Così è come avrebbe dovuto essere dal day 1, ma erano impreparati e lo stanno facendo ora.

AOSP o no è irrilevante come anche la versione di Android (entro certi limiti), se è Android quella roba gira.

mi riferivo al fatto che aumentano le differenze tra AOSP e l'Android di Google a vantaggio di quest'ultimo... Insomma, Android è open source tramite AOSP, ma questo fatto va diventando sempre più irrilevante, perché la direzione verso cui stanno andando porterà ad avere un'Android di serie A, parzialmente open ma con la parte buona closed (perché inclusa in Play), dipendente da Google e che deve sottostare al MADA o equivalenti e un Android di serie B, meno aggiornato e meno sicuro ma open source... Sinceramente la cosa mi piace poco...

...e un Android di serie B, meno aggiornato e
meno sicuro ma open source...
Meno aggiornato e meno sicuro no di certo, quel codice è usato anche dall'Android "di serie A".
Sarebbe però un Android sempre più scarno, con molte funzionalità mancanti rispetto a quello di Google.

Dal punto di vista dell'utente lo spostare sempre più servizi nel google play service è una buona cosa (aumenta la parte del sistema che viene costantemente aggiornata anche se il produttore non aggiorna), lo è molto meno dal punto di vista della libertà del progetto.

Meno aggiornato e meno sicuro no di certo, quel codice è usato anche dall'Android "di serie A".
Sarebbe però un Android sempre più scarno, con molte funzionalità mancanti rispetto a quello di Google.

se un componente viene spostato da AOSP a Play e poi viene fixato un bug di sicurezza su Play, AOSP non avrà il fix a meno che non venga corretto da qualcun altro diverso da Google

Dal punto di vista dell'utente lo spostare sempre più servizi nel google play service è una buona cosa (aumenta la parte del sistema che viene costantemente aggiornata anche se il produttore non aggiorna), lo è molto meno dal punto di vista della libertà del progetto.

è ciò che intendevo dire con il primo post

se un componente viene spostato da AOSP a Play e poi viene fixato un bug di sicurezza su Play, AOSP non avrà il fix a meno che non venga corretto da qualcun altro diverso da Google
Sì, ma non avrà neanche il bug.

Perchè se il componente ora è nel Play, anche il bug sta nel play.

Qui ci stiamo nascondendo dietro a un dito, solo alcune componenti di Android necessitano della collaborazione dell'OEM per essere aggiornate.
O ritieni davvero che componenti come questa (che conteva la falla zergrush) o questa (che conteneva quest'altra falla) necessitino dei driver del SoC per essere aggiornate?
"driver E infrastrutture di basso livello". Ma comunque, spiego.

Android è un firmware, ma visto che ha le app e ha molte piú funzioni molti lo scambiano per un OS da PC cone una distro linux o Windows.

I PC sono un ambito molto particolare dove alcune regole standard del mondo degli OEM sono state distorte o scardinate a vantaggio degli utenti e di MS, perchè MS li ha presi a sberle e si è imposta con la forza con un OS che gli ha messo limiti ovunque.

Nel mondo embedded (tutto quello che non è un PC/server/eccetera), tutto lo sviluppo avviene tradizionalmente alla "brutto giuda", modificando brutalmente i sorgenti del firmware (linux) e facendo degli schifi immani non documentati e non compatibili con null'altro che QUEL DISPOSITIVO SPECIFICO Lì. Se va bene.

Esempio pratico, un router che ho avuto, un Asus rt-n56 credo, ha una feature particolare dove sfrutta l'accelerazione hardware del suo SoC per gestire il traffico in uscita (instradato al modem in bridging) a velocità maggiori di 100 megabit/s, come molti altri in commercio comunque, è una cosa comune. Lasciamo perdere per un momento che serve esattamente a 0 su un router consumer da 50 euro.

Bon questa cosa l'hanno ottenuta prendendo il sorgente del componente di linux che gestisce questa roba e lo hanno modificato brutalmente integrando in esso cose non documentate minimamente, discutibili, specifiche per il loro SoC e per quanto tecnicamente parte dei materiali rilasciati come opensource, non portabili nei progetti open come ad esempio OpenWRT perché far andare la feature su quel router andrebbe ad incasinare tutti gli altri.


Nei PC non possono fare cose del genere. Windows non si tocca sennò MS li mena, quindi si sono dovuti adattare a fare dei software/driver standardizzati come li vuole MS, per quanto ci provino sempre a fare i loro soliti schifi nei driver e nei programmi preinstallati dall'OEM (non quelli sponsorizzati, dico le utility e il crapware brandizzato).



La stessa cosa della faccenda firmware vale anche per Android. Tu (o io ma anche Google) non hai ALCUNA idea di quali e quante porcate hanno fatto nei componenti di base dell'OS per supportare le loro "esclusive feature" o anche solo semplicemente per far andare tutto con dei driver closed scritti coi piedi dal produttore del SoC e sui quali loro fanno poco o per tagliare sui costi di sviluppo di prodotti che tanto non supporteranno neanche quindi chissenefrega al cubo no?

E anche se non lo hanno fatto piú di tanto in un prodotto particolare, per loro é fondamentale poterlo fare alla bisogna, quindi se Google mettesse su un sistema di aggiornamento dei componenti veri del sistema si metterebbero a fare storie.

Android é stato messo open (ma chiudibile) e gratis proprio per farli abboccare, per fargli credere di potersi gestire le cose da soli e da cani come hanno sempre fatto con i firmware di tutti gli altri dispositivi che fanno.

Una delle ragioni per cui winphone non se lo sono cagato neanche di striscio e continuano a fregarsene tranquillamente anche ora é proprio questo. Non possono personalizzarselo in alcun modo, né fare cagate con il firmware per supportare eventuali "esclusive features", sennó MS li mena.

Ora che hanno abboccato, Google inizia a tirare la lenza, spostando lentamente cose nelle sue app, legando sempre piú app dell'ecosistema Android ai Google Play Services, e appena ha abbastanza potere contrattuale per potersi imporre, vedi che si inizia ad imporre col frustino come fa da sempre MS per mettere in riga questa banda di gatti.

Insomma, Android è open source tramite AOSP, ma questo fatto va diventando sempre più irrilevante,Ma é sempre stato irrilevante nel senso che intendi tu.
AOSP é solo una base di partenza per fare un firmware da device mobile che fa girare le app dello store Google, non una distro linux classica, né un bastione di libertá.

Il suo essere open é una necessitá pratica, non ideologica.

Google sviluppa a porte chiuse e poi quando é pronto smolla i sorgenti della nuova versione sull'AOSP perché gli OEM li possano usare.

La community fa cose, manda patch, fa fork sperimentali per nuove feature interessanti, fa roba varia, ma cosa va in ogni versione ufficiale di Android lo decide Google, punto.

https://source.android.com/source/code-lines.html

Sì, ma non avrà neanche il bug.

Perchè se il componente ora è nel Play, anche il bug sta nel play.

e se il bug risale a prima che tale componente fosse spostato nel Play? AOSP avrà una versione vecchia, meno aggiornata e con meno feature, e probabilmente avrà anche il bug :D

l'esempio perfetto sono le API di localizzazione, quelle AOSP sono inutili, quelle Play invece...

"driver E infrastrutture di basso livello". Ma comunque, spiego.

[...]

La community fa cose, manda patch, fa fork sperimentali per nuove feature interessanti, fa roba varia, ma cosa va in ogni versione ufficiale di Android lo decide Google, punto.

https://source.android.com/source/code-lines.html

92 minuti di applausi per il post (tagliato per praticità :D)

e se il bug risale a prima che tale componente fosse spostato nel Play?Allora è un bug di una API di Android, quindi è/sarà presente in tutti i firmware Android basati su AOSP (= tutti perchè la madre di tutti i firmware Android è AOSP) se qualcuno non si smazza a chiuderla nel suo (vedo una fila di OEM che sono proprio lì che scalpitano dalla voglia, Samsung in testa).

Nel caso specifico, le API del Play Services non disabilitano le API di Android, quindi "installa i Play Services" non è una risposta valida ad uno che dice che c'è un bug nelle API di Android.

Perchè AOSP è Android.
Non esiste che c'e un bug in AOSP e non nell'"Android di Google", perchè AOSP è l'android di Google.

Meno le sue app proprietarie che lo integrano coi servizi Google, ovvio.

AOSP avrà una versione vecchia, meno aggiornata e con meno feature, e probabilmente avrà anche il bug

l'esempio perfetto sono le API di localizzazione, quelle AOSP sono inutili, quelle Play invece...
???
Quelle AOSP usano solo il GPS di bordo, ma sono sempre presenti.

Quelle del Play usano i servizi cloud di Google per una posizione approssimativa via wifi/3G, e il GPS solo quando serve.

API standard http://developer.android.com/reference/android/location/package-summary.html

API Play Services https://developers.google.com/android/reference/com/google/android/gms/location/package-summary
Se vedi, tutte le sotto-API a parte LocationListener (il GPS di bordo, usato anche dalle API standard) richiedono GoogleApiClient che va a parlare coi server Google.
https://developers.google.com/android/guides/api-client#Starting


Quindi non è che "quelle di Google" vanno meglio e allora Google le mette closed.

Vanno meglio e sono closed perchè usano l'infrastruttura di Google (e il wifi/3G).

92 minuti di applausi per il post Grazie :D