Discussion :

[ClaudeBg]

Bonjour,

Je rencontre un problème avec une application Android utilisant l'USB HOST (je sais que c'est un peu hors des sentiers battus).

Sur le fonctionnement global tout est OK; Il s'agit d'un service lancé au boot de l'appareil, et ce service communique sans problème avec le Device USB qui est une carte ARM reliée au monde physique.

Là où se situe le problème, c'est qu'à chaque démarrage et également à chaque déconnexion/reconnexion du device USB, je reçois une notification (de mon service) qui dit "Autoriser l'application xxx à accéder au périphérique USB?" avec une case à cocher "Utiliser par défaut pour ce périphérique USB".

J'ai beau cocher la case, rien n'y fait, à chaque redémarrage de l'appareil HOST Android ou à chaque connexion ou redémarrage de l'ARM Device, l'utilisateur est obligé de reconfirmer l'autorisation.

Or, la doc dit ceci: "Note: If your application uses an intent filter to discover USB devices as they're connected, it automatically receives permission if the user allows your application to handle the intent. If not, you must request permission explicitly in your application before connecting to the device."

J'ai utilisé les intent-filter et les meta-data pour déclarer mon périphérique USB, mais rien ne change, que je mette des valeurs farfelues ou correspondant au device réel: Je dois chaque fois confirmer. En fait je ne vois même pas à quoi servent ces meta-data vu que quoi que j'y mette ça ne change strictement rien.

Or, le souci est qu'il s'agit d'une application qui doit rester fonctionnelle en continu sur secteur. Et en cas de panne secteur l'application doit redémarrer toute seule automatiquement. Or, ici, ça redémarre sauf que ça reste bloqué évidemment sur la requête d'autorisation. Et cette requête est déclenchée parce que le périphérique n'est pas détecté comme disposant de l'autorisation. Avec en plus le problème que le périphérique Android n'a pas d'écran et donc ça oblige à connecter un moniteur pour confirmer.

Quelqu'un peut-il m'aider à localiser ce problème?

C'est un projet open-source, je peux donc fournir n'importe quelle partie du code.

Je vous remercie d'avance,
Claude

[ClaudeBg]

Bonjour,
Personne ne sait vraiment répondre? Je vais poser les questions d'une façon différente:

