Les prisonniers du développement Android chez Google

• Une petite opération de maintenance visant à relever le targetSdkVersion d’une application Android legacy pour répondre aux exigences de Google s’est transformée en crash en production sur Android 13 et en longue attente de validation sur Google Play
• Pour qu’une application existante continue d’être proposée aux utilisateurs d’appareils tournant sous une version d’Android supérieure à son niveau cible, elle devait viser l’API level 31 ou plus ; l’auteur est donc passé de l’API level 30 à 33 avant de déployer
• La première release a été approuvée en moins d’une heure, mais elle crashait juste après la connexion sur de vrais appareils Android 13, et il n’existait aucun moyen de rollback vers la version précédente fonctionnelle
• Le build correctif a été soumis juste après la modification du code, mais il est resté environ 72 heures en attente de validation, avant d’être finalement publié en production le 4 septembre, soit 11 jours plus tard
• Avec les applications mobiles natives, même quand on exploite soi-même le code source et l’infrastructure, le canal de distribution final reste contrôlé par les opérateurs d’app stores, ce qui limite les correctifs d’urgence, les rollbacks et la vitesse de déploiement

---

Une petite mise à jour du SDK tourne à l’incident de production

• La maintenance concernait une application Android legacy utilisée par un client
  • Ses fonctionnalités étaient stabilisées depuis des années et l’application n’était plus activement développée
  • Dans l’idéal, il aurait été préférable de laisser telle quelle la version stable existante
• Google a signalé par email le 18 août 2023 les exigences liées au niveau d’API Android
• Le point clé du message de Google était que, pour qu’une application existante continue d’être proposée aux utilisateurs d’appareils sous des versions plus récentes d’Android, elle devait viser l’API level 31 ou plus
• L’impact exact sur les applications déjà installées n’était pas clairement expliqué, et une interprétation prudente a conduit à traiter la mise à jour en priorité
• Il restait moins de trois semaines avant l’échéance, et Google n’avait pas envoyé de rappel plus tôt sur cette exigence

Passage de targetSdkVersion 30 à 33

• Le travail a commencé le 23 août, avec une hausse du targetSdkVersion de l’application de l’API level 30 à 33
• Le premier build a échoué à cause d’une dépendance d’analytics incompatible
  • Cette dépendance n’étant pas étroitement liée à la logique métier, il a été possible de la supprimer
• L’application a ensuite été exécutée sur un émulateur Android, et les fonctionnalités principales semblaient continuer à fonctionner comme avant
• Ce changement était une mise à jour de conformité à une politique, sans nouvelle valeur métier apportée

Premier déploiement sur Google Play et crash sur Android 13

• Le processus de déploiement sur Google Play s’est d’abord déroulé sans accroc
  • Comme cette application legacy n’était mise à jour qu’une ou deux fois par an, il a fallu répondre à plusieurs questionnaires
  • La release a passé la validation en moins d’une heure et a été déployée en production
• Le soir même, vers 21:30, le problème a été révélé quand le client a signalé que des utilisateurs ne pouvaient plus se connecter avec la nouvelle version
• En testant sur de vrais appareils Android, l’application crashait juste après la connexion
• Une enquête complémentaire a montré que le problème survenait sur Android 13, alors dernière version d’Android, tandis que les versions précédentes fonctionnaient normalement
• Lors du travail initial, seuls de vieux images d’émulateur avaient été testées, ce qui a empêché de voir le problème de compatibilité
• En testant plusieurs versions d’Android, le problème aurait pu être détecté
  • L’ampleur limitée du changement et la pression du délai ont donné un faux sentiment de confiance, mais l’insuffisance de la couverture de test était bien une erreur de l’équipe

Une structure de déploiement qui bloque le rollback

• La réponse initiale la plus sûre aurait été de restaurer la précédente release fonctionnelle et d’analyser le crash aux heures de bureau suivantes, mais Google Play n’offre pas cette possibilité
• Il n’existait aucun moyen de retirer la dernière release de production et de réactiver la version précédente
• L’option suivante consistait à remettre le targetSdkVersion à 30 et à publier un nouveau build avec un numéro de version plus élevé, mais Google Play l’a refusé
  • Les indications publiées semblaient laisser entendre qu’une cible plus basse restait autorisée jusqu’au 1er septembre, mais une erreur imposait que toute nouvelle mise à jour vise l’API level 33
