Tweak verify-byte code

[woodz]

Bonjour à tous ;) ,

Je suis tombé sur le forum de XDA là dessus.

Quelqu'un connait?

http://forum.xda-dev...d.php?t=1263119

Ne faites cette opération que si vous comprenez bien ce que vous faites. Vous le faites à vos risques et périls et personne, autre que vous, ne pourra être tenu pour responsable en cas de problème.

Modifié 19 septembre 2011 par woodz

[kevin1969]

J'ai vu mais je ne sais pas qu'elle application 'plante' a cause de se truc et je ne connais pas le gain, j’essaierais prochainement ^^

[vinss]

Merci beaucoup pour l'info, j'ai testé et franchement ça a l'air d'aller plus vite, vraiment !

Pour info voici ma config spica :

- Android 2.2.1

- Noyau : 2.6.32.9 banjo@banjo-VirtualBox #39

- Mod : CM-6.1.1-Spica-a8.4-NextGeneration_2a

- Build : YONIP Kernel V.22B 16Bpp

[droid19]

Moi je suis tomber sur des trucs comme ça:

Supercharger script:

http://forum.xda-developers.com/showthread.php?t=991276

Juve Ram Script:

http://forum.xda-developers.com/showthread.php?t=1111145

Ça vaut peut être le coup de voir si ça pourrai nous aider?

[Marco Sokolov]

Le post sur Samdroid précise que le tweak est adapté aux ROM déodexés, mais je ne me souviens plus si celles du spica le sont ou pas... Si quelqu'un pouvait m'éclairer sur ce point, merki !!

Marco

[khancyr]

Oui les rom du spica sont deodexer mais aprés faut voir si le script est utilisable sur le spica

[tjbu]

Pour le premier Tweak j'ai eut quelques surprises :/

