Autorisations pour USB

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

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

Citation:

---

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

Salut
------

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

Citation:

---

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.

Citation:

---

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".

Citation:

---

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

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Si tu peux faudrait tester ton problème sur différent version d'OS pour voir si ca n'a pas été corrigé depuis.
Je sais pas quel est ton device android actuel , mais j'ai travailler sur quelques device android embarqués (souvent chinois) à base d'android 5.1 et y'a souvent des petits bugs. peut être tester sur un device un peu standard (genre téléphone récent) voir ce que ca dit.

Citation:

---

Si tu peux faudrait tester ton problème sur différent version d'OS pour voir si ca n'a pas été corrigé depuis.

---

En fait j'ai testé sur mon GSM Android 7
Et ma Centrale en Android 5 a choisi le moment où je voulais tester pour rendre l'âme. Moralité je n'ai plus que de l'Android 7 et j'ai recommandé une centrale qui sera aussi en Android 7
Aujourd'hui je dois partir, mais je testerai demain les différentes pistes que toi et d'autres m'avez renseignées

Bon, voici le résultat de mes expérimentations:

1- J'ai créé une activity sur base du contenu du zip que tu m'as renseigné et à ma grande surprise ça fonctionne parfaitement et exactement comme je prévoyais au départ pour mon application: Le fichier meta-data est bien pris en compte, l'application est bien lancée automatiquement si et seulement si on connecte le device correspondant explicitement aux meta-data, et la case à cocher "utiliser par défaut" est bien prise en compte même après redémarrage de l'appareil host. Mieux: la requête vers l'utilisateur pour obtenir la permission est lancée sans qu'on ne doive le faire par soft, c'est géré par l'OS.

2- Or c'est strictement et exactement la même méthode qui est implémentée dans mon application, sauf qu'il y a en moins dans le zip la gestion de l'appel explicite de la requête utilisateur et qu'on affiche ici les informations. Or dans mon application ça ne fonctionne pas du tout (ni prise en compte des meta-data identiques, ni case à cocher).

Après quelques essais, la conclusion est la suivante (sous réserve d'une erreur de ma part): La méthode renseignée fonctionne pour une Activity mais PAS pour un service: Pour un service on ne sait jamais obtenir une autorisation définitive, il faut la redemander à chaque redémarrage du service, et en plus la demander explicitement. Pourquoi? je l'ignore encore, mais le fait est que ça semble être le cas.

En outre, dans l'activity il n'y a même pas besoin de générer la requête vers l'utilisateur, l'OS s'en charge, alors que ce n'est pas du tout le cas avec le service puisqu'au départ je n'ai pas l'autorisation et que je ne l'obtiens pas tant que je n'envoie pas explicitement la requête vers l'utilisateur. Rien de tout ça en Activity, c'est l'OS qui se charge de l'envoi.

Bref, c'est beaucoup beaucoup plus simple de gérer l'USB dans une activité que dans un service. Dommage, j'avais fait tout le boulot, ne restait que cette fichue autorisation non rémanente.

Du coup, même si mon application est opérationnelle à 100%, ce problème d'autorisation m'oblige à transformer mon service en activité: L'esprit était plus "service" que "activity", mais au moins j'ai une solution qui débloque mon projet, et de toute façon il n'y a pas d'écran pour vérifier qu'on a ou pas quelque chose à l'écran. La fonctionnalité "service" évitait juste qu'on ne ferme l'application par accident ou que l'OS ne la ferme. Mais bon, sans clavier et sans aucune autre application opérationnelle sur la Centrale, le risque est faible.

En tout cas, merci de ton aide, qui m'a été utile. :)
Si je découvre d'autres informations sur ce sujet précis, je compléterai mon message, au cas où ça servirait à d'autres.

A+
Claude

Et simplement obtenir l'autorisation dans ton activity puis la transmettre à ton service ?

En gros l'activity initie la connectivité USB et la passe ensuite au service.
Ca peut éventuellement d'éviter de tout refaire.

Citation:

---

Et simplement obtenir l'autorisation dans ton activity puis la transmettre à ton service ?

---

Marrant, c'est juste la voie dans laquelle je viens de démarrer, les grands esprits se rejoignent, LOL

J'ai pensé effectivement à recréer l'appli en démarrant comme activity qui lance le service automatiquement et qui ouvre les périphériques puis passe les devices déjà autorisés au service qui ne fait que les utiliser.
Dit comme ça, ça fait un peu "barbare", mais ça semble une démarche qui devrait pouvoir fonctionner.

Je dois encore voir comment opérer en pratique et vérifier si mon service peut réellement utiliser les devices ouverts par l'appli, mais c'est la première chose que je vais tenter.

Pour l'instant, le service se lance automatiquement au boot et il y a une activity qui, elle, ne fait que permettre l'arrêt et la remise en marche "manuelle" du service. Comme tu l'indiques, ça me permet de récupérer la majeure partie du projet, je dois quand même en refaire la structure principale, mais j'aurai beaucoup de copiés/collés.

Dès que j'ai eu le temps de finaliser ça, je teste et je te tiens au courant des résultats.
De toute façon, merci pour l'idée.

A+
Claude