• Une demande de prolongation permettant l’API level 30 jusqu’au 1er novembre a été déposée, mais l’erreur de publication est restée la même
• Le seul chemin possible consistait donc à corriger le crash sur Android 13 et à soumettre une nouvelle release

Correctif sous pression et longue attente de validation

• La version défectueuse se diffusait progressivement auprès des utilisateurs via les mises à jour automatiques, et plus le build correctif arrivait vite en production, plus le nombre de clients touchés pouvait être limité
• Le crash était reproductible sur un émulateur Android 13, et les changements de code nécessaires étaient limités
• Il a toutefois fallu travailler tard le soir sous pression, avec peu de temps pour effectuer une régression complète
• Le plan du moment relevait d’une réponse pragmatique
  • corriger tous les crashs connus
  • tester les parcours les plus critiques
  • soumettre immédiatement la version corrigée
  • poursuivre les tests plus larges et préparer si nécessaire une mise à jour supplémentaire
• Le nouveau build a bien été soumis à Google Play, mais il restait toujours en attente de validation après 2 heures, et il n’était toujours pas approuvé vers 01:00
• Le lendemain matin, l’application était encore in review
• La majeure partie de la journée a été consacrée aux tests sous Android 13 et à la vérification de la Google Play Console, ce qui a permis d’identifier puis de corriger quelques petits problèmes moins graves que le crash à la connexion
• À la fin de cette journée non plus, le correctif de production n’avait toujours pas été approuvé
• À ce moment-là, le build correctif attendait depuis environ 72 heures ; le code était réparé, mais le déploiement restait bloqué dans une file de validation opaque

Mise à jour ultérieure : validation, chat de support et déploiement progressif

• Le 27 août, l’auteur a publié un billet sur Hacker News, où la discussion a mêlé stratégies de release Android et critiques
  • Le billet est arrivé en page d’accueil et a reçu environ 130 000 visiteurs uniques sur quelques jours
  • Le site statique, hébergé sur un VPS coûtant environ 5 € par mois, a encaissé le trafic
  • Cette attention n’a pas entraîné de réaction de Google, et la mise à jour de l’application restait en validation
• Le 1er septembre, l’auteur a découvert le chat de support caché derrière l’icône en forme de point d’interrogation dans la Google Play Console
  • Le support a promis d’accélérer la validation, sans toutefois donner de calendrier clair ni de solution concrète
  • Il était frappant que personne n’ait mentionné cette possibilité dans l’importante discussion sur Hacker News
  • Vu la réputation d’accès difficile au support Google, les développeurs ne s’attendent peut-être même pas à obtenir de l’aide directe
• Le 4 septembre, la mise à jour corrective a finalement été publiée après 11 jours de validation
• Ensuite, au lieu de déployer immédiatement à 100 % des utilisateurs, une release de suivi plus petite a été soumise avec un déploiement progressif, et cette mise à jour a passé la validation en moins d’une heure
• Le 7 septembre, une autre petite mise à jour a été soumise pour remplacer la version qui avait atteint 99,9999 % des utilisateurs
  • Dès que cette nouvelle version est entrée en validation, Google a automatiquement interrompu le rollout précédent sans avertissement
  • Si cette nouvelle validation avait pris plusieurs jours, les utilisateurs restants n’auraient même plus reçu la release précédente
  • Même en retirant la nouvelle soumission, le rollout précédent n’était pas restauré
  • Heureusement, cette validation s’est terminée en moins d’une heure

Quand le contrôle de la plateforme change la responsabilité en production

• Les développeurs mobiles ont déjà connu de nombreux cas similaires où Google ou Apple retardent des correctifs urgents en production, retirent une application ou donnent très peu d’explications sur leurs décisions
• Même quand une équipe technique diagnostique et corrige rapidement un défaut, le moment où les utilisateurs reçoivent la solution reste contrôlé par les opérateurs d’app stores
• Les utilisateurs ordinaires peuvent ne disposer ni d’un rollback, ni d’un canal de distribution alternatif, ni d’un moyen fiable d’accélérer la validation
• Même si l’on possède le code source et l’infrastructure, la nature de la responsabilité en production change dès lors qu’on ne contrôle pas le canal de livraison final
• Quand une application mobile native n’est pas indispensable, les raisons de préférer la plateforme web ouverte deviennent plus fortes
  • Une application web peut souvent fournir les fonctionnalités nécessaires tout en laissant l’équipe gérer elle-même le déploiement, la supervision et le rollback
