ça fonctionne pas mal du tout, très pratique avec la touche select

apparemment ma touche select affiche un petit menu contextuel par défaut lorsqu'on reste appuyé, du coup j'ai droit aux deux fonctions en même temps, ce qui rend l'affichage de la bar un peu plus long, mais bon, c'est déjà pas mal du tout

merci pour le retour 8ight.

normal que la touche select peut parfois faire double emploi. d'où l'intérêt d'une nouvelle version avec le choix du bouton. pour le temps d'affichage de la barre, c'est juste le temps que met le service à se relancer (mais bon ça prend pas plus de 2 secondes. hein?)

Dommage que cela fonctionne qu'avec la touche Start
je l'aurais bien testé sur le 80xs

HideSystemBar-v1.1.apk

J’attends la version 1.2

Merci pour apk

Salut, comme on est sur "Open" console ( ), tu pense qu'il y moyen de partager le code source pour que que je comprenne pourquoi elle ne fonctionne pas sur G18 malgré que les deux commandes sus-cité fonctionne ?

(edit)
Le "show" fonctionne.

Voila mon logcat quand je lance ton appli et je fais Hide Sytem Bar:

Code:

 Displayed com.razlaf.hidesystembar/.MainActivity: +508ms
W/ThrottleService(  154): unable to find stats for iface rmnet0
W/audio_hw_primary(  88): get audio.routing failed
V/su-binary(  941): ----su-----
I/ActivityManager(  154): Force stopping package com.android.systemui uid=1000
W/WallpaperService(  154): Wallpaper uninstalled, removing: ComponentInfo{com.android.systemui/com.android.systemui.ImageWallpaper}
D/dalvikvm(  220): GC_FOR_ALLOC freed 14662K, 70% free 6633K/21511K, paused 71ms
I/dalvikvm-heap(  220): Grow heap (frag case) to 16.978MB for 10813456-byte allocation
D/dalvikvm(  220): GC_CONCURRENT freed 28K, 21% free 17164K/21511K, paused 1ms+4ms
D/dalvikvm(  220): GC_FOR_ALLOC freed <1K, 21% free 17164K/21511K, paused 27ms

Ou sinon montre juste les commandes que t'envoie avec "exec" ?

Je donnerai peut être les sources quand l'application sera achevé.. ou pas
Dans la prochaine version je rajouterai la possibilité d'éditer les commandes envoyé à l’arrêt et au démarrage du service.
les commandes que je passe dans 'exec' sont celle indiqué dans mon premier post.

T'es sur à 100%

Bref, afin d'être plus compatible avec un max d'appareil, j'aurais pensé que tu utiliserais "busybox killall" au lieu de "pkill".

Par contre pour l'écoute de la touche, il vaudrait mieux passer par un service plutôt qu'un thread qui risque de se faire jeter par le système dans certains cas.

Citation :

Par contre pour l'écoute de la touche, il vaudrait mieux passer par un service

De quel service parles tu?

Citation :

un thread qui risque de se faire jeter par le système dans certains cas.

Dans quel cas l'usage de thread serait-il proscrit? pourrais tu expliciter?

Aie c'est un sujet plutôt complexe à aborder mais disons que de la façon que c'est implémenter ce n'est la bonne façon (ou disons pas une façon que je ferais, c'est très subjectif comme notion navré) surtout avec des boucles infinie et des sleep de très longue durée, c'est pas optimum.

Mais à propos des services (et des threads) sur android je te propose de lire ceci (en anglais, désolé):
http://developer.android.com/guide/components/processes-and-threads.html
http://developer.android.com/reference/android/app/Service.html#WhatIsAService

Après si tu veux, demain je pourrais te faire une réponse plus détaillée par rapport a ton implémentation et comme je trouve l'idée de ton appli très intéressante surtout si on peut la faire compatible sur de multiple appareil. Si tu le souhaite quelques conseils et idées, je te laisserais pour cela mon gmail en mp.
En attendant, n'hésite pas à utiliser des variables de classes (je pense notamment au commandes shell ) et faire des méthodes séparées pour bien aérer ton code et faciliter sa maintenance et éviter le copier/coller

Citation :

ce n'est la bonne façon (ou disons pas une façon que je ferais, c'est très subjectif comme notion navré)

La façon de faire varie toujours d'un développeur à un autre, mais de là à dire que ce n'est pas la bonne façon de faire..
C'est un petit prog fait à l’arrache, pas terminé mais fonctionnel, avec 50 lignes à tout casser on est plus proche du script.. même si ce n'est des plus "propre", je ne vais pas m'ennuyer à faire des classe, methods, events et pourquoi pas des commentaires et de la javadoc pendant qu'on y est. Je ne suis pas au taf là..
Merci pour tes liens vers la doc du SDK android, et sur la façon de coder proprement.. mais je sais ce qu'est un thread et un service (ça fait de nombreuse années que je pisse de la ligne de code..). De plus ce n'était pas ma question.
Bref..si par exemple tu as des infos technique concrète sur la façon d'intercepter les touches autre que la mienne, je suis preneur (on en apprend tout les jours..) donc oui, si tu as des infos tu peux m'envoyer ça par MP, ça évitera que ce post se transforme en conversation privée et ennuyeuse pour les autres lecteurs.

@+