1- Peut-on éviter de demander l'autorisation à l'utilisateur pour utiliser un device USB? Même s'il faut faire des modifications sur l'appareil lui-même, qui est rooté d'origine.
2- Pourquoi les meta-data pour le filtre USB n'ont aucune incidence et ne sont pas prises en compte? J'ai strictement suivi cette procédure: https://developer.android.com/guide/...ivity/usb/host
3- Pourquoi la case "Utiliser par défaut pour ce périphérique USB" ne fonctionne pas (aucun changement de comportement qu'on la coche ou non)?

Si quelqu'un sait me débloquer, ça m'éviterai de devoir abandonner la réalisation de ce projet sous Android, et donc de perdre plusieurs mois de travail. D'autant que toute mon application fonctionne et que les docs sont déjà écrites, je n'avais juste pas remarqué ce problème avec les essais finaux.

Merci,
Claude

[grunk]

1- Peut-on éviter de demander l'autorisation à l'utilisateur pour utiliser un device USB? Même s'il faut faire des modifications sur l'appareil lui-même, qui est rooté d'origine.

je ne pense pas , c'est une fonctionnalité du système que tu ne peux pas outrepasser (sauf à modifier android).

2 et 3 :

Je n'y connais rien en USB Host , mais une des raisons qui pourrais faire que l'autorisation est perdu est que ton device USB ne garde pas ses identifiants.

As tu déjà essayé d'afficher des vendor-id, product-id pour vérifier si il étaient strictement identique même après une coupure électrique ?
Si ce n'est pas le cas , ça pourrais aussi expliquer les meta-tag qui ne marchent pas.

Après un redémarrage secteur ton device android garde bien toutes ses configurations où il repart de 0 à chaque fois ?

--Edit--
Il semblerait que l'histoire de la case à cocher qui ne fonctionne pas , soit quelque chose de connu.
Peut être essayé ce qui est exposé là : https://stackoverflow.com/questions/...ssion#15151075

[ClaudeBg]

Salut
------

D'abord, merci pour ton aide, je me sentais un peu seul.

je ne pense pas , c'est une fonctionnalité du système que tu ne peux pas outrepasser (sauf à modifier android)

La doc originale semblait dire qu'on pouvait passer outre en déclarant des meta-data liées à l'intent-fiter, mais ça ne fonctionne pas (ou ne fonctionne plus).

Par contre, "modifier Android" dans le sens "modifier un fichier de configuration dans l'appareil host" ce n'est pas un problème c'est juste que j'ignore que changer pour faire baisser le niveau de sécurité afin que l'OS ne demande plus l'autorisation.

En effet, l'application utilise un appareil dédié uniquement à cette utilisation, on peut donc le configurer comme on veut, ce n'est ni un GSM ni une tablette, et les devices USB. sont figés en fonction de l'installation. Ce n'est pas comme si c'était une application qui peut être chargée et utilisée telle quelle sur n'importe quel appareil: c'est une application intriquée avec le matériel de façon "définitive". Rien n'empêche donc de "customiser"' les paramètres de l'OS, c'est juste que je ne suis pas suffisamment compétant pour faire ça.

As tu déjà essayé d'afficher des vendor-id, product-id pour vérifier si il étaient strictement identique même après une coupure électrique ?

C'est moi qui ai réalisé les périphériques en question, sur base de cartes ARM-Cortex M3. J'impose donc mon propre vendor-ID et mes propres product-ID.
Ils ne peuvent donc pas changer, ils sont figés dans le code.

De plus pour répertorier ceux que l'utilisateur a effectivement connectés parmi ceux possibles, je teste explicitement ceux présents en fonction du vendor-id (identique pour tous les périphériques) et chaque product-ID qui dépend du rôle de la carte: Et absolument tout fonctionne: La "Centrale" (Host) trouve les cartes, les identifie correctement, et les utilise tout aussi correctement.

Bref, tout fonctionne excepté que si on perd l'alim (panne réseau), la Centrale redémarre bien, les cartes aussi, le logiciel de la Centrale (qui est un service d'avan-plan) redémarre bien automatiquement, MAIS on se retrouve avec un message demandant si on autorise l'application à accéder par défaut aux périphériques. Or il n'y a personne pour valider le message et il n'y a même pas d'écran et donc l'appli est bloquée tant qu'on ne valide pas.

Pour ton lien, je te remercie, mais c'est exactement ce que j'ai déjà fait, et ça ne fonctionne pas.
En fait, les infos dans la meta-data ne servent à rien: Que j'y mette le bon device ou n'importe quoi je dois toujours demander à l'utilisateur et une fois l'autorisation accordée j'ai toujours accès.

Je me demande si cette doc n'est pas ancienne et que Google n'a pas changé un paramètre au niveau des sécurités du système qui ferait que cette méthode fonctionnait mais ne fonctionne plus avec le niveau de sécurité relevé. Ma solution serait alors de redescendre ce niveau, la Centrale n'ayant pas accès ni aux mises à jours Android ni à rien de dangereux: Elle tourne en interne sous réseau privé avec ses propres devices USB et sans carte sim.

Mais si c'est ça, j'ignore que changer au niveau de l'OS (commande à envoyer, fichier de sécurité à éditer...).

Ce qui est dommage c'est que tout le projet fonctionne et une grande partie des docs est même écrite (250 pages). Je n'avais simplement pas vu qu'en cas de redémarrage on devait revalider, je pensais que la case à cocher et la meta-data faisaient que la validation se faisait une fois pour toute. Et si je ne résous pas ça, le projet est finalement non viable et je dois réécrire la partie "Centrale"" Host sous Linux plutôt qu'Android.
Or j'avais choisi Android parce que dans le même projet j'ai des tablettes distantes qui dialoguent en tcp/ip avec la centrale, comme "interfaces utilisateur", et donc ça m'évitait de devoir travailler avec 3 IDE (Android Studio, Segger Embedded Studio + un IDE pour Linux). Quand je débogue je dois déjà travailler avec 2 IDE simultanément, avec 3 ça devient un peu "lourd".

Après un redémarrage secteur ton device android garde bien toutes ses configurations où il repart de 0 à chaque fois ?