• Les applications natives gardent malgré tout des cas d’usage valides
  • dépendance aux fonctionnalités de l’appareil
  • fonctionnement en arrière-plan
  • nécessité d’une distribution via un app store
• Choisir le mobile, ce n’est pas seulement viser des avantages produit : c’est aussi accepter le coût opérationnel qu’implique l’intervention d’un tiers puissant dans le processus de release

[GN⁺]

Avis sur Hacker News

• J’ai reçu cet e-mail à titre personnel comme professionnel
  À titre personnel, je développe et maintiens bénévolement une application open source pour les systèmes de transport public de 16 villes, et j’ai dû mettre à jour 16 applications en deux semaines pour une tâche qui ne profite à personne.
  Mon application est une PWA, et la version Android consiste en Cordova avec quelques plugins ajoutant quelques options natives. Quand j’ai mis Cordova à niveau pour prendre en charge la nouvelle API Android cible, des plugins qui n’avaient pas encore été mis à jour ont cassé, et j’ai dû passer tout le week-end à travailler et à tester.
  Honnêtement, j’aimerais supprimer l’application et demander aux utilisateurs d’aller sur le site web pour installer la PWA, mais l’utilisateur moyen ne sait pas encore comment faire. Le premier endroit où les utilisateurs cherchent une application reste aussi le Play Store. Ce serait déjà bien si Google permettait de soumettre directement des PWA à l’app store, et je n’ai pas envie de répéter ça chaque année.
  Professionnellement aussi, nous sommes en train de réagir dans l’urgence. Nous avons une application legacy utilisée par une partie des clients pris en charge jusqu’à la fin de l’année ; c’est une application assez complexe, et le simple changement de version d’API cible a cassé plusieurs éléments dès les tests de base. Nous avons obtenu une extension, mais nous savons qu’une mise à jour qui n’apporte aucun changement fonctionnel, si ce n’est satisfaire Google, demandera une à deux semaines de développement et une à deux semaines de QA. Et ce, alors même que l’application sera officiellement retirée du store en fin d’année, une fois que tous les clients auront migré vers la nouvelle application.

  • C’est précisément pour ce genre de cas qu’existent les Trusted Web Activities (TWA). Elles permettent de publier une PWA sur le Play Store sans framework comme Cordova.
    https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
    https://developers.google.com/codelabs/pwa-in-play#0
  • Soyons clairs : ce n’est pas seulement parce que les utilisateurs ne savent pas comment faire. C’est parce que Google et Apple n’ont pas rendu cela aussi simple que l’installation d’applications depuis leurs propres app stores. C’est un choix, et un choix délibéré.
  • Je pense que vous comprenez mal les utilisateurs. Ce n’est pas qu’une question d’ignorance. J’aimerais que les applications redeviennent de vraies applications natives, c’est-à-dire autre chose que Cordova. Il existe très peu d’apps web qui égalent l’expérience d’une vraie application bien conçue, plutôt qu’un truc web bricolé à la va-vite.
  • Je compatis. Quelques-unes de mes applications personnelles ont aussi été touchées.
    Cela dit, cette échéance était annoncée depuis plusieurs mois, et il était évident qu’elle finirait par être affichée de façon plus explicite. Je n’ai pas aimé la formulation, et il était absurde de se plaindre que la version de production était correcte mais que la version de test ne respectait pas les critères.
    De plus, le problème a toujours été de pousser une nouvelle mise à jour, et c’est comme ça chaque année. Il était possible de garder l’application publique pendant un certain temps.
    Donc dire qu’il n’y avait que deux semaines n’est pas exact.
  • Je ne sais pas si cela aidera, mais si j’étais dans votre situation, je publierais quelques mises à jour de l’application en y ajoutant un écran expliquant comment installer la version PWA, afin de sortir progressivement de ces problèmes. Vous pourriez aussi fournir un formulaire de feedback sur les difficultés rencontrées par les utilisateurs.