rm /data/dalvik-cache/*

rm /cache/dalvik-cache/*

Me font des erreurs comme quoi les dossier n'existent pas :S J'ai pensé que a venais du fait que j'avais mis la machine Davilk sur la SD (avec Samdroid tools) Donc je reboot remet la Davilk sur le portable, double reboot. Mais toujours pas de /data/davilk-cache/* ni de /cache/davilk-cache/

Puis après impossible de trouver le build.prop ou le local.prop ils n'y sont pas :/

Enfin petit problème mon appli broken a moi c'est le market et mon gost commander ^^

Je suis en CM de sophien (la dernière version) sur le kernel Horse Power :)

Donc je pense flasher d'ici peu ^^ (avant de flasher je vais voir si le tweakde la RAM de Juve marche)

[vinss]

Pour le premier Tweak j'ai eut quelques surprises :/

rm /data/dalvik-cache/*

rm /cache/dalvik-cache/*

Me font des erreurs comme quoi les dossier n'existent pas :S J'ai pensé que a venais du fait que j'avais mis la machine Davilk sur la SD (avec Samdroid tools) Donc je reboot remet la Davilk sur le portable, double reboot. Mais toujours pas de /data/davilk-cache/* ni de /cache/davilk-cache/

Puis après impossible de trouver le build.prop ou le local.prop ils n'y sont pas :/

Enfin petit problème mon appli broken a moi c'est le market et mon gost commander ^^

Je suis en CM de sophien (la dernière version) sur le kernel Horse Power :)

Donc je pense flasher d'ici peu ^^ (avant de flasher je vais voir si le tweakde la RAM de Juve marche)

j'ai eu exactement les mêmes messages et les 2 fichiers cités ne sont pas présents sur mon phone, pourtant après reboot et quelques heures d'utilisation je suis formel : mon spica dépote comme jamais :)

[LordManta]

Deux remarques :

- Si vous utilisez le app2sd de samdroid et que vous avez déplacez le dalvik-cache sur la sd c'est assez normal qu'il ne trouve pas le fichier en /data/dalvik-cache/* ni même en /cache/dalvik-cache/*. en fait il faudrait ajouter un

rm /system/sd/dalvik-cache/*

pour tenir compte du apps2sd des SamdroidTools.

- Faites quand même très attention à cette manip car elle désactive le bytecode verifier de la dalvikvm ce qui fragilise quand même l'ensemble du système en particulier sur des tels rootés... Avec le jit qui offre une compilation optimisée (mais qui est aussi moins rigoureuse) vous multipliez les failles de sécurité sur votre téléphone... Sinon ce tweak est efficace car en désactivant le bytecode verifier on permet une exécution pus offensive du code. Comparé au ROM odexé ça permet d'obtenir des perfs similaires mais les vérifications en moins...

[woodz]

Je vais tenter... au pire pour remettre, y'a juste une ligne de code!

On verra si le jeu en vaut la chandelle. Faut dire que créer des failles de sécurité c'est pas glop, mais si on installe rien de suspect, ou est le problème? (question, pas affirmation!)

[LordManta]

Je vais tenter... au pire pour remettre, y'a juste une ligne de code!

On verra si le jeu en vaut la chandelle. Faut dire que créer des failles de sécurité c'est pas glop, mais si on installe rien de suspect, ou est le problème? (question, pas affirmation!)

En fait le risque est surtout qu'en l'absence de vérifications du bytecode, un bytecode altéré peut avoir un comportement inattendu alors qu'il aurait été rejeté avec le vérificateur.

Si tu n'installes que des applis venant du market (donc signées et je l'espère un peu vérifiées par google avant), le risque est pas bien grand je pense. Mais le risque augmente, même s'il est difficile d'évaluer dans quelle proportion. C'est pourquoi je préfère prévenir :D .

Par exemple l'utilisation d'applis a priori inoffensives (même des applis systèmes), peuvent avoir été mal programmées. En l'absence de vérifications à runtime, elles peuvent alors être victimes plus facilement d'attaques (buffer overflow etc ...).

Bon sinon :

setprop dalvik.vm.verify-bytecode false

ne semble pas marcher pour moi : quand je fais un

getprop

derrière, je trouve pas la propriété en question... Est-ce que quelqu'un a pu vérifier après avoir positionner la propriété que celle-ci était effectivement changée ?

Pour la deuxième propriété ça marche.

Concernant le gain : Ça semble effectivement plus réactif au chargement des applis...

Mais bon, vu que mon système n'est pas très réactif depuis quelques versions...

Par contre je n'ai pas observé de plantages particulier pour le moment. (ni avec GhostCommander, ni le Market ni aucune autre appli que j'utilise ...). Mais bon vu que le tweak ne semble pas s'appliquer correctement sur mon système...

update 19-09-2011 : 11:35 :

Ça semble bien fonctionner si on a mis les propriétés dans le build.prop par exemple :

/system/build.prop

en mettant :

dalvik.vm.verify-bytecode = false
dalvik.vm.dexopt-flags=v=n,o=v

Le spica à l'air plus réactif et les properties sont visibles avec un getprop ;)

Modifié 19 septembre 2011 par LordManta

[woodz]

Merci pour l'info ;)

En retour pour le getprop j'ai [m=y] (je sais pas ce que ca veut dire! :D ), rien a voir avec les paramètres du script?

Sauf si je me suis planté et qu'il faut obligatoirement editer le fichier pour que ca s'applique!

Je ne suis pas sur que la ligne de commande suffise :/

Rien pour la deuxieme non plus...

en meme temps je trouve pas le data/local.prop ou le build :/

Edit build trouvé :D

J'ai fait la modif du build... wait & see...

Modifié 18 septembre 2011 par woodz

[vinss]

Moi je suis tomber sur des trucs comme ça:

Supercharger script:

http://forum.xda-dev...ad.php?t=991276

Juve Ram Script:

http://forum.xda-dev...d.php?t=1111145

Ça vaut peut être le coup de voir si ça pourrai nous aider?

J'ai installé le Juwe Ram Script et je suis fasciné, jamais vu mon Spica aussi réactif ! Merci beaucoup pour ce lien, tu as fait ma journée :)

Sinon j'arrête là après le Tweak Verify byte code + le Juwe Ram Script je pense pas qu'il soit possible d'optimiser + mon système, encore merci !

[LordManta]

Après quelques heures de test, le tweak bytecode verifier et le tweak juve rendent effectivement le téléphone très réactif.

Par contre, le tweak dy bytecode verifier rend un peu erratique le comportement général du téléphone. Les applis plantent plus souvent, mais en général on les redémarre instantanément et ça fonctionne (même si au final 2 redémarrage ne permet pas d'apprécier un gain notable par rapport à un démarrage lent :P ).

J'ai eu un reboot du system_server depuis hier, mais j'ai pas pensé à vérifier le logcat... J'imagine que c'est probablement le problème d'instabilité de la vm suite au retrait du bytecode verifier.

Par contre, avec ces plantages on a un risque augmenté d'avoir des corruptions des données associées aux applications qui plantent, j'ai du réinstaller les données de l'application mail après 3 plantages. mais avec TitaniumBackup c'est un jeu d'enfant et Le confort du à la réactivité vaut bien ce petit inconvénient je pense.

Reste les risques accrus en termes de failles de sécurité... pour le moment je fais l'autruche ;) .

[droid19]

@vinss

De rien :)

A ce que je lis, toi et LordManta avez combiner les deux tweak, je vais en faire autant pour tantôt ;)

@LordManta

Le script Ram de Juve est prévu initialement pour fonctionner sur un SGS, est ce que les valeurs mériteraient d'être adaptées pour notre Spica?

Pour ma part, la modification du buid.prop et du local.prop sont bien intégrées, légère meilleure réactivé au lancement des apps, moins de micro lags dans le launcher (ADW). Pas de 'plantage(s)' constatés.

2.1 Eclair FE9 SamdroidTools dans le dalvik cache sur SD.

[LordManta]

@vinss De rien :) A ce que je lis, toi et LordManta avez combiner les deux tweak, je vais en faire autant pour tantôt ;) @LordManta Le script Ram de Juve est prévu initialement pour fonctionner sur un SGS, est ce que les valeurs mériteraient d'être adaptées pour notre Spica? Pour ma part, la modification du buid.prop et du local.prop sont bien intégrées, légère meilleure réactivé au lancement des apps, moins de micro lags dans le launcher (ADW). Pas de 'plantage(s)' constatés. 2.1 Eclair FE9 SamdroidTools dans le dalvik cache sur SD.

Je pense qu'il faudrait effectivement les adapter un peu car ça a un peu tendance à être agressif avec certaines applis mais pour le moment je test avec les paramètres tels quels et c'est plutôt bon.

J'ai beaucoup gagné en réactivité du système (il faut dire que mes réglages de base n'étaient pas terrible). Par contre je conseil d'ajouter quelques garde-fous.

OOppps : les mises en garde habituelles :

Ne faites cette opération que si vous comprenez bien ce que vous faites. Vous le faites à vos risques et périls et personne, autre que vous, ne pourra être tenu pour responsable en cas de problème.

Comme Voku à retiré ses tweaks de la SGM-3.3 j'ai ajouté le fichier suivant dans 98tweaks :

Donc c'est taillé et testé sur la Voku SGM-3.3. Il faudra éventuellement adapter en fonction des autres ROMs disponibles.

#!/system/bin/sh
# based on :
#	 - script proposed by Juwe11 http://forum.xda-dev...d.php?t=1111145
#	 - tweaks from Voku (in its SGM BETA 3 ROM)

L="log -p i -t cm"$L "tweaking memory usage based on Juwe11 script"
# More ram hereif [ -e /sys/module/lowmemorykiller/parameters/adj ]
then
 #echo "0,1,2,4,7,15" > /sys/module/lowmemorykiller/parameters/adj
 # we keep Voku's scores
 echo "0,1,2,4,6,15" > /sys/module/lowmemorykiller/parameters/adj
fi
if [ -e /sys/module/lowmemorykiller/parameters/minfree ]
then
 # Juwe11 are somewhat aggressive (remember unit is in pages of 4KB)
 #echo "2560,4096,5632,10240,11776,14848" > /sys/module/lowmemorykiller/parameters/minfree
 echo "2560,4096,5632,10240,12288,18432" > /sys/module/lowmemorykiller/parameters/minfree
 #echo "1536,2048,4096,7680,12288,18432" > /sys/module/lowmemorykiller/parameters/minfree
fiif [ -e /proc/sys/vm/swappiness ]
then
 echo "20" > /proc/sys/vm/swappiness
 #echo "60" > /proc/sys/vm/swappiness
fi
if [ -e /proc/sys/vm/vfs_cache_pressure ]
then
 echo "70" > /proc/sys/vm/vfs_cache_pressure
 #echo "100" > /proc/sys/vm/vfs_cache_pressure
fi# less lags playing with fs cache
if [ -e /proc/sys/vm/dirty_expire_centisecs ]
then
 # Pay attention here higher risk to get corrupt data as data is not write back for a while
 echo "3000" > /proc/sys/vm/dirty_expire_centisecs
 #echo "200" > /proc/sys/vm/dirty_expire_centisecs
fi
if [ -e /proc/sys/vm/dirty_writeback_centisecs ]
then
 # Juwe11 scripts uses default from Voku
 echo "500" > /proc/sys/vm/dirty_writeback_centisecs
fiif [ -e /proc/sys/vm/dirty_ratio ]
then
 echo "15" > /proc/sys/vm/dirty_ratio
 #echo "20" > /proc/sys/vm/dirty_ratio
fi
if [ -e /proc/sys/vm/dirty_background_ratio ]
then
 echo "3" > /proc/sys/vm/dirty_background_ratio
 #echo "5" > /proc/sys/vm/dirty_background_ratio
fi# protect important apps from the task
$L "protect some apps based on Voku 98teaks script"protectApp(){
 while true
 do
pid="$(pidof "$1")"
if [ -n "$pid" ]
then
  echo "-17" > "/proc/$pid/oom_adj"
  renice -20 $pid
  $L "protect su app pid=$pid"
fi
sleep 100
 done
}
( protectApp com.android.phone &)
( protectApp com.noshufou.android.su &)
( protectApp adbd &)
( protectApp com.android.contacts &)
( protectApp android.process.acore &)
# if you want to protect another process add a line above
# but don't exagerate to much on our Spica cause of the low amount of RAM.

Modifié 19 septembre 2011 par LordManta

[woodz]

Un mix entre voku et Juwe?

question, ca s'applique comment? :huh: (Noob inside)

[droid19]

Je pense qu'il faudrait effectivement les adapter un peu car ça a un peu tendance à être agressif avec certaines applis mais pour le moment je test avec les paramètres tels quels et c'est plutôt bon.

J'ai beaucoup gagné en réactivité du système (il faut dire que mes réglages de base n'étaient pas terrible). Par contre je conseil d'ajouter quelques garde-fous.

Ces paramètres à modifier, c'est surtout en cas de crash d'applis? Ou pour la gestion de la RAM?

question, ca s'applique comment? :huh: (Noob inside)

Tu peux télécharger le script Juwe RAM Tweak ici > http://forum.xda-dev...d.php?t=1111145 et l'appliquer en recovery Tu devras le copier avec un explorateur Root à la mano. Pour intégrer les modif de LordManta , je ferait un .zip un peut plus tard dans la soirée.

Juwe RAM Script recovery:

http://download394.m..._RAM_Script.zip

Juwe RAM Script Voku by LordManta recovery:

http://download1400....y_LordManta.zip

Ne me tenais pas pour responsable en cas de mal fonctionnement, vous seul savez ce que vous faites, si vous ne savais pas ne faites rien ^_^

Modifié 19 septembre 2011 par jo_nathan

[ChristopheScheidt]

quelqu'un peut m'expliquer comment installer les 3 script parceque je pige rien a l'anglais et avec google trad c'est pire =)

[woodz]

Le premier, par terminal, puis modif d'un fichier system.

Les deux derniers (l'un ou l'autre, Juwe ou Juwe by LordManta featuring Voku ^_^ ) par recovery grace à jo-nathan (merci à toi d'ailleurs! :lol: )

Je reprends en détaillant, je ne fais que traduire...:

Disclaimer:

Ne faites cette opération que si vous comprenez bien ce que vous faites. Vous le faites à vos risques et périls et personne, autre que vous, ne pourra être tenu pour responsable en cas de problème.

1)Ouvrir Terminal Emulator sur votre téléphone / ouvrir adb shell depuis votre PC et tapez...

su

setprop dalvik.vm.verify-bytecode false

setprop dalvik.vm.dexopt-flags v=n,o=v

rm /data/dalvik-cache/*

rm /cache/dalvik-cache/*

reboot

2) Ajoutez à /data/local.prop ou build.prop (après en avoir fait une sauvegarde sur votre SD).

dalvik.vm.verify-bytecode = false

dalvik.vm.dexopt-flags=v=n,o=v

Si les lignes existent déjà, modifiez les. (Pour ma part, la première n'existait pas)

Perso, je l'ai mis dans le build.

Ensuite, Terminal emulator ou ADB shell et tapez...

rm /data/dalvik-cache/*

rm /cache/dalvik-cache/*

reboot

Avantages:

• Plus de RAM
  
• Lancement plus rapide du système & des applis perso au deuxième boot.
  
• Donnes autant de performances que l'ODEX, sans l'ODEX! Pas de soucis pour les themes.
  
• Meilleure transition entre les applis.
  

Inconvenients:

• Probabilité de plantage plus elevé, rique d'entrainer l'incompatibilité de certaines appli.
  

Modifié 19 septembre 2011 par woodz

[droid19]

De rien ;) et merci @LordManta pour la modif' ;)

[ChristopheScheidt]

sa marche merci

Modifié 19 septembre 2011 par chris-du57

[woodz]

Allez, je me lance dans le Juwe+Voku+LordManta! ....

.... Suspense! B)

[LordManta]

Merci jo_nathan pour le recovery

Pour revenir sur l'utilisation de ces tweaks. Pour ma part le tweak désactivant le bytecode verifier semble un peu trop instable (pas grand chose mais c'est un peu gênant à la longue : Google + plante, Email plante de temps en temps, 2 ou trois reboot du system_server - pas un reboot complet mais uniquement la couche android au dessus de linux).

Pour le moment je teste avec les propriétés suivantes dans le build.prop:

dalvik.vm.verify-bytecode=false
dalvik.vm.dexopt-flags=m=y
# the second one is the Voku's version

Même si c'est encore un peu tôt pour en rendre compte, ça a l'air plus stable (plus de plantage avec Google+). Et ça a l'air toujours aussi réactif...

Attention, tous ces tests sont fait uniquement sur la SGM3.3 de Voku. Je ne sais pas comment ça se comportera sur d'autres ROM.

En fait d'après http://www.netmite.com/android/mydroid/2.0/dalvik/docs/embedded-vm-control.html la propriété dalvik.vm.verify-bytecode est obsolète donc en désactivant la seconde propriété j'ai complètement désactivé le tweak :(

Je vais voir le mix suivant :

dalvik.vm.dexopt-flags=m=y,v=n,o=v

Modifié 19 septembre 2011 par LordManta

[droid19]

De rien LordManta ;)

Il y a quelques temps, j'étais tombé sur ça sur Samdroid: http://forum.samdroid.net/f56/script-smart-tweak-5585/#post169979