Google sur Android : L'open source sous contrôle absolu

Par franck_29 - Le 9/11/13 - Affichages : 10232

Bonjour,
je vous propose aujourd'hui, pour la seconde fois, la traduction d'un article qui m'a paru intéressant. Et ce, sous deux aspects.
Le premier, car on lit souvent ici ou là que Samsung veut s'extraire de son lien avec Google, nous verrons qu'en analysant un peu les choses cela n'est pas si simple que cela. Le second, concerne le caractère "open source" d'Android. Et dire cela, suffit bien souvent, à la plupart d'entre nous de dire, bah c'est open source, au pire on peut forker, et bien nous verrons là encore que cela est loin d'être aussi simple.
Au final, nous verrons que google impose sa poigne de fer sur android, bien qu'il soit "open source".

L'article original est disponible à l'adresse : Google’s iron grip on Android: Controlling open source by any means necessary (la poigne de fer de google sur android : contrôler par tous les moyens nécessaires un développement open source")

Image

Retour arrière : Nous sommes en novembre 2007, le projet Open Source Android (AOSP) est annoncé. Le premier iPhone vient à peine de sortir, ce dernier ouvre l'ère des smartphones modernes? Bien que google était alors un partenaire, fournisseur d'applications pour l'iPhone, il n'en a pas moins pris conscience de ce que serait un futur ou l'iPhone règnerait en maître, sans concurrence. Vic Gundotra, rapportant les propos de Andy Rubin lors de la conception initiale d'Android, déclarait :

Si google n'avait pas agi, nous aurions été confronté à un avenir draconien, dans lequel votre unique choix aurait été dicté par un seul homme, une seule entreprise, avec un seul smartphone fourni par un seul opérateur"


Google était terrifié à l'idée que Apple parviennent à contrôler totalement le marché de la mobilité. Alors, pour tenter de lutter contre Apple, à une époque où Google n'avait strictement aucun point d'appui dans le domaine de la mobilité, Android a été lancé comme un projet Open Source.
A cette époque Android ne pesait quasiment rien, Google a donc décidé de donner gratuitement Android et l'a utilisé comme cheval de Troie pour ses "Services Google". L'idée était que si un jour, la "recherche google" était exclue de l'iPhone, les gens cesseraient également d'utiliser la recherche Google sur leur ordinateur. Android était donc les douves protégeant le château "Google Search", sa raison d'être était donc de protéger les acquis de Google dans le monde de la mobilité.

Image

Aujourd’hui, les choses sont quelque peu différentes. Parti de zéro, Android représente aujourd'hui près de 80% du marché des smartphones. Android a sans aucun doute gagné la guerre des smartphones, mais "Victoire d'Android" signifie-t-il "Victoire de Google", en effet Android est Open Source, et Android n'appartient donc pas vraiment à Google, Chacun est en effet libre cloner le source et de créer son propre fork ou sa propre version "alternative".

Comme nous l'avons vu dernièrement avec les difficultés de Windows Phone et de BlackBerry 10, les applications mobiles sont décisives dans ce marché, et l'énorme base installée d'android signifie une énorme quatité d'applications disponibles. Si une compagnie décidait de forker Android, le nouveau système serait effectivement compatible avec ses millions d'applications, elle n'aurait qu'à déployer son propre "market" et y faire mettre toutes les applications disponibles. En théorie, l'opération durerait une nuit, et vous auriez des tonnes d'applications disponibles sur un système non-google. Si cette entreprise autre que Google parvenait à faire un android meilleur que ce qu'il n'est, elle pourrait constituer une concurrence redoutable et potentiellement menacer la suprématie de Google. C'est le principal danger pour la position actuelle de Google : une distribution Android alternative à succès!

Et effectivement certaines entreprises se sont risquées à se séparer d'Android. La version alternative ayant rencontré le plus de succès est sans conteste la Kindle Fire d'Amazon. Amazon a pris les sources AOSP, en a ôté les principaux "add ons" Google, et a fourni son propre "app store", son propre contenu, son propre navigateur", son propre service de stockage en ligne et de messagerie. La chine a également mis de côté toutes les parties Google d'Android. La plupart des services Google y sont bannis, aussi la seule solution est d'en proposer des versions alternatives. Dans les deux cas, Le code d'Android est utilisé et Google n'en retire absolument rien.

A force de donner, Android ne risque-t-il pas et de finir en dernière place avec zéro part de marché, précisément là où il a commencé ? Quand vous occupez la première place, il est un peu plus difficile d'être "open" et accueillant. Android est passé du statut de "protecteur de Google" à celui d'un système méritant, pour lui même, d'être protégé : le futur de l'internet est la mobilité, et contrôler la plus vaste plate-forme mobile recèle des tas d'avantages.
Il est pourtant trop tard pour revenir sur l'idée d'Open Source, alors une question se pose : Comment contrôler un projet Open Source ?

En fait, Google s'est toujours protégé contre des versions alternatives d'Android. En fait, ce que la plupart des gens pense, c'est qu'android se compose de deux catégories, la première issue de l'AOSP, qui est le fondement d'Android, et la seconde, du code fermé, composé des fameuses applications Google. Et même si Google ne fermera jamais complétement Android, il semble qu'il fasse tout son possible pour se donner des leviers sur le code open source, et la principale méthode employée est d'apporter de plus en plus d'applications "fermées" made by Google.

Privatisation progressive de l'Open Source

Avec Andoid, il a toujours eu des applications Google "fermées", à l'origine il s'agissait d'applications clientes des services en ligne de Google, par exemple Gmail, GMaps, GTalk et YouTube. Quand Android représentait 0 part de marché, conserver ces seules applications et construire le reste d'android comme un projet Open Source était une solution confortable. Aujourd'hui, Google a décidé qu'il avait besoin de plus de contrôle sur la partie ouverte du code d'Android.
Pour certaines de ces applications, il se peut qu'il y ait toujours un équivalent AOSP, mais dès lors qu'une version "propriétaire" était fournie, tous les travaux sur la version AOSP étaient stoppés. Moins de code source disponible, implique plus de travail pour la concurrence. Car si il n'est pas possible de "tuer" une application Open Source, il est possible de contraindre à son abandon en déplaçant toutes les efforts de développement sur la version équivalente au modèle fermé. Ainsi, à chaque fois que Google renomme une application, ou livre une nouvelle composante d'Android au sein de son Play Store, c'est le signe évident que le source en a été fermé, et que la version équivalente AOSP est morte.

Search

Image

Nous commencerons avec l'application "Recherche", qui est un excellent exemple de ce qui se passe quand Google duplique une fonction AOSP.

En aout 2010, Google a lancé "Voice Actions". Ce faisant, la compagnie a introduit "google seach" sur l'android marcket (pas encore renommé en play store), c'était à l'époque de Froyo. L'illustration ci-dessus montre la dernière version de la recherche AOSP aux côté de la recherche "fournie" sur Android 4.3. Ainsi qu'on peut le voir, la version AOSP est toujours "scotchée" à l'époque de Froyo (Android 2.2). Dès lors que Google eut terminé son application "source fermé", il a immédiatement abandonné la version AOSP. La version Google dispose de la recherche par la voix, la recherche audio, des capacité de lecture de texte (text-to-speech), une capacité de réponse à des questions et le fameux "Google Now", la fonctionalité de prévision personalisé. La version AOSP peut faire des recherches WEB et locales, et ... c'est tout.

Music

Image

C'est lors du Google I/O de 2010 que Google à présenté son service de musique sur le cloud. C'est à cette date que l'application AOSP "Music" a été gelée. Aujourd'hui, cette dernière ressemble toujours à une application Froyo.
"Google Play Music" peut accéder au cloud google de stockage de musique, ainsi qu'à un magasin de musique en ligne gigantesque. "Google Play Music" a en outre subit plusieurs évolutions importantes côté design, obtenant au passage un égaliseur ainsi que le support de Chromecast. Les deux applications (ndt : AOSP Music et Google Play Music) sont tellement différentes aujourd'hui, qu'il est difficile d'imaginer qu'un jour elles n'étaient qu'une.

Calendar

Image

Google Agenda (ndt : calendar) est l'une des dernières applications à avoir reçu ce traitement de "fermeture des sources". La façon dont la manipulation est présentée à la communauté est toujours assez amusante : "Le calendrier android, est désormais disponible pour tous ! La mise à jour est disponible sur le Play Store ! Avec plein de fonctionalités supplémentaires (Oh, au passage, le source est fermé désormais)
Comme c'est un "split" récent, il y a encore peu de différences entre les deux versions. L'application Google Agenda peut synchroniser au travers de différents équipements (ndt : Smartphone, tablettes, PC etc...), et dispose d'une nouvelle icône. Je ne m'attends pas à ce que la version AOSP propose ces évolutions avant longtemps.

Keyboard

Image

Même l'application "clavier" n'est pas à l'abri d'une "fermeture de source". Il y a quelques mois, Google a ajouté une fonctionalité de swipe (ndt : saisie de texte en glissant avec son doigt d'une lettre à l'autre) au clavier Android. Cet ajout a été réalisé via une nouvelle application disponible sur le Play Store : "Google Keyboard". Devinez où se trouve le code source de cette application? Certes pas dans l'AOSP. L'illustration montre les paramétrages possibles des deux claviers. L'application Google Keyboard propose naturellement des paramétrages pour la saisie en mode swype, à l'inverse de la version AOSP. Elle a été abandonnée aussitôt la version "Google Keyboard" rendue disponible.

Gallery / Camera

Image

L'appareil photo et la galerie sont en fait une unique application (un APK Android Application Package). La version AOSP s'appelle "Gallery2.apk", tandis que la version Google se somme "GalleryGoogle.apk". Comme l'illustration précédente le montre, la fonction photosphère est une exclusivité de la version Google - ce mode innovant de prise de vue n'est pas disponible dans la version AOSP (ndt : open source). De même, la version open source n'intègre pas non plus l'intégration avec les albums Google Plus (Le comportement normal de la nouvelle galerie est d'afficher les albums G+ à côté des albums locaux).

A ce point toutefois, nous devons rendre à Google un certain crédit (ndt : sic). Tandis que la version AOSP n'a bien sûr pas intégré ces nouvelles fonctionnalités, le nouveau "design" introduit avec Android 4.3 l'a été dans le code source d'Android.

Le futur

Image

Alors qu'elle n'a pas encore été délivrée, la prochaine application en ligne de mirre, juste derrière la porte est l'application Android SMS. Et bien que des gens se paments avec ferveur pour que Google Hangouts intègre les messages textes et concurrence de fait iMessage (ndt : application iphone), il faut savoir que ce faisant, vous poussez à transférer la fonctionalité SMS (ndt : évidemment de base dans Android) vers une application au code source fermé.
Une fois que Google aura fait la bascule, ma prédiction est que dans une ou deux versions d'Android, l'appication SMS aura disparu des applications par défaut. Un peu de la même façon dont Google a procédé lorsqu'il a tué le navigateur web par défaut au profit de Chrome (bien que Chrome soit toujours Open Source)
Quand Hangouts intégrera les SMS (ndt : c'est fait), l'application AOSP SMS d'android sera définitivement abandonnée, elle est d'ailleurs a mi-chemin de la retraite. (elle n'a subi aucune mise à jour significative depuis sa refonte graphique liée à Android 4.0). Et quand cela se produira, vous saurez lire entre les lignes : l'application Open Source SMS sera définitivement "morte".

Image
(Gauche: KitKat, montrant l'icône "Google Photos." Droite: l'icône actuelle de "G+ Photos")

Dernier point, à propos de la galerie. Dans une image fuitée de KitKat, la prochaine version d'android (ndt: version non encore officielle lord de la sortie de cet article) on trouve une nouvelle icône intitulée "Google Photos". "Galerie", qui normalement selon l'ordre alphabétique, devrait être entre "E-Mail" et "Gmail", est étrangement absente. Bien que nous n'ayions jamais vu "Google Photos" auparavant, il partage la même icône que l'application "G+ photos". Il semble que l'application Gallery de l'AOSP soit en train de mourrir au profit d'un service à code fermé dépendant lourdement de "Google Plus". C'est le dernier avatar en date sur le chemin du nouveau jardin clos de Google.

La mise sous contrôle des constructeurs

Alors, comme on l'a vu, Google dévoie autant qu'il est possible la composante Open Source d'Android, mais agir du côté "applications" de l'équation n'est pas le seul levier à la disposition de Google dans ce jeu de pouvoir.

Si une entreprise, voulait malgré tout "forker" l'AOSP, clôner les applications Google, et devenir une concurrent viable à l'android de Google, il se trouve qu'elle aura bien du mal à trouver un constructeur pour lui construire un smartphone capable de recevoir ce nouvel OS. Dans un marché ouvert, cela serait assez simple de solliciter un constructeur et de le convaincre de basculer, mais, Google est là pour rendre les choses un peu plus compliquées que cela. Le vrai pouvoir de Google réside dans le contrôle des applications Google (ndt : les google apps), principalement Gmail, Maps, Google Now, Hangouts, YouTube et le Play Store. Ce sont des applications phares d'android (ndt : killer apps) et les grands constructeurs veulent ces applications dans leurs smartphones. Et puisque que ces applications ne sont pas Open Source, elle doivent obtenir une licence de Google. Et c'est à ce point que vous voyez se dessiner une scène "du parrain", car en effet, ces applications nécessitent quelques ... pré-requis...

Image

Bien que cela ne soit pas un pré-requis officiel, obtenir une licence pour installer les Google Apps vous sera bien plus facile si vous faites partie de l' "Open Handset Alliance". l'OHA est un groupement d'entreprise engagées dans Android -Celui de Google- Et pour ses membres il est contractuellement interdit de construire des appareils non approuvés par Google. Et c'est vrai, pour une entreprise, rejoindre l'OHA signifie de renoncer à vie à, consturire un smartphone équipé d'un fork concurrent de l'android officiel.

Acer, s'est retrouvé face à cet engagement quand il a essayé de construire un smartphone équipé de Alibaba's Aliyun, un OS Chinois. Aliyun est en fait un fork d'android, et quand Google a eu vent de cette affaire, Acer s'est vu convaincre d'arrêter le projet sous peine de perdre son accès aux Google Apps.
Google a même publié un post officiel sur son blog a propos de cette affaire :
"Bien qu'Android demeurre libre pour quiconque veut l'utiliser comme bon lui semble, seuls les équipements compatibles Android peuvent bénéficier de l'écosystème Google complet. En tant que membre de l'OHA, chaque membre contribue et construit une plateforme Android - pas un ramassis de versions incompatibles"


Cela rend la vie extrêmement difficile pour la seule société occidentale assez effrontée pour vendre un fork d'Android : Amazon. Puisque l'OS du Kindle compte au rang de "version incompatible d'android", aucun constructeur de renom n'est autorisé à construire le Kindle Fire pour Amazon. Aussi, quand Amazon s'est mis en recherche d'un constructeur pour sa prochaine tablette, il a immédiatement dû rayer de sa liste : Acer, Asus, Dell, Foxconn, Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, et ZTE. En fait, Amazon s'est tourné vers Quanta Computer pour construire sa tablette, une entreprise donnant dans l'assemblage d'ordinateurs portables. Amazon n'a sans doute eu guère d'autres choix.

Pour les constructeurs, cela signifie qu'ils ne peuvent pas migrer en douceur de Google Android vers un quelconque fork. Cela veut également dire que s'ils vendent ne serait-ce qu'un seul équipement doté d'un fork concurrent d'Android, ils recevraient le "baiser de la mort" et se verraient bouter hors de la famille Android - cela doit être une rupture claire. De fait, pour un constructeur Android, basculer vers une version forkée d'android est une perspective rien moins que terrifiante, vous devez sauter de la falaise Google, et il n'y a pas de retour arrière possible.

Tout constructeur envisageant de déployer les Google Apps devra passer les tests de compatibilité de Google pour y être autorisé. La compatibilité est censée assurer que les applications du Play Store pourront fonctionner sur tout appareil Android. Pour Google, cette "compatibilité" est en fait un concept "adaptatif" qu'un ingénieur Android a en off décrit comme "un club pour forcer les constructeurs à faire ce que nous voulons". Et bien que Google a désormais complètement automatisé le test de compatibilité, obtenir une licence pour utiliser les Google Apps, nécessite que l'entreprise le désirant "baise l'anneau" du roi Google. La plupart de ces accords sont des accords bilatéraux tenus secrets, de sorte que l'information à notre disposition vient surtout de querelles publiques et ou de poursuites judiciaires entre Google et les déserteurs potentiels (voir Acer).

Un autre levier de Google réside dans le fait que les Google Apps sont licenciées sous forme d'un bundle (ndt : un paquet) unique. Ainsi si vous souhaitez Gmail et Maps, vous devrez aussi prendre Google Play Services, Google Plus et tout ce que Google voudra bien ajouter au paquet. La compagnie Skyhook l'a appris à ses dépends quand elle s'est attelée au développement d'une solution de géolocalisation concurrente pour android. Une bascule vers le service de Skyhook signifiait en fait pour Google qu'il ne pourrait plus collecter les informations de localisations des utilisateurs. Pas très bon pour Google, qu'à cela ne tienne, Skyhook s'est donc vu déclaré "incompatible", ce constructeur qui voulait déployer les Google Apps n'a donc pas été autorisé à le faire, Skyhook a été poursuivi en justice, et le procès dure toujours.

Tâter le terrain avec le Bloatware

Pour la plupart des équipementiers, abandonner l'écosystème Google et continuer avoir du succès n'est qu'une chimère. Une voie possible pour un constructeur souhaitant se préparer à une vie sans Google, sans risquer les foudres de Montain View est de produire des versions alternatives des Google Apps. C'est ce que la plupart d'entre nous rejette comme étant du "bloatware". En fait ce bloatware est le résultat logiciel de l'exercice "et si nous n'avions pas les google apps", une réplication de toutes des google apps principales pour voir à quoi ressemblerait la vie en dehors du "jardin clos"

Image

Samsung fait un travail particulièrement abouti dans cet exercice, il va jusqu'à proposer à l'utilisateur d'avoir son propore login mot de passe sur l'infrastructure Samsung, ainsi que des service de synchronisation Samsung et son propre market. Il maintient également l'ensemble le plus complet d'alternatives aux Google Apps. Bon nombre d'entre elles (ndt : les alternatives) comme Internet, E-Mail et Calendrier ont leur racine dans l'AOSP, simplement, Samsung a continué à leur ajouter des fonctionnalités bien longtemps après que Google les ait abandonné au profit d'alternatives fermées.

Sur un téléphone disposant des Google Apps, il semble stupide et redondant de disposer de deux applications calendrier. Pourtant, beaucoup de constructeurs voit leur bloatware, comme un important plan B stratégique, au cas où les choses iraient vraiement mal. Si google dépassait la ligne jaune, et forçait de fait un constructeur à quitter, ce constructeur doit avoir quelque chose à montrer à ses clients. Les équipementiers incluent ces alternatives dans les téléphones qu'ils vendent (pourquoi? et alors, pourquoi pas ?) et en obtiennent de précieux retours utilisteurs. Et tandis qu'ils créent de la redondance, et ajoutent à la confusion des utilisateurs, une faible part aimera ces versions alternatives.

Avec une telle liste d'applications alternatives, il pourrait sembler que Samsung est sur le point de quitter le navire à tout moment. Mais en fait, répliquer les Google Apps n'est qu'une petite partie de l'effort considérable à consentir pour s'affranchir de l'écosystème de Google. En fait, l'aspect qui intéresse le plus le constructeur, c'est le choix gigantesque d'applications tierces disponibles pour Android. Google sait parfaitement que c'est sa plus grande faiblesse, aussi s'est-il (Google) engagé dans une voie visant à rendre cet écosystème des applications tierces, lui aussi, dépendant de Google.

Verrouillage dans les applications tierces

Image

Nous avons précédemment exploré les implications de la mise à jour "Play Services", mais c'est en réalité, une arme de destruction massive contre les forks d'Android. Play Service est une application au code source fermé, propriété de Google et licenciée comme une partie du bunddle Google Apps.Toute fonctionalité migrant de l'android "Normal" vers un service Google Play, s'accompagne en même temps d'une migration Open Source vers un code source fermé. L'astuce permettant d'offrir de nouvelles fonctionalités à l'utilisateur (et de fermer le code source au passage) se double d'une capacité de verrrouiller les développeurs tiers sur des API Google également propriétaires.

Clôner l'écosystème des applications tierces de Google semble facile : ne suffit-il pas de bâtir un App Store, de convaincre les développeurs d'y déposer leurs applications et c'est fini ? En fait non, car les API Google, intégrées au services "Play" sont toutes faites pour convaincre les développeurs de tisser aux même un lien de dépendance avec Google, et ce lien il est intégré au code de leurs applications. La stratégie de Google avec ses Services Play est de transformer l'ecosystème "Android App" en un écosystème "Google Play", en rendant la vie des développeurs la plus simple possible sur un équipement "Google Approved", et aussi difficile que possible sur un équipement qui ne l'est pas.

Si vous utilisez n'importe quel élément de l'API Google et que vous tentiez de faire tourner votre application sur un Kindle, ou sur n'importe quel système non Google (AOSP) : surprise ! Votre app ne fonctionnera pas. En fait, les developpeurs sont surtout intéressés par la rapidité de développement, par le fait que leur application fonctionne bien, et, qu'elle atteigne une large audience. Les API de Google permettent cela, avec comme effet de bord, que votre application est désormais dépendante d'un smartphone disposant d'une license Google App.

Les API Google MAPS

L'API Google Maps vous permet d'utiliser des données de Google Maps dans votre application. C'est extrèmement pratique quand il s'agit de faire figurer la météo par dessus la carte d'un trajet dans une application de voyage. Le seul problème c'est qu'il s'agit d'une composante des services Google, pas une composante d'Android. Se baser sur l'API Google Maps sous-tend donc que votre application ne focntionnera pas sur un smartphone ou une tablette non approuvée par Google.

En réponse à cette situation, Amazon a du se résoudre à licencier les données de cartographie de Nokia et de développer un clone des API Goocle Maps. Amazon propose même une page d'instructions spéciale pour aider à la migration de votre application basée sur Google Maps. Une fois encore, Google fait tout son possible pour faciliter la vie dans son propore écosystème et de la rendre extrèmement difficile si l'on en sort. Si vous voulez fonctionner sur le Kindle, vous devez maintenant supporter deux API de cartographie différentes.

C'est une situation terrible pour le forker Android, dans ce cas, Amazon a maintenant le choix de payer des licences d'utilisation à Nokia à vie, ou alors de sortir cartographier entièrement la planète avec ses propres moyens. Amazon doit aussi, dorénavant, suivre le rythme infernal de développement de Google: l'API Amazon's Maps supporte l'API Google Maps v1, mais Google en est aujourd'hui à la v2. Si vous êtes développeur et dépendez de quelque nouvelle fonctionalité disponible en Google Maps v2, Amazon ne la supporte pas encore. Maintenant, vous avez encore plus de travail à faire.

Google Cloud Messaging

Image

Google Cloud Messaging (GCM) est le moyen le plus simple pour pousser (push) des notifications sur Android, cependant vous ne verrez pas ce système dans l'AOSP. GCM a été récemment ajouté aux services Play lors du Google I/O de 2013, et il inclut désormais, non seulement les notifications entrantes mais également la capacité dite de "Pushing messages upstream". C'est ce qui a apporté la possibilité nouvellement ajoutée, de synchroniser des notifications au sein de multiples équipements. Les developpeurs utilisent souvent ce GCP pour pousser (ndt : en mode push) des "breaking news" ou pour notifier une application qu'un nouveau jeu de données est disponible et qu'une nouvelle synchronisation est souhaitable.

Alors que Google Maps pourrait être considéré comme ne concernant qu'un petit nombre d'applications, bien plus d'applications ont besoin d'échanger des messages en mode push pour être d'une quelconque valeur. C'est une autre des fonctionalités que Amazon a du se résoudre à copier afin de ne pas être laissé de côté. Sa version s'appelle "Amazon Device Messaging", et ne fonctionne que sur les terminaux Amazon. De même que pour l'API Maps, vous devrez, en tant que developpeur, travailler plus pour tester votre application pour finalement un sur-ensemble très restreint d'utilisateurs. Toutes les fonctionalités de CGM se seront peut être pas disponibles dans la version d'Amazon, vous aurez encore une charge supplémentaire pour traiter ces manques éventuels.

l'API de localisation

Image

Lors du Google I/O de 2013 Google a toiletté l'API Android de localisation et l'a intégré comme composante de Google Play Services. En d'autres mots, les services de localisation d'Android sont désormais en source fermé. Et si l'histoire décrite plus haut se confirme, la pile logicielle (AOSP) de localisation sera laissée à "pourrir". Les fonctionalités ajoutées incluent le "Fused Location Provider", une réecriture complète des algorithmes de localisation d'Android, le Geofencing (ndt : non traduit) (qui vous laisse définir une localisation sur une carte qui va générer des évènements vers une application quand l'utilisateur atteindra cette localisation), et la reconnaissance d'activité, qui utilise les données de l'accéléromètre et des algorithmes pointus pour déterminer si l'utilisateur marche, fait du vélo ou conduit -tout cela sans l'aide du GPS-

Cela fait bien évidemment sens de mettre les API Maps et GCM dans un modèle propriétaire dans la mesure où ces services reposent sur les serveurs Google pour fonctionner. Quoi qu'il en soit, avoir déplacé l'intégralité de la pile logicielle de localisation, ressemble à une prise de pouvoir massive de la part de Google. Il y a désormais deux façons pour obtenir la localisation d'un usager : la bonne, économe en batterien en mode source fermé selon Google, et la seconde, mauvaise, couteuse en batterie mais en mode open source.

L'achat "In App"

La mailleure façon d'implémenter un achat au sein d'une application se réalise à l'aide du google Play Store. Si un développeur veut que son application fonctionne sur un Kindle ou en Chine il devra quoi qu'il en soit trouver une autre solution. Cette autre solution doit être répliquée, c'est ce qu'a fait Amazon avec son API Amazon In-App Purchasing. Samsung est également de la partie, il a introduit une fonctionalité d'achat In-App voilà maintenant deux ans.

Jouer

Image

Play Games est une autre API propriétaire résolvant beaucoup de problèmes difficiles pour les développeurs. Elle procure un accès simple aux comptes des utilisateurs, leurs classements, leurs niveaux, les sauvegardes dans le cloud, la lutte anti-piratage et une capacité multi-joueurs en temps réel. Le meilleur c'est que cela fonctionnne à peu près partout : Dans une web apps, sur IOS et bien sûr sur Android. En fait partout sauf sur l'AOSP, qui n'est pas supporté. C'est là encore une fonctionnalité importante dont pourraient dépendre les applications et qu'une version alternative d'android se devrait de répliquer.

Amazon dispose d'un ensemble d'API dédiée aux jeux appelé "GameCircle", mais ce n'est pas un simple clonage de "Play Games" à l'image de l'API Amazon Maps. Un développeur devra passer un temps considérable pour faire fonctionner une implémentation multijoueur spécifique rien que pour l'Android d'Amazon.

Le support d'iOS comme dépendance supplémentaire envers les API Google

Le part géniale (limite google is not evil) de la stratégie de Google est que 90 % des API Google sont également supportées sur iOS. Maintenant mettez vous dans la peau d'un développeur devant choisir d'utiliser ou pas les API Google : La plupart des solutions Google sont d'un excellent niveau en terme de facilité d'utilisation, de fonctionnalités, et de facilité de développement. Google supporte les deux platteformes mobiles principales, et couvrira un très large pourcentage de votre base d'utilisateurs potentiels. La seule ombre au tableau sera que cela ne fonctionnera pas sur un fork Android, sachant qu'un fork AOSP ne représentera finalement qu'une portion infime de votre cible d'utilisateurs.

La plupart des développeurs diront probablement "Oui" aux API Google, et la prochaine question qui leur viendra sera "Que faire pour la Kindle et les autres forks Android?" Les developpeurs sont largement livrés à eux même pour trouver des API de remplacement, qui seront finalement peut-être périmées et ne fonctionneront peut-être pas avec leurs développements, si ces solutions de remplacement ne sont pas des parfaits clônages, et qui obligeront les développeurs à trouver des solutions de contournement aux fonctionalités manquantes. Puisque seule une infime partie d'utilisateurs est concernée si l'on compare avec la base iOS et Android ( ndt : + Google), cela vaut-il simplement la peine de considérer ces écosystèmes alternatifs? Procureront ils un retour sur investissement? N'est-il pas plus simple de dire "au diable les fork d'android" et de tout simplement éviter le travail supplémentaire, et le complément de support (reponses aux questions etc...) que cela entrainerait?

Samsung ne va nulle part

C'est la section qui montre pourquoi Amazon peut vivre sans Google et pas Samsung. Tandis qu'Amazon est une machine à copier les API Google, Samsung ne propose en revanche que peut de réponses aux développeurs tiers se reposant actuellement sur Google. Toute spéculation sur Samsung quittant l'écosystème Google est prématurée tant que vous ne le verrez pas tenter d'obtenir une license pour des données cartographiques ou développer une API de messagerie dans le cloud.

Amazon a fait un travail considérable pour suivre, mais la compagnie est née sur l'internet. Les serveurs et le logiciel sont la force de l'entreprise, aussi constuire un nouvel assortiment de services dans le cloud n'est pas un changement fondemental. Samsung Electronics est, et bien une entreprise d'électronique - construire une infrastrcuture cloud ou une collection d'API n'est pas dans son ADN. Aussi alors qu'Amazon est capable d'absorber la charge en quelques années et de la faire endosser par sa propre plate-forme de services cloud, Samsung, pour sa part une véritable montagne à gravir.

Samsung a réalisé quelques progrès. Comme mentionné plus haut, l'entreprise dispose de son propre SDK pour l'achat In-App. de façon très intéressante, c'est également un SDK pour la publicité en ligne, pour générer de l'argent. Quoi qu'il en soit, Google supporte également la publicité en ligne sur Android (même les forks), iOS, et même sur Windows Phone.

Une ouverture en mode "regarder mais pas toucher"

Si une entreprise voulait forker Android pour créer un concurrent viable, elle devrait répliquer l'ensemble des points listés dans cet article. Et même alors, il ne se passerait sans doute rien. Il lui resterait à convaincre les utilisateurs de basculer depuis le Google Android vers le nouvel Android forké.

Google fait tout en interne. La compagnie offre en outre Maps et ses services de cloud pour pratiquement rien. Toute entreprise qui voudrait tenter de suivre devrait probablement externaliser une partie de l'important challenge. Amazon ayant aquis les droits d'usage des données cartographique de Nokia est un excellent exemple. Google vend des publicités sur Maps - et c'est profitable - tandis qu'Amazon en est réduit à payer pour chaque utilisateur des données cartographiques. C'est radicalement différent, gains dans un cas, dépenses dans l'autre, et c'est une situation à laquelle devra faire face au quotidien tout nouvel entrant. Les services Google ne coutent rien à Google, en revanche tout nouveau compétiteur devra imanquablement s'acquiter à un moment ou un autre d'une redevance mensuelle à une autre compagnie.

Si une entreprise parvenait à forker Android en une alternative crédible, en dehors de l'écosystème Android, resterait le petit problème de trouver un constructeur, la plupart étant contractuellement empêchés de construire un équipement capable de faire fonctionner le nouvel OS. Et même si le nouveau dérivé d'Android était meilleur, pour un constructeur, faire le saut en dehors de l'écosystème de Google, est probablement un risque bien trop important.

Alors qu'on dit d'Android qu'il est ouvert, c'est plus une impression d'ouverture en mode "regarder mais pas toucher" dont il s'agit. Vous êtes autorisés à contribuer à Android, et même à l'utiliser ... dans le cadre de "hobbies", mais dans presque tous les domaines, les dés sont pipés contre quiconque tenterait d'utiliser Android sans la bénédiction de Google. A la seconde où vous essaierez de prendre Android et d'en faire quelque chose que Google n'approuve pas, il fera s'écrouler le monde autour de vous.

Par Ron Amadeo du site arstechnica.com


32 réponse(s) -