Il redémarre à 0 à chaque fois, parce qu'en fait il n'y a rien de spécifique à mémoriser. Du moins je ne vois pas ce que je pourrais mémoriser: Tout est codé en dur dans l'application et il n'y a pas d'OS vu que c'est une carte à microcontrôleur. Donc il s'initialise, attend les requêtes d'énumération du Host et répond de façon toujours identique.

Si tu avais une idée, je suis preneur, merci de ces premières propositions
En tout cas, si j'arrive à trouver je posterai la solution ici, parce qu'en cherchant sur le net je constate que je ne suis pas le seul à me heurter à ce problème.

A+
Claude

[grunk]

Par contre, "modifier Android" dans le sens "modifier un fichier de configuration dans l'appareil host" ce n'est pas un problème c'est juste que j'ignore que changer pour faire baisser le niveau de sécurité afin que l'OS ne demande plus l'autorisation.

C'est plutôt modifier android dans le sens refaire toi même une rom spécifique à ton besoin à partir de AOSP.
Autant dire tout de suite que c'est un boulot très conséquent et ça demande (à mon avis) une très bonne connaissance de l'os avant d'arriver à quelque chose.

Pour ton lien, je te remercie, mais c'est exactement ce que j'ai déjà fait, et ça ne fonctionne pas.

As tu essayé le zip qu'il propose ? il semble dire que c'est un exemple fonctionnel pour l'acceptation de l'autorisation uniquement une fois.

[ClaudeBg]

As tu essayé le zip qu'il propose ? il semble dire que c'est un exemple fonctionnel pour l'acceptation de l'autorisation uniquement une fois.

Je l'ai chargé, mais il ne contient en fait que

- le manifest, qui est un strict copié/collé de la doc, et qui est donc ce que j'ai utilisé
- Le fichier res filter_device, qui est identique à celui que j'ai utilisé
- Un main qui se contente de scruter les périphériques connectés lorsqu'on clique sur un bouton et qui affiche le vendor-ID, le product-ID et le statut de l'autorisation:

Mon programme contient déjà tout ça et renvoie "false" comme statut d'autorisation de façon systématique. La seule façon d'avoir "true", c'est d'envoyer la requête à l'utilisateur: Or, le programme zippé n'envoie même pas la requête en question, il se contente de lister les autorisations.

En fait je peux connecter mon device sur la Centrale Android, l'OS ne me demande rien du tout.
Par contre, dès que je lance mon application, j'ai les autorisations sur "false" et donc je ne sais pas ouvrir les devices. Pour ouvrir un device je dois lancer explicitement la requête d'autorisation depuis mon application, le message apparaît demandant si l'application peut utiliser ce device, et une fois confirmé, alors mon autorisation passe à "true".
La requête, elle vient de mon application, pas de l'OS, mais c'est l'OS qui m'impose de l'envoyer car sinon il me refuse l'autorisation qui devrait pourtant être à "true".

Et le zip en question, il liste juste les autorisations, qui dans mon cas sont systématiquement sur "false" et il n'envoie jamais la requête.
Donc si je fais tourner ça (il faut créer le projet), je ne vais avoir que des "false", parce que c'est déjà ce que je fais pour lister les devices au démarrage: Je demande un itérateur, je récupères les devices présents, puis je fais un UsbManager.hasPermission. C'est là justement où je reçois toujours "false", alors que le type explique que lui reçoit "true" si on a déjà validé une fois.

Bref je ne doute pas que ça fonctionnait lorsqu'il a posté, parce que c'est ce que tout le monde disait à l'époque d'Android 5.0, et c'est du reste ce que dit explicitement la documentation:
https://developer.android.com/guide/...ivity/usb/host

C'est juste que maintenant ça ne fonctionne plus, vu les messages que j'ai trouvés sur le net à ce sujet. Et j'avais vu par hasard que Google avait modifié le niveau de sécurité par défaut concernant notamment l'USB, et donc je pense que l'explication est peut-être à ce niveau. Le message en question indiquait comment redescendre ce niveau (sur un appareil rooté) mais je ne me rappelle plus où j'ai lu ce message.

Mais bon, vu que mon application est un service, je vais quand même créer une application standard en reprenant le code du zip, histoire d'être sûr du résultat.