Aie, ça recommence, driver status abnormal ! (après reboot, comme d'hab)
Dans l'ordre : _ j'ai rebooté (pour faire un nandbackup) _ redémarrage OK _ puis environ 20s après démarrage, blocage du téléphone _ environ 1min après, il reboot tout seul (soft reboot apparement !) (Là,si je fais rien c'est la boucle blocage/reboot/blocage...) _ je force rapidement le reboot et je vais dans le recovery, je flashe le fichier sh dans le répertoire su.d (celui qui donne les droits à viper pour un kernel enforcing !) _ je rédémarre et j'ai "abnormal", donc obligé de désintaller le driver, reboot puis réinstall (parfois, le status est OK à cette étape et pas besoin de faire la réinstall !)
Ca arrive régulièrement (mais pas forcément à chaque reboot), si qq'un à une idée de ce que je peux faire, car je sèche...
J'ai déjà essayé, mais avec cette version modifiée c'est pire, jamais réussi à la faire fonctionné ! Par contre flinguer mon système oui Merci quand même.
Bon, je vais comme retenter l'install de la version de guitardedhero, dès que je remets la main sur les liens
Les liens ? C'est celui que je t'ai donné. Si les drivers demandent une nouvelle installation après redémarrage, c'est que ça n'a pas marché dès le début. Il fait quoi ton script exactement ? Voilà le mien :
Pour les liens, j'ai retrouvé (autre post sur XDA...) ! Mon script est bien celui-ci (je n'ai rien inventé, et pour le audio_effect.conf, c'est aussi du pompage !)
Ce que je ne comprends pas dans ma config, c'est que le simple fait de rebooter (et encore c'est pas à chaque fois !), met le driver en défaut !
Après avoir flashé le zip, essaie de supprimer le deep buffer dans audio_policy.conf (à moins que ce soit déjà ce que ton zip fait) puis désactive ou upprimé SoundAlive dans les applis système.
Déjà fait ! En plus la suppression du deep buffer n'est utile que si on veut que tous les sons system passent par viper (et je n'utilise viper qu'en bluetooth !)
J'ai retesté les versions de guitardedhero, mais marche toujours pas ! le driver ne s'installe pas (alors qu'il devrait déjà être préinstallé dans cette version). Au moins cette fois-ci mon system ne s'est pas planté ! J'ai aussi essayé à tous hazard de désactivé le "deep buffer". Mais dès que je reboot le téléphone, c'est "mort" pour viper + probable blocage/reboot du téléphone). J'aimerai bien retester avec un kernel "permissive" (je crois que ça allait mieux), mais malheureusement celui que j'utilisais en LP, la version pour MM supprime une bonne partie des permissions des apps après qq reboot ! A chaque version d'android, ça devient de plus en plus galère avec les sécurités ! (on se croirait de plus en plus sur windows ou pire sur ipxxxx !)
C'est les surcouches qui compliquent l'histoire. Je n'ai aucun problème sur mon Nexus depuis des années (hors adaptation suite à des mises à jour majeures d'Android).
Salut merci de l'info,mlais dedans y a 2 FX un apk de 5 mo 30 qui se nome ViPER4Android_FX_A4.x.apk et l'autre de 2 mo 40 qui se nome ViPER4Android_FX_A2.3.apk
alors lequel installer ? je suis en 64 bits sur le htc 10 pour info merci
Je suis pas sûr que la couche constructeur pose vraiment pb ! (Sauf pour le freeze des applis/gestion son natifs de la surcouche) Par contre viper mériterait un "installateur" potable (çà existe avec d'autre gestionnaire de son, gernre musicFX).
@snach21 : viper est pas stable en applis "app", il faut le mettre dans le priv-app pour cette raison. Je pense que la gestion d'énergie de lolipop ou MM pose soucis ! En priv app, l'applis est considérée comme une applis system, donc gestion diff !
Le 2e gros pb, c'est la sécurité du kernel ("enforcing"). Quand il est en "permissive", plus de pb !
Je pense pas : dans mon cas, avec un kernel permissive, plus de pb. mais avec le kernel enforcing, le driver viper "saute" au reboot, bien avant le chargement de la surcouche. D'ailleurs en fouillant un peu sur le net, j'ai trouvé d'autres qui ont le même pb que moi (de souvenir sur un moto G 2015, pas de surcouche et un one plus). Le pire, c'est que pour d'autres personnes, avec mon zip flashable et même ROM, ça marche, même après reboot ! J'en déduis que je dois être tombé sur un bug de viper 2.4.0.1, ou que mon system est pourris (donc réinstall FULLwipe dans qq jours, dès que j'ai le temps !)
Le coup du kernel permissif était une solution de contournement au lancement de SELinux. Depuis que le script est connu, V4A fonctionne parfaitement avec un kernel enforcing.
Par contre, il est clair que V4A mérite une vraie mise à jour pour fonctionner nativement sur les dernières versions d'Android.
Aux dernières nouvelles, c'est surtout qu'il ne s'en occupe pas beaucoup, par manque de temps. zhuhang ne poste plus rien sur XDA (même pas le dev), le blog EN n'est pas alimenté depuis 1 an et demi... L'application officielle V4A fonctionnera le temps qu'elle peut mais je doute qu'elle soit vraiment mise à jour.