• Je suis d’accord sur les difficultés du développement Android, mais l’auteur a commis deux grosses erreurs.
  Premièrement, il n’a pas testé l’application sur la dernière version d’Android. C’est une très grosse erreur, et c’est la raison pour laquelle nous maintenons 11 machines virtuelles pour toutes les versions d’Android que nous prenons en charge.
  Deuxièmement, quand on déploie une application sur Google Play, il ne faut jamais la distribuer d’emblée à 100 % des utilisateurs. Le déploiement progressif est la base ; après publication d’une release, nous ne dépassons pas 10 % des utilisateurs au début. Quand nous sommes confiants, nous la déployons à 99 %, pas à 100 %. Ainsi, si nous devons interrompre le déploiement pour une raison quelconque, il est facile de l’arrêter tant qu’il n’a pas atteint 100 %.
  Qu’on aime ou non, ces deux pratiques sont des tactiques bien connues des développeurs Android expérimentés.

  • Je suis d’accord qu’on aurait pu mieux faire sur plusieurs points. Mais comme je l’ai expliqué, il s’agit d’une application legacy, pas d’une application activement développée aujourd’hui, donc mettre en place un dispositif de QA aussi robuste n’a pas vraiment de sens. Cette application a été écrite il y a longtemps par une autre entreprise et ne possède même pas de tests unitaires simples. C’est la réalité.
    Mais même avec une infrastructure aussi complexe, des erreurs arrivent, et le vrai problème est qu’il n’existe aucun moyen d’annuler une release, de l’interrompre ou de revenir en arrière.
    Dans cette situation, en quoi le déploiement progressif aide-t-il tous les clients ? Quand un utilisateur final reçoit une version cassée, existe-t-il un moyen pour lui de récupérer une version qui fonctionne ?
  • Petite astuce : ce champ accepte aussi les décimales. Nous le réglons toujours sur 99,99999999 % afin qu’aucun utilisateur ne soit exclu par erreur. Et cela permet quand même, comme vous l’avez dit, d’annuler le déploiement.
  • Si l’on doit maintenir une machine virtuelle pour chaque version d’Android prise en charge, soit ; mais au final, on se demande quand même à quoi sert exactement la commission de 30 % sur les revenus.
  • Ça ressemble un peu à du blâme de la victime. Ces deux points ne devraient tout simplement pas poser problème au départ.
  • Ce que vous dites est tout à fait juste, et c’est la seule façon pratique de gérer les mises à jour et les releases. Mais il est regrettable qu’on ne puisse pas s’attendre à ce qu’une mise à jour d’API fonctionne simplement parce qu’elle compile.

• Je ne comprends pas les réactions qui acculent l’auteur du billet original. Bien sûr, il aurait pu être plus prudent, et tester la connexion sur le dernier Android. Mais si le crash ne concernait pas la connexion ? Et si ça fonctionnait sur la dernière version mais pas sur d’autres ? Où faut-il tracer la limite ?
  À un moment donné, il faut dire : « c’est littéralement une plateforme utilisée par des millions d’apps et des millions de développeurs ; les erreurs peuvent arriver, et il devrait être facile de les corriger, par exemple en remettant immédiatement en ligne une version précédente déjà approuvée, même si l’on ne sait pas arrêter sa propre distribution ou utiliser des astuces comme un déploiement progressif. » Surtout dans des lieux comme les app stores, rendre les choses réversibles et récupérables est un principe de conception fondamental.

  • Je suis l’auteur du billet original, merci de réfléchir avec moi. Comme je l’ai déjà dit dans plusieurs réponses, je suis entièrement d’accord sur le fait que j’aurais pu faire mieux côté tests. Bien sûr, il y a toujours matière à s’améliorer sur ce point.
    Google a fixé une échéance, et je le répète : je l’ai appris pour la première fois le 18 août, pas avant. Le changement semblait mineur à l’époque, et comme l’app fonctionnait comme avant sur les anciennes versions d’Android, je ne m’attendais pas à un échec aussi catastrophique.
    Je ne suis pas un développeur Android chevronné, mais j’ai plus de 15 ans d’expérience dans le développement logiciel en général, donc j’ai une certaine intuition de la manière dont les choses peuvent fonctionner, de ce à quoi il faut s’attendre et de ce qu’il faut craindre. J’ignorais vraiment que le déploiement progressif à 99,99999999 % était la bonne pratique si l’on veut conserver la possibilité de « retirer » au moins partiellement la dernière release.
    Je n’aurais jamais imaginé qu’il n’existe aucun moyen d’annuler ou de supprimer la dernière release pour revenir à la version précédente qui fonctionnait. On dirait qu’il faut vivre ce genre de situation pour l’apprendre.
    Vous pouvez me reprocher de ne pas avoir testé toutes les fonctionnalités sur toutes les versions d’Android, et je le pense aussi, mais j’aimerais que vous ouvriez les yeux et compreniez que la façon dont le Play Store gère actuellement les releases n’est pas une façon dont une personne raisonnable procéderait en dehors du Play Store. N’importe qui peut un jour rencontrer ce problème, et j’espère que ce billet et ce fil réduiront le nombre de développeurs qui se retrouveront dans une situation similaire.
  • « Et si ça marchait sur la dernière version mais pas sur une autre ? » est une excuse faible. Même pour une web app, il faut tester sur plusieurs navigateurs.
    Un smoke test sur une nouvelle release relève de l’éthique professionnelle de base.
    Un déploiement progressif avec rollback n’est pas non plus un concept nouveau.
  • Ne pas avoir fait de tests Android 13 en portant l’app vers Android 13, c’est-à-dire targetSdkVersion 33, est inexcusable.

