Discussion :

[ClaudeBg]

Bonjour,

Je rencontre un problème de permission USB sur un appareil 7.0 utilisé en "Usb-Host" sur lequel je branche une carte USB-device.

- Si je connecte la carte sur l'appareil déjà allumé et l'activité lancée: La première fois j'ai une requête de demande de permission USB: Je valide en cochant la case "toujours utiliser..."

- Je déconnecte et je reconnecte: Plus aucun problème, la carte est acceptée d'office définitivement, même après un redémarrage de l'appareil.

- Si je connecte sans application lancée, l'insertion provoque bien le démarrage de l'activité à tous les coups: Si je n'avais jamais accepté la carte j'ai la requête de demande d'autorisation, sinon j'ai l'autorisation d'office

- Par contre, si je connecte la carte appareil éteint, puis que j'allume l'appareil, en fin de boot mon BroadcastReceiver lance bien mon activité mais la permission d'utilisation de ma carte est refusée d'office sans même me reproposer une nouvelle requête: Je dois déconnecter puis reconnecter la carte et alors ça fonctionne.

Quelqu'un a une idée? Parce que sinon, mon application est inutilisable

Merci,
Claude

[ClaudeBg]

Au cas où d'autres seraient dans le même cas dans le futur, voici le résultat de mes essais:

Si connexion du device USB après le boot de l'appareil USB contenant l'application:
------------------------------------------------------------------------------------

A- Si l'UsbManager est géré par un service (reconnaissance des devices depuis le service):

- Pour chaque connexion d'un device on a par défaut la permission refusée: On doit faire un "requestPermission" explicitement par soft
- Si on est sur un appareil Android <=7: On a la case à cocher "utiliser l'application par défaut"... mais elle est inopérante et chaque reconnexion = nouvelle obligation de confirmer les permissions
- Si on est sur un appareil Android 9 (pas testé en 8): La case n'existe même pas, donc aucun moyen non plus de mémoriser les permissions

B- SI l'UsbManager est géré par une activité

- Pour chaque connexion d'un device on a apparition automatique du request de permission utilisateur, sans aucun appel à "requestPermission"
- La case à cocher "utiliser l'application par défaut" est présente sous Android 7 et 9 et fonctionne
- On doit juste appeler "hasPermission" pour obtenir la permission finale de l'utilisateur, sans aucun code explicite ni gestion du BroadcastReceiver pour les permissions

Conclusion de cette partie: La seule façon d'obtenir une case à cocher "toujours autoriser.." fonctionnelle, c'est de gérer les devices à partir de l'UsbManager obtenu par l'activité.

Si on allume l'appareil avec le device USB déjà branché (cas du rétablissement d'une box Android après une panne secteur par exemple)
------------------------------------------------------------------------------------------------------------------------------------------

- On n'obtient jamais le request automatique de demande de permission, que ce soit avec un service ou une activité, on est contraint d'appeler "requestPermission"
- La case à cocher "toujours utiliser" au lancement de "requestPermission" est présente sous Android 7 et 9, cependant:

- Sous Android 7 la poursuite des opérations via le BroadcastReceiver ("com.android.example.USB_PERMISSION") se poursuit correctement, on obtient finalement bien l'autorisation, MAIS même si on a coché "toujours utiliser", on doit quand même re-confirmer les permissions à chaque redémarrage: Donc, la case à cocher ne fonctionne pas.

- Sous Android 9 c'est pire: L'opération n'appelle jamais le BroadcastReceiver pour valider la demande de permission, donc on n'obtient jamais cette permission, et la seule solution est de déconnecter et reconnecter manuellement le device USB.

Conclusion finale: Une nouvelle fois, Android fait la preuve qu'il est le pire OS de toute l'histoire de l'informatique: Rien n'est correctement débogué, on obtient des fonctionnements imprévisibles et anormaux qui varient totalement en fonction des versions, dès qu'on tente d'utiliser cet OS pour autre chose qu'une application classique embarquée sur un GSM.

C'est quand même fortement dommage: On trouve des appareils Android à petit prix partout, qui sont hardwarement de belles opportunités de développer des applications domotiques et autres, mais l'OS foireux plombe toute initiative dans ce domaine. Vivement un vrai OS sur toutes ces Boxes à base d'ARM.

