Fonctionnement des mises à jour android, segmentation choix futurs ?

[helloworld]

Bonjour à tous

j'ai vraiment apprécié honyecomb. Avant je suivais l'évolution d'android de loin, cette fois ci de beaucoup plus près, surtout avec honeycomb.

je me pose quelques questions sur le fonctionnement d'android, notamment à propos des mises à jour et des droits utilisateurs.

Sur un windows, vous récupérez les maj des serveurs microsoft

Sur une ditribution linux, les maj se font via des dépôts contrôlés par les sociétés qui gèrent (suse, cannonical, redhat...)

Les maj qui tardent à venir sur android en fonction des fabriquants me laisse penser que l'os est préconfiguré pour que les dépôts de maj soient "pointés" vers des serveurs motorola ou samsung ou autre...et que les terminaux sont livrés en mode "user" d'où les questions suivantes :

Google entretient il des dépôts de maj de son os comme le ferait par exemple cannonical avec ubuntu ?

Google fournit il un android nu aux fabriquants, qu'ils configurent à leur manière de sorte que les maj ne se fassent que via leurs serveurs ? par exemple, si demain sur un transformer je veux passer à honeycomb 3.2, seul asus update me le fournira ? (hormis les versions "rootées") Finalement on part d'un os libre censé apporter plus de libérté et on se retrouve dépendant du bon vouloir de la politique d'un fabriquant

Pour l'instant google ferme le code d'honeycomb et on a l'impression qu'ils sont autour d'une table en train de réfléchir sur une direction à donner. Une question me vient d'ailleurs à ce sujet, si android 3 est fermé, aucun fabriquant ne devrait pouvoir le modifier, donc aucune raison que asus ou samsung décident de quand je dois faire ma maj vers une autre version. ...je ne sais pas

Android a un potentiel énorme et peut aller concurrencer windows sur les ordinateurs portables . D'ailleurs avec windows 8, microsoft vont faire le chemin inverse. je serais curieux de voir comment vont il gérer les fabriquants à propos des surcouches et des maj . A ma connaissance windows ont toujours été les seuls à contrôler les maj de leurs os (hormis les windows mobiles surchouchés dont je ne connais pas trop la politique)

Je pense que google doit prendre les devants des fabriquants et maîtriser la configuration de son os de A à Z. je veux bien que les fabriquants puissent se démarquer. Il peuvent proposer des interfaces différentes oui mais pas ajouter des surcouches au code initial ou proposer sur leurs propres serveurs "leurs android". L'android market n'est il pas un dépôts google qui pourrait fournir la maj du système ?