• Le discours du type « revenons aux standards ouverts du Web pour reprendre le contrôle » peut changer quand on réalise que le Web est lui aussi à moitié contrôlé par Google, l’entreprise qui pose problème ici. Apple, avec Safari qui est de fait le seul navigateur sur iOS, n’est pas exactement un ami non plus.

  • C’est vrai aussi, mais au moins ce genre de problème peut se gérer avec des mécanismes comme un rollback. Ici, on sait qu’un mauvais build est en production et que les téléphones se mettent automatiquement à jour vers celui-ci, sans pouvoir rien faire. C’est ça, le pire.
  • Héberger sur le Web peut aussi demander plus de maintenance que le simple fait de payer des frais.
    Je préfère clairement un site Web à une app quelconque qui n’existe que pour mieux tracer les utilisateurs, mais ce billet m’a surtout donné l’impression d’un cas de maintenance faite à moitié à l’arrache.
  • Si vous refusez d’aller dans le sens qui privilégie la confidentialité et la sécurité des utilisateurs, alors Apple n’est clairement pas votre ami. Voilà une raison, si besoin.

• C’est une situation impossible à gagner
  Microsoft consacre des efforts énormes à la rétrocompatibilité, et c’est largement à saluer. Mais cela augmente aussi considérablement la surface d’attaque
  De même, une bonne partie des pires aspects de C++, souvent critiqués injustement, vient de sa position très stricte sur la rétrocompatibilité. Du code aussi ancien que possible, voire du vieux code C, doit continuer à compiler et à se comporter comme prévu, jusqu’à accepter de faire le lien avec de vieux binaires dont le code source a été perdu
  La plupart ne font pas autant d’efforts et invalident l’ancien au nom de la maintenabilité, de la fiabilité et de la sécurité
  Quel que soit le point de bifurcation choisi, quelqu’un en pâtira. Sinon, c’est que personne n’utilise ce code

  • Exact. C’est une facette du problème, et je ne demande pas non plus une rétrocompatibilité excessive. Dans cette situation précise, la plus grande inquiétude est que, sur Android, il n’existe aucun moyen d’annuler, de retirer ou de revenir en arrière sur une release, et que tout est bloqué derrière le processus de validation de Google
    Pourquoi est-il impossible de « retirer » une release problématique et de continuer à afficher la release précédente comme version la plus récente ? Dans ce contexte, cela résoudrait la majeure partie du problème
  • À mon avis, le compromis utile pour tout le monde serait de modifier l’API et de casser la compilation. Il suffirait que les développeurs corrigent les erreurs de compilation et utilisent correctement l’API
    Mais il ne faudrait pas changer le comportement d’une fonction existante ayant la même signature. Quand on fournit une API, on devrait faire de son mieux pour que la compilation ait un sens
  • Il n’y a pas de choix gagnant idéal, mais on peut aussi distribuer l’application séparément. Ce n’est pas une exigence d’Android, c’est une exigence du Play Store
    Dans beaucoup de cas, ce n’est pas du tout simple et cela ne sera jamais autant utilisé que la version Play Store, mais c’est bien qu’il existe une issue de secours
  • Il m’a semblé que la plainte principale de l’auteur portait sur le fait que Google joue le rôle d’arbitre de ce que les utilisateurs peuvent exécuter comme logiciel. Le problème de dépréciation des API n’est que l’élément déclencheur qui nous fait prendre conscience à quel point nous sommes devenus vulnérables aux caprices de Google
  • J’ai du mal à accepter cela comme excuse de la part de Google
    La plupart des applications déployées sur Android ciblent du bytecode Android. Ce ne sont pas des applications compilées nativement
    Si C++ crée des problèmes de sécurité difficiles à surmonter, c’est à cause de sa nature bas niveau et du fait qu’une fois qu’on a un binaire natif, l’histoire s’arrête là
    Mais avec le bytecode d’un langage à sécurité mémoire, pourquoi serait-il impossible de rétroporter des correctifs de sécurité ? Exécuter ce genre de code implique justement, par nature, de recompiler continuellement le bytecode
    Pour voir à quel point la position de Google est absurde, la JVM peut encore aujourd’hui exécuter et utiliser des classes ciblant Java 1.0, sorti en 1996
    Ce n’est pas un problème de sécurité, c’est un problème de « Google ne veut pas prendre en charge sa plateforme »
    Je peux comprendre dans une certaine mesure que Google soit plus strict avec les artefacts contenant du code compilé nativement. Mais une politique générale du type « l’app a été construite en ciblant une ancienne version d’Android, donc nous ne la prendrons plus en charge » n’a aucun sens. Cela ressemble davantage à une manière d’élaguer les vieilles apps du store qu’à une mesure de sécurité
    Cette politique, en particulier, transfère intrinsèquement une lourde charge de maintenance aux développeurs Android. Pour prendre en charge le plus largement possible une application, on finit par cibler la version d’Android la plus ancienne possible. Peu de gens ciblent les toutes dernières versions d’Android, par peur d’exclure trop de clients
    Si Google prenait vraiment au sérieux la sécurité et l’accès large aux technologies Android récentes, il chercherait à découpler le runtime Android de la version du système d’exploitation. Rien n’empêche de distribuer les runtimes ART et Dalvik via Google Play, comme d’autres parties de l’écosystème Android. Cela éliminerait aussi les situations absurdes du genre « pour faire ça, il faut Android 17… ah, le fabricant du matériel ne met pas les pilotes à jour »
    Mais cela nuirait aux ventes de nouveaux appareils, donc ce serait inacceptable, évidemment