[grunk]

Vivement un vrai OS sur toutes ces Boxes à base d'ARM

Il existe et c'est linux

On à très vite abandonné l'idée d'android sur autre chose que les téléphones ou tablettes.
C'est d'ailleurs très courant d'avoir le choix de l'os sur les set topbox au moment de l'achat.

[ClaudeBg]

Oui, je sais pour Linux.

Mais sous Linux je ne sais pas faire tourner Kotlin, et donc je ne sais pas réaliser mon application comme je l'entends parce que j'ai besoin des méthodes d'extension "infix" (c'est particulier comme application).

En outre, Linux présente un problème dérangeant par rapport à Android: Il impose d'écrire un driver pour toute carte USB qui ne fait pas partie d'une classe générique: Or mes cartes sont des cartes USB personnelles, et pour des raisons d'efficacité, présentent des fonctions spécifiques ne les rangeant pas dans les classes génériques officielles: Et donc, sous Linux, c'est écriture d'un driver supplémentaire obligatoire: Je préfère éviter.

Sinon, j'ai résolu mon problème en forçant la carte USB slave à se déconnecter si l'appareil host ne communique pas. C'est possible pour moi parce que j'écris à la fois le soft sous Android pour le host et celui sous ARM-M3 sans OS pour les cartes slaves.

Du coup, le tout démarre, l'appareil Android n'a pas les permissions, ça entraine l'absence de communications USB, la carte slave s'en rend compte, se déconnecte et se reconnecte et, du coup, cette fois l'appli Android obtient les permissions, vu que la connexion USB devient postérieure au boot de la centrale. En même temps ce mécanisme me sert de watchdog: En cas de plantage la carte resette et la reconnexion USB entraîne le redémarrage de l'application Android. Bref, pas très "élégant" (j'aurais préféré des permissions qui soient logiques) mais ça fonctionne.

Sinon, niveau outils, Android Studio est quand même terriblement bien fait, à mon avis il ne manque que la génération de documentation automatique, comme ça existe dans Visual Studio.
Niveau Android la fin de l'obligation de gérer les cycles de vie dans la plupart des cas, en utilisant Android Architecture, a quand même rendu le code plus propre.

Au final ce qui est le plus dérangeant avec Android, c'est ces changements incessants, qui imposent de remodifier tout le temps le code.
Bon, pour l'instant j'ai résolu mes problèmes "par la bande", sachant qu'un utilisateur lambda ne pourra pas forcément opérer de cette façon, ce qui a débloqué mon projet.
Je suis en train d'écrire quelques docs et j'ai des volontaires beta-testeurs pour faire tourner tout ça non-stop en stressant l'appli, histoire de vérifier que ça tient la route sur le long terme (c'est une appli qui doit tourner 24h/24 et 365 jours par an).

Bref, c'est vrai qu'en rencontrant ce problème pour le moins imprévisible je me suis passablement énervé. J'ai repris le codage depuis, et j'espère finaliser ce projet: De toute façon je ne recommencerai pas tout en passant à Linux, je laisserais plutôt tomber si ça ne fonctionne pas au final.

[grunk]

Pour les évolutions d'android , c'est un demi problème. Je sais pas sur quel plateforme tu travail , mais très souvent les produits un peu industriel , associent une version d'android à un hardware et n'y touche plus. il font leur build custom et c'est tout. La plus part du temps c'est déjà très en retard sur la version d'android et y'a pas de màj de sécurité mais l'environnement fait que les risques sont plus faibles

[ClaudeBg]

Tu as raison, mais en ce qui me concerne ce n'est pas de l'industriel, c'est de l'open-source grand public. Du coup je suis lié à l'évolution du matériel, je ne peux donc pas "figer" le hardware, il est justement évolutif par la nature même de mes projets. Sans compter que conserver un hardware ne pose pas de problème... tant qu'il ne tombe pas en panne: Or, ce genre de box Android, d'après mon expérience en la matière, ça résiste approximativement 2 à 3 ans avant de tomber en panne.