Depuis de nombreuses années, le développement d’Android est fait sous deux formes différentes : une partie ouverte au public, où chacun peut voir l’avancée du code et de ses modifications, appelée AOSP (Android Open Source Program), et une autre interne à Google, qui ne voit son code publié qu’une fois finalisé.
Mais les choses devraient changer avec Android 16, selon AndroidAutorithy : Google souhaiterait en effet passer tout le développement d’Android en interne, et ne lâcher le code sur AOSP qu’une fois celui-ci totalement finalisé.
Pourquoi ce changement ? Selon Google, le développement de deux branches à la fois de son système apporte des complexités inutiles, qu’il est facile de comprendre : les deux parties ont un mode de fonctionnement radicalement différent, avec le côté AOSP qui avance au fil des propositions d’ajout des développeurs indépendants en plus de l’équipe interne de Google, ce qui peut apporter des décalages, spécialement quand un patch de sécurité doit sortir. Ainsi, le code utilisé pour les deux versions ne sera pas forcément implémenté de façon identique, ce qui implique une double charge de travail.
Si le changement est important, il devrait cependant passer inaperçu pour les utilisateurs finaux. En effet, très peu de personnes travaillent directement avec la dernière version d’AOSP. Cependant, quelques impacts sont à prévoir selon la catégorie d’utilisateurs :
- comme dit plus haut, les utilisateurs finaux ne verront aucun changement.
- les développeurs d’apps ne seront pas vraiment impactés non plus, travaillant avec une version stable du système, et non les dernières évolutions d’AOSP.
- les équipes de développement des marques de smartphone n’y verront pas un gros changement non plus, étant en contact avec les équipes de Google ne serait-ce que par leur licence GMS (Google Mobile Services, qui donne entre autres accès au PlayStore et aux apps Google).
- les développeurs de versions « custom » se basant rarement sur les dernières sorties d’AOSP n’y verront pas d’inconvénient non plus.
- la communauté de l’Open Source, elle, devrait être la plus déçue : elle se retrouve dans l’impossibilité de voir, et de la même manière de participer au développement de la plateforme, le code ne leur étant plus accessible avant sa parution finale.
- enfin, les journalistes spécialisés vont aussi se retrouver limités, ne pouvant plus détecter quelques pépites laissées dans le code d’AOSP permettant de prédire le futur de la plateforme.
Le changement, s’il est d’importance symboliquement, ne devrait donc pas vraiment impacter une grande partie des utilisateurs. Google avait deux possibilités, en dehors du maintient du fonctionnement actuel : tout passer en interne, ou tout passer en ouvert. Comme pour des raisons de concurrence la dernière possibilité est écartée d’office, c’est le passage en interne qui a été logiquement choisi. Même si la communauté Open Source sera bien entendu déçue, ce choix était le plus pragmatique pour rationaliser le développement et limiter les pertes de temps, avec le bonus non négligeable de limiter les fuites.