• Il a toujours été évident que le Play Store et la « communauté » de développeurs enfermée dedans étaient un piège. Les mises à niveau forcées d’API n’en sont qu’un aspect
  Il y a clairement des tâches pour lesquelles les téléphones ou les apps mobiles sont les meilleurs : en général ce qui touche au déplacement, comme la navigation, ou ce qui dépend des capteurs du téléphone, comme déterminer quel côté est « en haut ». Mais presque tout le reste peut se faire avec un site web
  Pour un développeur solo qui maintient une app mobile multiplateforme, cela doit vraiment être pénible, et je compatis. Cela dit, comme j’ai décidé il y a longtemps que je ne voulais pas participer au jeu des plateformes propriétaires et des gatekeepers, je ne peux compatir qu’en tant que personne totalement extérieure

  • En réalité, même ces deux choses peuvent se faire facilement dans une app de navigateur
    Aujourd’hui, la seule chose qui ne soit presque pas facile à faire sur mobile, ce sont les compute shaders GPU. Mais quand WebGPU arrivera depuis les navigateurs desktop, cela tombera aussi
    Une autre chose qui me vient à l’esprit est la gestion générale des fichiers à l’échelle du système. Cela n’arrivera probablement jamais. La File System API permet bien à l’utilisateur d’accorder l’accès à certains répertoires, mais je ne sais pas si cette autorisation persiste après un rechargement de la page
  • J’étais convaincu que les app stores échoueraient. Je ne pensais pas que suffisamment de développeurs se rassembleraient au point d’abandonner la garantie de pouvoir réellement distribuer leurs propres apps
  • C’est drôle de lire ça sur un site qui attaque souvent Google parce qu’il ne fait pas assez de gatekeeping logiciel sur Android, et qui présente l’iPhone comme supérieur précisément parce qu’Apple contrôle plus agressivement
  • Vous ne voudriez quand même pas vous accrocher idéologiquement à la souveraineté des utilisateurs sur leurs propres appareils ? À la place, il suffit d’être intelligent et pragmatique, et de suivre le chemin de moindre résistance pour entrer dans l’enclos

