Discussion :

[23JFK]

Va aussi falloir que google ralentisse la fréquence des grosses mises à jours, parce les utilisateurs lambda ne s'avèrent guère plus enthousiastes que les constructeurs à faire de grosses mise à jours qui requièrent un minimum de préparation (batterie pleine - espace mémoire disponible - connexion réseau - de 10min à une heure sans téléphone à épier l'éventuelles messageboxes) si ce n'est quelques compétences (ouaip l'utilisateur lambda panique devant l'alternative j'accepte / je refuse).

[Aiekick]

Pratique pour google vu les options non désactivables (critique pour la confidentialité : http://www.developpez.com/actu/65550...-l-EFF-reagit/ ) qu'il ont mit en place dans la 4.4 et qui étaient désactivables dans les anciennes..

[nicroman]

Je ne rentrerai pas dans la discussion stérile de la fragmentation, qui n'a pas lieu d'être de toute manière... Aucun constructeur (même Apple) n'a la volonté de "supporter" des produits vieux de 3 ou 4 ans. Chaque "mise à jour" leur coûte un bras (et quand elle existe est annulée par le fournisseur qui a rajouté sa propre surcouche et ne fera de toute manière pas la mise à jour non plus)...

Google essaye de s'affranchir de ces versions successives par l'utilisation des "Google Play Services"... Tant mieux.
Cela n'empêchera pas les constructeurs à faire leurs propres surcouches (et donc être "en retard" de quelques mois, pour peu que le téléphone soit encore vendu...). Sinon, il reste les versions AOSP.

J'interviens juste pour corriger un truc lu dans le thread: Android n'est pas un OS Java...
Android est un système Linux.. un vrai de vrai, presque complet, avec ses drivers, et codage possible en C "à l'ancienne"...
Dalvik (et donc le langage Java) n'arrive que pour la partie "Framework" d'Android, et est, à priori, indépendant du système lui-même, utilisant quelques librairies natives (et drivers: la partie "modem" de l'OS si je ne dis pas de bêtises).

[Stéphane le calme]

Un document révèle les accords entre Google et ses OEM,
de nombreuses restrictions accompagnent l'adoption d'Android

Ben Edelman, professeur de la Harvard Business School et consultant pour le compte de sociétés concurrentes à Google (AOL, Microsoft, The New York Times, Universal music ou Wells Fargo), s’est procuré le contrat d’accord de distribution des applications mobiles de Google (Mobile Application Distribution Agreement ou MADA). Récupérées en 2012 dans le cadre de l'affaire opposant Google à Oracle, les informations fournies par ledit document qu'il a publié décrivent plusieurs restrictions soumises aux OEM en 2011.

En se référant à l'accord signé par HTC, il apparaît que les constructeurs désireux de recevoir une certification Android ne devront pas pré-charger un virus, un malware ou un morceau de code pouvant potentiellement affecter une application de Google. En dehors de ces règles de bases nécessaires pour pouvoir bénéficier du répertoire de Google Play, les constructeurs devront pré-installer des applications Google sur l’appareil à l'exceptions de quelques unes qui sont optionnelles (Orkut, Google Goggles, Google Earth, Finance, News & Weather, Google Buzz et Google Voice). De plus le fabricant devra offrir une grande visibilité au Widget de recherche, Google Phone-top Search, ainsi qu’un raccourci vers Google Play, Android Market. Les recherches sur Internet devront pour leur part pointer vers le moteur de Google. En outre, le fabriquant devra embarquer et activer le mécanisme de géo-localisation de Google.

Malgré la proposition de Google de l’ « open source » d’Android, ses partenaires devront se retenir d’encourager ou de soutenir la création de versions alternatives à son système fork. Ainsi, le système d’Amazon Fire OS ne saurait être pré-installé sur un smartphone HTC ou LG ou Sony. Ce qui pourrait probablement expliquer la raison pour laquelle Samsung s'est abstenu de développer son propre OS mobile basé sur Android et a préféré se tourner vers MeeGo pour concevoir Tizen.

Les OEM doivent fournir à Google des rapports mensuels sur leurs chiffres de vente dans le détail (modèle du téléphone, pays...). Ainsi, la société est en mesure d'avoir des informations comme les types de smartphones populaires dans tel ou tel pays. De plus, Google demande à recevoir au moins quatre prototypes pendant le processus de fabrication d'un nouveau smartphone et s'octroie le pouvoir de bloquer la vente d'un téléphone ne correspondant pas à ses critères.

Les documents datant de 2011, il est fort probable que les restrictions aient subi des modifications. L'accord entre un OEM et Google est valable deux ans.

Source : Blog Edelman

Et vous ?

Que pensez-vous des restrictions de Google ?

[merad]

Quesque vous auriez fait à la place de Google ?
Investir des milliards dans un OS et l’offrir gratuitement aux OEM sans contreparties !

[BugFactory]

Justement non, Android est une distribution Linux, ce n'est pas Google qui a tout fait. De plus, il me semble que c'est uniquement les applications de Google qui sont soumises à ces conditions, pas Android lui-même. Evidement, Android perd beaucoup d'intérêt sans les Google Apps. (Si quelqu'un en sait plus sur ces conditions d'utilisation, je suis preneur.)

Plus intéressant, l'interdiction de développer un fork. Je ne trouve pas choquant que Google impose des conditions à l'utilisation de ses applications, mais interdire le fork d'un logiciel open source, c'est de l'abus.

[Uther]

Que pensez-vous des restrictions de Google ?

Rien de vraiment nouveau, on savait que si la base d'Android est Open Source, les applications Google, y compris le GooglePlay étaient soumises a conditions, et c'est a peu prêt le genre de conditions auxquelles on pouvait s'attendre.

Plus intéressant, l'interdiction de développer un fork. Je ne trouve pas choquant que Google impose des conditions à l'utilisation de ses applications, mais interdire le fork d'un logiciel open source, c'est de l'abus.

Il n'interdit pas les forks, ce qui serait en effet contraire au libre mais il précise que les fork n'auront pas la certification de Google.

[naf87]

Au finish, rien n'est gratos. Et le terme "open source" devient de plus en plus un slogan de marketing qui masque des conditions quelques fois invraisemblables. Après tout, c'est aussi ça les affaires, j’hameçonne et tant pis pour celui qui se fera prendre .

[Invité]

Que pensez-vous des restrictions de Google ?

Normal qu'il mette des conditions pour une certification, tout projet open source à besoin de financement, alors pour Google il faut son ROI.

[Saverok]

Comme dit par beaucoup d'autres, Google assure juste son ROI.
L'interdiction du fork me choque un peu car la certification Android s'applique sur un seul modèle de téléphone.
Les constructeurs doivent faire certifier chaque modèle indépendamment les uns des autres.
Alors que l'interdiction d'un fork s'applique au constructeur, pas au téléphone en cours de certification.
Lorsqu'on interdit le fork d'un logiciel open source, est-ce encore de l'open source ?

Hormis ce point, rien de choquant.
En revanche, je suis nettement plus curieux de voir les contrats que signent Microsoft avec les constructeurs de téléphones sous Android.
Car là, pour le coup, ça sent l'abus à plein nez.

[Uther]

Alors que l'interdiction d'un fork s'applique au constructeur, pas au téléphone en cours de certification.
Lorsqu'on interdit le fork d'un logiciel open source, est-ce encore de l'open source ?

Le fork de la partie open-source d'android n'est pas interdit. Il entraine juste la perte du droit d'utiliser la partie non libre.

[BugFactory]

Il n'interdit pas les forks, ce qui serait en effet contraire au libre mais il précise que les fork n'auront pas la certification de Google.

Merci pour cette précision. A lire l'article, toutefois, on dirait plutôt que Google interdit aux fabriquants d'avoir un smartphone Android ET un autre utilisant un fork. Autrement dit, une fois qu'un partenaire a créé un smartphone Android, elle n'a plus le droit de faire un fork de la partie libre. C'est ce que je qualifie d'abus.