Bon je pense que mon intention a été mal perçu, j'en suis navré. (Pourtant j'avais tempéré mon propos en parenthèse)
Je n'ai pas pour habitude de parler de codage (notamment sur Android, c'est mon métier) ailleurs que sur un forum de développement car c'est souvent mal pris et peut paraître prétentieux, bien mal m'en a pris.

Tout ça pour dire que effectivement tu fais ton application comme tu l'entends il n'y a pas de soucis, je ne t’embêterais plus.

Bon courage
(PS; J'ai fais quelques apps pour ma G18 et j'ai fais classes, méthodes, intents, commentaires et javadoc, et si ça évolue bien il y aura des test unitaires, question d'habitude )

Je vais aller voir cela !

cajl a écrit:

Je vais aller voir cela !

installé
hide choisi
droit su donné
bouton Select appuyé
==> RIEN ne bouge

je suis donc passé à FULL!SCREEN et c'est mieux .

SnaKemaN, ma question sur l'utilisation du thread n’était pas une question piège. Une réponse pertinente m'aurai vraiment intéressé, au lieu de ça tu me fait un copier/coller d'un lien vers la doc du SDK android.. admet que c 'était plutôt léger..
Pour ce qui est du "mal perçu" , relis ton post et applique le à toi même, avec tes X années d’expériences, une personne que tu ne connais pas vienne t 'expliquer comment faire du code propre... Tu pourrais aussi mal le prendre.. (rhalala l'ego des analystes programmeur.. )
C'est tout à ton honneur de faire du code bien structuré même pour un petit dev perso. Personnellement mon coté laxiste prend le dessus et je fait l'impasse sur certaine procédure ennuyeuse que j'aurai du appliquer au taf, mais il n'est pas pour autant moins fonctionnel.

Sur ce, sans aucune rancune

@cajl

petit question, as tu testé sur gamepad? et busybox est bien installé?

J'ai pris le busybox sur le market sans soucis

testé quoi ?

razlaf a écrit:

SnaKemaN, ma question sur l'utilisation du thread n’était pas une question piège. Une réponse pertinente m'aurai vraiment intéressé, au lieu de ça tu me fait un copier/coller d'un lien vers la doc du SDK android.. admet que c 'était plutôt léger...

Bon alors je répond car ça peut expliquer le soucis de caji, en fait l'utilisation de thread en soit n'est pas idiote, seulement il faut comprendre le fonctionnement du cycle de vie d'une application (http://developer.android.com/guide/components/activities.html ) en gros ton "activité" (ton application) va démarrer et tant que celle-ci est active ton thread tournera, même si tu fais "back" car "l'activité" est encore en tache de fond (pause) (de même que ton thread du coup) mais au bout d'un moment Android va libérer totalement ton application (destroy) et par la même stopper ton thread car il n'st qu'un attribut de ta classe.

Si tu le met dans le corps de ton activité (dans le "onCreate"), il peut causer ce qu'on appelle des "ANR" ces fameuse pop-up "L'application de répond pas" car il pour lui il n'y a pas d'interaction avec l'application.

D'ou l’intérêt de passer par un service (qui lui peut lancer un thread sans soucis) car ce service permet de faire des traitement de longue durée et peut être "détaché" de l'activity qui l'a lancé.
Du coup comme tu "stocke" ton thread dans le service, il n'y a pas de raison qu'il s’arrête sauf si tu lui demande.

Avec busybox l'apk fonctionne bien mieux
mais je reste sur FULL!SCREEN du fait des boutons

Merci pour ta réponse SnaKemaN, c'est bien plus clair! ( tu aurais dû commencé par là on aurait gagné du temps  )
Je comprend mieux où tu voulais en venir avec ton histoire de service. J'ignore pourquoi, mais je m’obstinai à comprendre de travers quand tu me parlais de passé par un service pour l'interception des touches ( je pensai que me tu parlais d'un service android déjà existant pour faire cela.. ) d’où ma question "de quel service parles tu ?" pourtant c’était clair..méa culpa.
Quand tu dis "l'activité" est encore en tache de fond (pause) (de même que ton thread du coup)  cela laisserai sous entendre que mon thread est en pause aussi ? Ce qui n est pas vraiment le cas, vu que la détection des touches fonctionnes même quand l'appli n'est pas au premier plan. Ou bien j'ai encore mal compris
Par contre tu as raison de dire que mon appli pourrai être killé par le system au bout d'un moment (ne serait que pour un manque de mémoire system) Donc finalement je vais bien mettre mon thread dans un service!. Et puis cela me permettra de rajouter les options stop/start service dans l'appli pour arrêter l'interception des touches.
Merci !

@cajl

Citation :

testé quoi ?

Quand je disais "as tu testé sur gamepad?" je voulais juste savoir si tu avais testé sur la gamepad ou bien sur une autre console android.

On va finir par les marier finalement razlaf et SnaKemaN !

ne marche pas chez moi avec Firmware rooté... merci quand même!
J'ai testé full!screen par contre et c'est vraiment bien fait !

As tu pensé à la busybox ?

Mais il est vrai que Full!Screen est tip top

cajl a écrit:

As tu pensé à la busybox ?

il est pas installé d'office dans la rom rootée?
sinon je ne l'ai pas installé... c'est peut-être ça?

OUI...... (j'ai eu le même soucis)