• C’est ironique quand on pense que l’un des principes SRE de Google est que « les rollbacks sont normaux »
  https://cloud.google.com/blog/products/gcp/reliable-releases...
  « Chez Google, notre philosophie est que les rollbacks sont normaux. Si une erreur est découverte dans une nouvelle release, ou même raisonnablement soupçonnée, l’équipe de release commence par faire un rollback, puis enquête sur le problème. Une demande de rollback n’est pas interprétée comme une attaque contre l’équipe de release ou contre la personne qui a écrit le code bogué. Elle est au contraire comprise comme la bonne chose à faire pour rendre le système aussi fiable que possible pour les utilisateurs. Tant que la liste de changements du rollback décrit le problème observé, personne ne demande “pourquoi avez-vous annulé ce changement ?” »

  • D’après la situation de l’an dernier, le mélange entre les règles Google Play et les mises à jour Android fait que, si vous distribuez une app via le Play Store, la seule façon de faire un rollback est de désinstaller puis réinitialiser les données utilisateur
    Il est impossible de revenir à un versionCode inférieur, et le versionCode est défini par le développeur
    Android 11 interdit d’écrire dans le stockage « permanent » du téléphone, sauf via les exceptions pour les médias ou l’usage de l’API DocumentFile, qui traite un dossier local comme un stockage cloud. DocumentFile n’est pas utilisable dans de nombreux cas d’usage
    Le développeur peut définir hasFragileUserData, auquel cas il faut demander à l’utilisateur, lors de la désinstallation, s’il veut effacer ses données. Mais à cause d’un bug Google/Android, cette boîte de dialogue peut ne pas s’afficher
    Si l’app est désinstallée et que l’utilisateur n’efface pas les données, Android empêche le downgrade vers un versionCode inférieur
    Si l’on demande MANAGE_EXTERNAL_STRORAGE, on peut utiliser un java.io.File classique
    Google Play n’autorise MANAGE_EXTERNAL_STRORAGE que dans des cas exceptionnels
  • « Rollback pour moi, pas de rollback pour toi »

• La même chose m’est arrivée avec plusieurs apps basées sur un framework que j’avais créé. Une nouvelle version d’API entrait en conflit avec des dépendances existantes, et il a fallu un travail absolument énorme pour revenir exactement à l’état précédent
  J’en suis venu à avoir beaucoup plus de respect pour Microsoft, dont des trucs des années 90 tournent plus facilement sur Windows moderne qu’une app mobile que j’ai écrite pour Android il y a 4 ans

  • Si le framework utilisé ne vient pas de Google, c’est injuste de dire ça
    Tu ne vas pas reprocher à Microsoft le fait qu’Adobe Flash ne fonctionne pas dans le Store Windows 11, si ?

