C’est à nouveau cette époque de l’année : Google publie la première préversion de sa nouvelle version d’Android 14. Comme toujours, les débuts ne sont pas explosifs et les nouveautés sont – on s’en doute – destinées aux développeurs.
La version 13 d’Android avait surtout marqué par sa capacité à apposer un thème uniforme et coloré sur l’ensemble de l’interface. Mais en dehors de quelques nouveautés, cette mouture était relativement tranquille.
Android 14 Developer Preview 1 (DP1) est disponible depuis hier soir pour l’ensemble des Pixel à partir du modèle 4a. Il est déconseillé de l’installer si vous n’êtes pas directement concerné(e) par les apports, car la qualité du code est comparable à une alpha, donc avec un grand nombre de bugs potentiels. Et même sans bugs (c'est très improbable), les chances restent élevées qu’une application devienne incompatible.
N'espérez pas non plus l’installation en OTA avec une simple case à cocher. Il faudra passer par Android Flash Tool et installer manuellement le système. En revanche, ce dernier recevra ensuite les mises à jour automatiquement. La solution la plus simple pour explorer les nouveautés est encore de récupérer la dernière préversion d’Android Studio et de lancer son émulateur.
Quoi de neuf docteur ?
Les nouveautés, parlons-en. Elles sont pour l’instant assez discrètes et concernent surtout des modifications dans les API et des changements de comportements.
Par exemple, le niveau d’API minimal passe à 23 pour les applications. Google explique que ce niveau, apparu avec Marshmallow (Android 6.0 !), a introduit des sécurités supplémentaires. Selon la firme, de nombreux malwares visent en conséquence le niveau 22.
Les alarmes exactes ne seront plus automatiquement accessibles aux applications non plus. La permission SCHEDULE_EXACT_ALARM ne sera plus accordée et il faudra demander l’accord de l’utilisateur. On trouve aussi du changement pour le chargement dynamique des composants, allant tous dans le sens des restrictions. Google encourage d’ailleurs les développeurs à ne pas charger de code dynamiquement, mais la porte reste ouverte. Dans le cas où une application vise Android 14 et utilise le Dynamic Code Loading (DCL), tous les fichiers concernés doivent être marqués comme en lecture seule. Dans le cas contraire, le système présentera une erreur (exception).
Google fournit un guide pour ce cas de figure. La société conseille de supprimer et de recréer les fichiers avant de retenter leur chargement dynamique sur Android 14. Il reste possible de marquer les fichiers actuels comme en lecture seule, mais il est alors recommandé de vérifier leur intégrité avant. Ceci pour s’assurer que l’on n’enferme pas un code malveillant sous clé.
Il semble clair également qu’Android 14 mettra un accent particulier sur les tablettes. Dans son billet d’annonce, Google indique que le nouveau système récupère les améliorations d’Android 12L et 13 dans ce domaine et leur ajoute de nouvelles classes pour la taille des fenêtres, un layout pour panneau coulissant, l’intégration d’Activité, etc. Le « guide de qualité » pour les écrans larges a été mis à jour, et Google semble nettement pousser dans cette direction. Les applications de niveau 1 (sur 3) seraient ainsi celles prévues pour tous les cas de figure, y compris les Chromebook.
On trouve quand même quelques améliorations plus directement visibles par les utilisateurs. Par exemple, Android 14 va introduire une mise à l’échelle non-linéaire des polices jusqu’à 200 %. Selon Google, les applications intégrant déjà ce type de mécanisme ne devraient pas rencontrer de problème, mais des tests sont conseillés pour le 200 %.
D’autre part, l’API Grammatical Inflection fait son entrée pour simplifier les retours textes dans des langues prenant en compte le genre grammatical. L’exemple donné est d’ailleurs en français. Un homme recevra ainsi un message commençant par « Vous êtes abonné à... », tandis qu’une femme aura « Vous êtes abonnée à... ». Un genre neutre est également disponible, transformant le message en « Abonnement à… activé ».
Enfin, Android 14 intègre l’API Credential Manager, qui apporte entre autres la gestion des passkeys. Rappelons que ces dernières doivent prendre la relève des mots de passe classiques, une initiative pilotée par Apple, Google et Microsoft, sous l’égide de la FIDO Alliance.
La suite du programme
Il y aura au moins une autre Developer Preview le mois prochain.
Ce n’est qu’en avril qu’une première bêta sera publiée. Cette fois, le système devrait commencer à intégrer suffisamment de nouveautés visibles pour que les personnes en mal d’aventure se lancent. Il y aura plusieurs bêtas, dont les sorties s’étaleront jusqu’à l’été. À noter que les personnes ayant encore un appareil avec Android 13 Beta peuvent simplement attendre deux ou trois mois que la première d’Android 14 arrive sur les serveurs. Elle sera alors récupérée automatiquement.
À partir de juin, la plateforme devrait être considérée comme stable. C’est le moment où Google insistera sur la nécessité de tester les applications, car les API ne seront plus amenées à changer, du moins fonctionnellement.
La version finale, elle, arrivera à l’automne, comme d’habitude et sans plus de précision.
Commentaires (10)
#1
On parle aussi de borner la possibilité d’installer n’importe quel apk
#1.1
C’est implicite par le fait d’augmenter la version API minimale nécessaire et c’est expliqué dans ton article. Les APK qui ciblent plus vieux qu’Android 6.0 ne pourront plus être installées.
Ca me semble raisonnable comme comportement
C’est pas comme si Google imposait d’utiliser Android 12 quoi 
#1.2
Fin 2015 Android 6… Google est presque trop gentil a ce niveau.
#1.3
Ça dépend… J’ai un téléphone que je prévoyais de donner à Ëmmaus ou similaire qui vient brutalement de devenir obsolète par cette annonce.
Enfin techniquement il est sous Android 6, cependant je doute que les développeurs vont corriger leurs apps à chaque montée de l’API minimal, il vaut mieux sauter plusieurs niveaux de suite en misant sur le concept du 80%/20%.
#1.4
Le passer sur une rom custom résout le problème, non ?
LineageOS, Pixel Experience, etc. A voir si ton téléphone est supporté par ces OS et jusqu’à quelle version d’android.
#1.5
Oui mais au bout de 10ans on atteint les limites, j’ai commenté trop tard sur un autre post, si vous avez 2min pour exposer vos avis ça serait fort aimable.
#1.6
Honor 6X. C’est faisable mais ce n’est pas souhaitable : il était prévu pour être donné. LineageOS peut lourdement bugger et l’usager lambda ne saura pas gérer ça.
Il y a bien une méthode pour le faire passer en Android 8 officiel mais cela suppose de le faire passer pour un device prévu pour le marché indien afin de pouvoir le flasher, car il n’y a pas de ROM officielle européenne. L’opération peut potentiellement le briquer.
Reconditionner ou réparer est positif écologiquement. La livraison de pièces ne coûte pas tellement en CO2 par la mutualisation des envois, et on évite la fabrication d’un smartphone neuf.
Par contre oui, il faut clairement acheter du haut-de-gamme aujourd’hui pour maximiser les chances que ce soit faisable demain, et surtout le garder exploitable. J’ai un Samsung S4 (2013) ainsi qu’un Samsung Tab S2 (2015) updaté par LineageOS, la réactivité reste acceptable malgré leur âge.
A l’inverse en bas-de-gamme, j’ai un Honor 6X (2017) et un Samsung Tab 3 (2014) et… mouais. J’ai pû flasher la tablette avec un peu d’effort mais la lenteur est légendaire, il peut s’écouler plusieurs secondes entre chaque action.
Après on peut tenter de leur trouver des usages non-conventionnels mais ça dépend du matériel. Il est possible de relier un Raspberry PI à un smartphone via VNC par exemple, ce dernier servirait donc d’écran…
Mais ce qu’il faudrait, c’est forcer à la standardisation de certaines pièces ou connecteurs, de façon à permettre une réutilisation même au delà du smartphone. Il faut contraindre les fabricants de pièces à libérer leurs pilotes après quelques années afin de faciliter le travail de LineageOS. Etc.
#1.7
Merci.
Sur le fond je suis d’accord avec le haut de gamme, quitte à prendre une seconde main, plus abordable. Le gros problème à mes yeux reste les batteries collées qui sont la norme.
Pour les usages fin de vie secondaire, il y en a tellement.
#2
J’ai des anciens jeux qui ne vont plus s’installer :(
#2.1
Tu as toujours Bluestacks qui est bloqué à de vieilles versions d’Android (la 11 est seulement en beta… !). Sinon en alternative, perso j’ai conservé mon précédent smartphone pour le garder en “console de jeux”. Sa batterie et son port USB-C sont faiblards, mais ça fait le taff d’ici qu’il claque pour de vrai.