Avec google, android a et aura une puissance technique certaine, mais il faut une politique claire. Pourquoi pas un OS sous le control direct de google et une politique des droits utilisateurs selon la configuration ? (un ice cream qui reconnait automatiquement le terminal et qui selon que cela soit une tablette, un notebook ou un smartphone donnerait des droits d'accès différents) ps : je sais qu'il sera adpatable aux deux mais cela concerne t il aussi une nouvelle politique des droits ?

[Azathot]

Pour faire simple : Android est (quasi) libre.

Si on doit comparer à linux, plusieurs différences apparaissent.

- Android n'est pas créé par une communauté. Conséquence : Google libère le code quand il le décide.

- Android (à l'exception des Nexus) est livré sans pilotes. Conséquence : il est livré aux constructeurs pour qu'ils les intègrent au système avant distribution aux utilisateurs finaux. Pour les Nexus, Google a signé des accords avec les constructeurs (HTC puis Samsung) pour intégrer directement les pilotes eux même et par conséquent, les mises à jour sont assurée d'être plus rapides.

- Google laisse à la discrétion des constructeurs la possibilité de bloquer le bootloader de leurs terminaux. Bien qu'ils fassent petit à petit machine arrière, cette politique leur a permis d'éviter les mises à jour non officielles de leur terminaux, avec double but de contenter les opérateurs qui craignent les retours SAV de téléphones briqués et de pérenniser l'utilisation de leur interface maison (ce ne sont pas des surcouches, comme cela pouvait être le cas avec WinMo).

Le cas d'Honeycomb est un peu particulier.

Jursqu'alors, le code source était libéré quasi instantanément après l'annonce d'une mise à jour. La communauté pouvait alors se pencher dessus pour cuisiner des roms en intégrant les pilotes récupérés de leur terminal. Cela n'est toutefois pas forcément très aisé car les constructeurs peuvent décider de partager ou non leurs pilotes et leurs interfaces maison qui ne sont en général pas libres. Il en va d'ailleurs de même pour les applications natives de Google (market, gmail, etc).

Depuis Honeycomb, un niveau supplémentaire de difficulté a été ajouté du fait de la non libération de son code. Mais, bien évidemment, les développeurs de ROM ont su contourner le problème (qui d'ailleurs est quelque peu effacé par la très grande similitude matérielle des tablettes tournant sur ce système). Ainsi, sur l'Acer iconia tab, on voit arriver des ROMs issues du code de l'Asus eeepad.

Le vrai tournant se fera lors de la sortie d'Ice Cream Sandwich. En effet, cette version est sensée être le point de réunification des deux versions aujourd'hui parallèles Gingerbread et Honeycomb.

Deux possibilités se présentent alors :

- Google libère le code comme avec toutes ses versions smartphone, ce qui confirmerait les raisons officielles données à la non libération du code : à savoir garder la main sur un système neuf dans un marché concurrentiel (iOS pour ipad étant bien plus abouti car plus ancien).

- Google emploie la même politique que celle d'Honeycomb. Cela voudrait dire que sous la pression des autres parties de l'OHA, Google ferme petit à petit son code.

Petit workflow simplifié :

[helloworld]

Merci Azathot pour la très bonne synthèse

 Google laisse à la discrétion des constructeurs la possibilité de bloquer le bootloader de leurs terminaux. Bien qu'ils fassent petit à petit machine arrière, cette politique leur a permis d'éviter les mises à jour non officielles de leur terminaux

le bootloader étant un chargeur d'amorçage, en quoi cela évite t il de bloquer les mises à jours ?

au risque de me répéter :

les constructeurs pointent ils les maj vers leurs serveurs dédiés ? (sorte d'asus update pour eeepad par exemple)

et si oui par quel moyen ? si c'est via le bootloader, comment cela est il possible ?

Ainsi, sur l'Acer iconia tab, on voit arriver des ROMs issues du code de l'Asus eeepad

corrigez moi si je me trompe, les os classiques type fedora ou windows sont écrits sur un disque dur classique (et viennent juste après le bootloader)

si oui

Android est il différent par le fait qu'il soit écrit sur une ROM, donc n'est pas contenu dans la mémoire fournie mais sur une puce dédiée ?

le workflow est très pédagogique

En aurais tu pour d'autres os et notamment pour windows 8 ?

Cela voudrait dire que sous la pression des autres parties de l'OHA, Google ferme petit à petit son code.

Je ne comprends pas, j'aurais tendance à penser le contraire vu que tous les membres de l'alliance voudront un système ouvert qu'ils pourront bidouiller à souhait

[Azathot]

Le blocage du bootloader permet d'empêcher les Roms customs car il empêche l'accès au recovery. Ce dernier est un mode de boot permettant des opérations de flashage dans un but de récupération du système. Or, le recovery de base ne permet l'installation que de Roms officielles.

Déroulement d'une mise à jour OTA :

• Téléchargement d'un fichier appelé update.zip signé (c'est à dire crypté avec une clé) sur un serveur du constructeur (dans le cas d'une vente de type 4 bis de mon workflow) ou de l'opérateur dans le cas d'une "customisation" de la Rom par l'opérateur.
  
• Redémarrage en mode recovery
  
• Le recovery flashe le système de lui-même
  

Pour une Rom custom, on commence par flasher le recovery (ie en installer un nouveau) qui permet plus d'opérations et permet d'installer des Roms ayant des signatures différentes.

Pour ce qui est de la comparaison avec les autres système d'exploitation, il n'y a pas de différence matérielle. Tout vient de la structure des partitions.

Là où windows ne nécessite qu'une (ou deux) partitions et où nos distributions linux de bureau sont souvent sur deux ou trois partitions, le système Android en utilise beaucoup plus.

Je te laisse te faire une idée ici : https://www.droid-developers.org/wiki/CDT

Au niveau matériel, seule la mémoire interne (en grande majorité de la mémoire flash) contient des informations persistées (exceptées les informations de simlockage et encore...).

Pour le workflow, c'est le seul que j'ai pour la bonne raison que je l'ai réalisé en 5 minutes (et je me rends compte qu'il pourrait être amélioré). Windows 8 n'est pas encore sorti, il serait donc prématuré d'imaginer comment cela va fonctionner. Mais, au vu de la stratégie historique de Microsoft, on a de bonne raisons de penser que le processus sera globalement centré sur lui.

Enfin, la dernière remarque est importante. L'OHA regroupe (en gros) :

• Google : créateur du système
  
• Des constructeurs
  
• Des opérateurs
  

Ce qu'il faut bien voir c'est que la pression de fermeture remonte depuis le bas de cette classification. Les opérateurs sont (en très grande majorité et d'autant plus en France) les vendeurs finaux des terminaux. Ils ont donc toujours milité dans ce sens au sein de l'alliance pour des raisons officielles et officieuses.

Officiellement :

• Les systèmes non-officiels seraient plus consommateur de data (ce qui reste à prouver)
  
• Les erreurs de manipulations dans le système seraient générateur de plus de retour SAV (ce dont je doute aussi) : d'où la perte de garantie sur des systèmes bidouillés
  

Officieusement :

• Les opérateurs modifiant le système veulent imposer leurs applications et ne veulent surtout pas d'un moyen permettant de les supprimer
  
• En verrouillant certaines possibilités du système, ils peuvent contrôler et donc facturer certains usages (le tethering par exemple)
  

C'est donc pour cela qu'on a pu voir certains opérateurs faire publiquement pression sur les constructeurs ayant annoncé le déverrouillage de leurs terminaux. Ces derniers se retrouvent entre deux feux (opérateurs d'un côté et consommateurs de l'autre) ce qui peut expliquer des dérapages de communications non contrôlés.

[helloworld]

Salut azathot !

Pour le workflow, c'est le seul que j'ai pour la bonne raison que je l'ai réalisé en 5 minutes

franchement, je le trouve très bien fait et clairement utile dans un forum expliquant le fonctionnement d'android

je voudrais rebondir sur cette partie, assez technique tout de même :

[size="3"]Là où windows ne nécessite qu'une (ou deux) partitions et où nos distributions linux de bureau sont souvent sur deux ou trois partitions, le système Android en utilise beaucoup plus.
Je te laisse te faire une idée ici : https://www.droid-de...rs.org/wiki/CDT
Au niveau matériel, seule la mémoire interne (en grande majorité de la mémoire flash) contient des informations persistées (exceptées les informations de simlockage et encore...).[/size]

Pour faire simple, une ubuntu installe son grub sur l'amorce puis la partiton racine et le home (que l'on peut mettre en partition séparée ou pas, idem pour pour /etc )sur le disque dur.

Pour android, j'ai noté que l'on parle souvent de ROM.

Sur pc, la rom est assimillée au bios et contient le firmware. Pourquoi assimile t on tout android à la ROM ? c'est ce que je ne comprend pas

à propos de l'OHA

si ces derniers font pression pour un android fermé, comment peuvent ils y accéder pour le verrouiller ? en y ajoutant dans programmes ?

je vais essayer de voir si je trouve des explications sur le fonctionnement d' IOS et windows phone7. (à comparer au workflow)

Ceci étant, ce qui est intéressant avec honeycomb est que l'on quitte progressivement le monde du smartphone et la présence des opérateurs se rétrécira.

Et toi qu'en penses tu ?

Avec l'eeepad transformer, on a pratiquement un petit ordi. Le poids de l'opérateur est insignifiant sur ce segment.

google doit il à ce moment se recentrer sur lui même et tout dicter au constructeurs comme un os classique pour desktop ?

parce que finalement, comme ce qui est décrit, toute l'organsation est finalement conditionnée par les opérateurs (notamment le bloquage du tethering) mais leur poids s'arrête au smartphone.

[Azathot]

Merci pour le workflow :)

Pour les ROMs, il y a une confusion de vocabulaire. ROM veut dire Read Only Memory et par extension est devenu ce qu'on installe sur cette mémoire (à savoir le disque dur), c'est à dire l'OS. Une bonne explication (en anglais) ici : http://limitlessdroid.com/2010/08/19/rooting-101-custom-roms/

Le BIOS, tel qu'on le connait sur un PC, n'existe pas. Les rares fonctionnalités communes se font directement en compilant le noyau (linux kernel).

Pour revenir sur la politique et sur Honeycomb, je vois plusieurs raisons pour la fermeture.

• Comme je l'ai dit plus tôt, Google veut à mon avis limiter tout bidouillage qui nuirait à l'image d'un système neuf. Peut-être même que le code n'est pas montrable (de gros hack dans le code par exemple)
  
• En effet, la pression des opérateurs est moindre du fait que seule la xoom possède une connectivité 3G. En revanche, les caractéristiques sont tellement proches que chacun veut garder sa spécificité.
  

Le cas d’Honeycomb est donc un peu particulier du fait de sa nouveauté et de son segment à part.

Mais j'espère que tout reviendra à la normale avec Ice cream sandwich.

[helloworld]

salut à tous

salut azathot

j 'essaie de trouver du temps pour lire un peu l'actu

je tombe sur cette info concernant les versions non officielles de...honeycomb...apparemment fermé ou pas, la tradition des rom alternatives persiste.

[/url]

Pour résumer, si j'ai bien compris, une "rom" alternative est un fork d'android ou plutôt un os basé sur android. (comme le serait une ubuntu par rapport à une debian ou une mint par rapport à une ubuntu)

Donc si le code d'android honeycomb est fermé, "Minimalist 3.1 et HonneyVillain" seraient des os illégaux comme le seraient certains dérivés "piratés" d'XP.

à propos de la politique, c'est vrai que ce n'est pas tout à fait clair :

pour l'instant, google livre un os brut à un constructeur ou à un opérateur qui en a l'emprise via un blocage des fonctionnalités et une mise en évidence d'autres. Cela aboutit donc à une inertie du système (les maj passent par leurs serveurs, impossible de passer officiellement en root...)

qu'en est il de windows phone et ios et de leur politique par rapport aux opérateurs ? ce lien donne un début d'explication

finalement, pour Ios, tout passe par leur serveur (logique )

android, c'est un peu tout le monde y met la patte. Google conçoit et sfr ou htc assurent les maj.

windows phone 7 : ça reste assez opaque. A priori, les operateurs et les contructeurs n'ont pas d'emprise sur le système, techniquement verrouillé. Les maj se font via des serveurs windows.

je cite : Et quand je dis "poussé sur tous les terminaux", c'est absolument tous. Un avantage indéniable de la solution de Microsoft sur d'autres systèmes concurrents, car en effet il a été imposé aux constructeurs et opérateurs mobiles que les mises à jours de Windows Phone 7 soient impérativement gérés par Microsoft ("poussé" directement depuis leurs serveurs), sans aucune interventions possible de leurs part (enfin, contractuellement les opérateurs peuvent refuser une mise à jour, mais pas la suivante), ce qui permet d'avoir un parc homogène et ainsi éviter la fragmentation des versions, un vrai casse-tête pour les développeurs, mais également une source de frustration en moins pour les utilisateurs, comme ça, pas de jaloux :)

là au moins, les operateurs peuvent ne modifient pas le système.

j'étais à deux doigts de m'acheter un eeepad, mais devoir dépendre d'asus pour les maj et la gestion de mon os me rebute franchement. Donc je me contente de mon dual boot xp/suse pour l'instant où je peux gérer mes droits administrateurs et mes dépôts

En ce qui me concerne, mon seul interlocuteur pour l'os doit justement être le concepteur de cet os. Un operateur me vend un service et un fabriquant du matériel. Je n'ai rien contre les personnalisation (facultatives)

dernier point à clarifier :

A propos de la femeture d'honeycomb. Cette dernière en théorie nuit autant au petit flasheur qu'aux grands "flasheurs" que sont les opérateurs. CAr lorsqu'android était ouvert, rien n'aurait empêché un operateur d'installer une rom à leur gôut d'android sur un terminal X. SI honeycomb est fermé, ils doivent absolument passer par des accords avec google pour avoir un accès sur l'os.

Donc, je ne comprend pas l'interêt des operateurs à une fermeture d'android 3

[helloworld]

pas de windowsphone7 sur tablettes

je trouve l'approche de windows intéressante sur ce point. Windows 8 sera destiné aussi bien aux tablettes qu'aux pc. Les smartphones restent un produit traité différemment, probablement parce que les opérateurs auront toujours leur mot à dire sur ce segment.

[helloworld]

salut !

je remonte ce topic d'autant plus utile avec l'actualité récente et le rachat de motorola mobility par google.

Le schéma d'azathot plus hait explique le fonctionnement d'android

mais il restait une question : cela s'applique t il au téléphone nexus ?

si pour les constructeurs ou opérateurs commercialisant un androphone, les maj passent par leur serveurs (j'imagine qu'ils modifient les dépôts de "leur" android), qu'en est il des nexus ? Les androids "vanilla" de ces derniers pointent ils librement vers les serveurs google update ?

Quelques infos sur le fonctionnement des windows phone

Mon lien

en gros, windows centralise et donne toujours les maj via ses propres serveurs microsoft update.

l'opérateur ne peut pas bloquer techniquement la maj (comme pour android) mais plutôt contractuellement. microsoft update détecte le matériel et l'opérateur j'imagine

[thebogoss885]

Bonjour, et bien si il existe des tablette tactile avec Windows 7... bon c'est des tablette non officielle.