• Je pense qu’il y a énormément d’inconvénients, et très peu d’avantages, à être forcé de distribuer ses apps uniquement via une seule boutique d’apps « approuvée en interne ».
  L’avantage, ironiquement, serait que l’administrateur de l’app store vérifie l’absence de malwares et de virus avant publication. Mais les apps remplies de pubs Google et de trackers Google/Facebook sont accueillies sous toutes les formes.
  Il y a aussi le fait que cela facilite la recherche, l’installation et la mise à jour des apps pour les utilisateurs. À condition de réussir à trouver ce qu’on veut parmi des milliards de jeux et d’apps quasiment identiques publiées uniquement pour envoyer de la publicité ou collecter des données personnelles.
  L’inconvénient, c’est d’être soumis aux caprices de l’administrateur de l’app store, et de ne pas avoir le contrôle du processus de publication de l’app. Ce n’est pas moi qui décide si je peux publier une app, ni quand ; c’est l’administrateur de l’App Store qui décide selon ce qui l’arrange. Je pense que ce droit ne devrait appartenir qu’aux utilisateurs.
  Pour une app native commerciale, par exemple une app de banque à domicile, j’aimerais pouvoir me connecter à un espace privé sur le site du développeur pour la télécharger. L’app devrait être signée avec GPG et permettre de vérifier l’intégrité du paquet. Une fonction de mise à jour automatique serait aussi possible.
  Pour les apps open source, il y a la boutique F-Droid, et l’on peut y ajouter ses propres dépôts. J’admets que c’est un peu technique et que cela ne convient pas à tout le monde. Ce serait d’une grande aide si F-Droid était préinstallé sur les nouveaux téléphones, mais je doute que Google l’autorise.
  Une autre option réaliste, ce sont les PWA. À mon avis, très peu d’apps ont réellement besoin de fonctionnalités natives, et presque tout le reste peut être fait avec les technologies PWA. Il n’est même pas nécessaire d’envoyer des mises à jour aux utilisateurs ou de leur demander de faire une mise à niveau.
  Les app stores propriétaires et commerciaux, exploités sous prétexte de simplifier la vie des utilisateurs et d’offrir une « meilleure sécurité », sont un « excellent » moyen pour Apple et Google de gagner des milliards de dollars sur le travail des développeurs indépendants et, dans le cas de Google, de collecter et vendre les données personnelles des utilisateurs et de vendre de la publicité de toutes les manières possibles.

  • Tu as oublié un autre avantage : garder le Boston Strangler[0] hors de chez toi. Si tu attaches les mains de l’utilisateur dans son dos, tu peux décider dans quelles conditions il utilise ton travail. Pas de piratage, pas de blocage de pubs.
    C’est pour cela que les développeurs de jeux des années 80 et 90 ont largement suivi le modèle « Licensed by Nintendo », et que les développeurs d’apps mobiles de la fin des années 2000 ont fait exactement la même chose avec l’iOS App Store. Ils ne veulent pas collaborer directement avec les utilisateurs pour contourner le propriétaire de la plateforme. Ils veulent que le propriétaire de la plateforme attache les mains des utilisateurs, et acceptent au passage d’avoir les leurs attachées aussi.
    Prenons par exemple le cas d’une app bancaire : la banque veut une attestation distante sûre. Elle veut empêcher les utilisateurs qui lancent des attaques de credential stuffing contre l’app, empêcher des malwares d’ouvrir l’app bancaire et d’appuyer sur le bouton « envoyer de l’argent à un escroc », empêcher les utilisateurs d’extraire les secrets cryptographiques liés au tap-to-pay, et empêcher l’injection de secrets volés dans l’app du téléphone.
    L’app ne peut pas vérifier elle-même que les mains de l’utilisateur sont attachées. Il faut un tiers de confiance, présent dans la chaîne de démarrage ou en EL3, fiable pour la banque plutôt que pour l’utilisateur. Ce qu’elle veut, ce n’est donc pas simplement te fournir une app et une signature : elle veut que Google fasse en sorte que Google puisse attacher les mains de l’utilisateur.
    Il est important de noter que tous les avantages des app stores côté utilisateur sont des rationalisations a posteriori. Dès le départ, l’objectif était de ligoter les utilisateurs. Parce que, pour eux, les utilisateurs sont de petits moustiques voleurs. C’est la « partie silencieuse » qu’ils ne disent pas à voix haute.
    J’espère vraiment que la proposition WEI de Google ne deviendra pas réalité et que les PWA n’auront pas accès aux fonctions d’attestation. Google sort déjà des absurdités du type « vous ne pouvez pas vous connecter depuis un navigateur inconnu », et ce cancer n’a pas besoin de se propager.
    F-Droid est excellent. Les manigances de Google sur Android doivent être stoppées. L’UE aurait pu le faire, mais les États-Unis doivent aussi le faire et faire en sorte que cela s’applique au niveau international.
    [0] Nom de code que la MPAA utilisait pour désigner la copie non commerciale à petite échelle, c’est-à-dire l’enregistrement d’émissions de télévision avec un magnétoscope. Jack Valenti était vraiment quelqu’un d’épouvantable, non ?

• Cela fait aussi des années que je m’oppose au développement d’apps mobiles, au motif qu’à l’instant où l’on décide de développer une app mobile, on remet le contrôle de son produit ou service à un tiers.
  Difficile de ne pas être d’accord.
  Si le « support » consiste à espérer recevoir une attention utile sur HN ou Twitter, alors nous faisons fausse route.