2012-03-26

Comprendre un plantage (simple) de lint

Je n'ai pas eu l'occasion de faire un billet à ce sujet, mais le très récent ADT 17 apporte  une nouvelle version de lint dopée au stéroïdes.

Malheureusement, il peut arriver que (comme sur l'image de l'article) lint se casse les dents sur votre projet en cours. C'est assez ennuyeux que l'outil d'aide à la découverte de potentiel bug se banane, mais on va voir que ce n'est pas TOUT lint qui est concerné.

2012-03-21

[INTOX] Les applis avec pub ruinent la batterie


L'intox du jour est issue de l'article "Free apps eat up your phone battery just sending ads" de newscientist.com et est assez gratinée.

Le principe d'une bonne intox est de partir d'un fait plausible et de saupoudrer d’exagération et de mauvaise foi. Toutes les vues animées dans une application consomment du CPU, du GPU et de l'Affichage et donc épuisent la batterie. Ce n'est pas vendeur, alors il va falloir conchier du géant Android ou iOS.

Dans cette étude, Abhinav Pathak, nous fais une présentation sérieuse et rigoureuse de son outil eprof capable d'analyser la consommation électrique sans avoir le code source. L'étude est loin de la vulgarisation faite par newscientist : du pret-a-penser pour le mass-media.

Ce que NS laisse croire, à tort, de l'étude:

Lisons l'article ...
"STRUGGLING to make your smartphone battery last the whole day?"
Commençons par chercher l'information là où elle est avec l'outil de suivi de la consommation électrique inclus dans Android.
"Plate-forme Android 30%", "Ecran 29%", "Téléphone inactif 20%" blah blah ... la première application ne culmine qu'à 2% : l'excellent Carcast (avec pub). Se battre avec du 2% ... bon struggling mon gars !

Le Qualiticien en moi réagit au prisme de l'empirique principe de Pareto (vous vous en doutiez). Si je veux significativement améliorer la durée de vie de la batterie j'ai intérêt à agir sur les 80% des facteurs influant sur la consommation électrique. Fréquence du kernel (cpufreq )? Réduire les services tournant en tâche de fond (sms/mms) )
Ce raisonnement est vrai mais pas pertinent (vous vous doutez bien que Pareto c'est un peu plus subtil que 80/20) et c'est pour moi le grand interet de l'article de Abhinav.

L'accroche de l'article n'est pas pertinente... je continue.

Up to 75 per cent of the energy used by free versions of Android apps is spent serving up ads or tracking and uploading user data
Source des 75% ? Un étude universitaire avec l'aide de Ming ZHANG, salarié de Microsoft (concurrent d'Android) ce qui explique la présence de l'étude à cette adresse http://research.microsoft.com/en-us/people/mzh/eurosys-2012.pdf. On va garder le "beaucoup"/"significatif" mais le 75% est vraisemblablement orienté pour donner plus de poids à l'étude.

"For example, in Angry Birds only 20 per cent is used to display and run the game, while 45 per cent is spent finding and uploading the user's location with GPS then downloading location-appropriate ads over a 3G connection."
Ahem ... Angry Birds utilise le GPS ? Et bien non ... D'après le Play Store il n'est question que de géopositionnement par triangularisation GSM. 
A priori l'utilisation du GPS et la double version avec publicité ou payante sont des spécificités iOS donc il serait honnête de cesser de nous râper les raisins avec des généralisations foireuses appliquées à l'arrache sur Android. L'ISO 1664 j'aime bien, mais uniquement entre potes.

Ce que l'étude dit :

Contrairement à ce que le buzz nous laisse croire, les données ne portent pas sur TOUT le secteur de la mobilité mais uniquement sur ... Android. Le logiciel eProf a été réalisé sur Android et Windows Mobile 6.5 mais malheureusement la partie de l'étude sur Windows Mobile n'est pas accessible. Rien sur iOS quel dommage.

L'étude ne se focalise que sur Flurry. Pourquoi avoir mis de côté Admob réalisée par Google ? Toujours sur Flurry qui consomme 45% de l’énergie dépensée pendant une partie d'Angry Birds (dans le chapitre 7.2.2) il est question d'une consommation à hauteur de 15% du GPS. Oh wait !!! Comment peut-on associer à Flurry la consommation du chip GPS alors que l'application n'a pas accès ? Comme nous l'indique le Manifest.xml de l'Angry Birds, la seule permission de géo-positionnement est ACCESS_COARSE_LOCATION qui ne nécessite que peu de calcul.

L'étude version Android porte sur une 20aine d'applications représentatives du monde Android, sur 2 terminaux Android (HTC Magic avec Android 2.0 et HTC Passion avec Android 2.3 que des nouveautés. Aucun Galaxy Nexus ? Étonnamment non, les tests sont réalisés avec des dinosaures (partouseur de droite) équipé d'une surcouche constructeur.

L'étude a été menée en collaboration avec un cadre d'Intel. Hé hé hé ....

PARETO, mon poto. TAGUCHI mon ami :

Revenons une seconde à notre bon Pareto. L'amélioration de la durée de la batterie ne passera malheureusement pas par les 80% de postes de dépenses de l'énergie. L'approche est tentante mais inaccessible : la réduction de "Ecran 29%" passe par une analyse des facteurs et de leurs multiples interactions. Je n'ai pas la prétention de résoudre avec un oscillo, un oeil et les tables du Dr TAGUCHI ce que des armées d'ingénieurs chez Sharp et Samsung peinent à faire.

Abhinav Pathak a du avoir le même raisonnement (hem). Sa pré-étude lui a permis d'évaluer les 3 gros postes de dépenses triviaux : fréquence de "redraw" d'une vue trop élevée, trop de requetes http courtes et trop de sollicitation des chipsets GPS. Tout triviaux que sont ces trois points, ne nous privons pas de la confirmation scientifique (par Abhinav Pathak) de nos acquis empiriques.

C'est là le point, à mon avis majeur, de son étude. Les publicités comme Flurry (mais pas que), utilisent intensivement les trois points, en simultané et en continu. Si le gain absolu est ridicule, la marge de progression relative est impressionnante. Certains développeurs mettent une fréquence de rafraichissement ahurissante de la publicité. C'est mon cas et je vais mettre la pédale douce pour les prochaines versions de mes applications.

Moralité

L'étude est supervisée par Microsoft (concurrent Android), un cadre d'Intel (concurrent arm), ne se focalise QUE sur Android et lui fait porter la responsabilité de l'indigence de Flurry et est réalisé avec des systèmes d'exploitations obsolètes sur des terminaux trop vieux pour être pris au sérieux en 2012.

Le travail de Abhinav Pathak est un travail universitaire qui peut apporter de bonnes pistes d'amélioration pour la génération actuelle de smartphones. Le prix du quart d'heure de gloire est une synthèse détournée en FUD.
 

2012-03-15

ERROR getting 'android:icon' attribute: attribute is not a string value

Le message d'erreur

Le message d'erreur se veut utile et pertinent ... normalement ...
Le fichier est incorrect : W/ResourceType( 6142):
No known package when getting value for resource number 0x01080049 
ERROR getting 'android:icon' attribute: attribute is not a string value 
Donc la valeur resource 0x01080049 identifiant l'icône d'un élément n'est pas une valeur littérale. Admettons ...

L'identification

Eclipse facilite énormément le développement mais la recherche de texte m'est plus facile avec la ligne de commande
$ egrep -ril 80049  * | wc -l
0
C'est mal parti ...
Essayons ça :
$ egrep -ri 'android:icon' AndroidManifest.xml 
android:icon="@drawable/icon"
android:icon="@android:R/drawable/ic_menu_preferences"
Je change l’icône "@android:R/drawable/ic_menu_preferences" de l'activité Preferences par "@drawable/icon" :
<activity
     android:name=".Preferences33700"
     android:excludeFromRecents="true"
     android:icon="@drawable/icon"
     android:label="@string/app_prefs"
     android:theme="@style/theme_signalspam" >
     <intent-filter>
     <action android:name="android.intent.action.MAIN" />
     </intent-filter>
</activity>
Et je repasse au validateur du PlayStore :

Conclusion

Ne pas utiliser de ressources @android:R dans le Manifest.xml ... Mieux lire les guidelines Android ... :)

2012-03-10

Reinstaller manuellement une sauvegarde RerBackup Root



Si comme moi vous effacez régulièrement le contenu de votre téléphone, la partie la plus pénible que vous devez rencontrer est la réinstallation de toutes vos applications. Lourdingue.

La solution passe par l'outil interne "pm" qui est la version en ligne de commande de PackageManager. Cet outil nécessite que vous soyez root sur votre terminal.

La commande magique est pm install avec comme option :

pm install: installs a package to the system. Options: -l: install the package with FORWARD_LOCK. -r: reinstall an exisiting app, keeping its data. -t: allow test .apks to be installed. -i: specify the installer package name. -s: install package on sdcard. -f: install package on internal flash.
Nous allons utiliser -r pour éviter les messages de type
pkg: com.endomondo.android.pro_63.apk Failure [INSTALL_FAILED_ALREADY_EXISTS]
Les commandes, avec la boucle bash qui va bien :

# cd /mnt/sdcard/rerware/MyBackup/AllAppsBackups/AppsMedia_2012_03_07/Apps
# for i in *.apk; do pm install -r $i;done;
That's all folks, tout en automatique. La restauration des données est un peu plus funky. Prochain Billet.

2012-03-09

Mettre à jour un Galaxy Nexus chiffré

Il est temps de mettre à jour la ROM AOKP (sources de la rom ici) pour mon Galaxy Nexus. Je ne sais pas si ça vient de mon téléphone, de ma ROM, du Galaxy Nexus ou d'IceCreamSandwich mais il ne m'est pas possible de faire une restauration en valeur d'usine.

A chaque petits soucis sa bombe atomique, vu que je ne peux pas annuler le chiffrement du terminal, je vais donc écraser la ROM par fastboot. Ce qui va suivre est largement inspiré du guide cyanogenmod.

Les pré-requis :


Il faut également les outils adaptés comme tar, adb et bash. Pour que ce blog vous intéresse un minimum c'est que vous avez déjà ces outils, non ?


Préparation :
  • Sauvegardez votre contenu avec un outil comme MyBackupPro et sauvegardez la SdCard via MTP. LE DÉCHIFFREMENT DU TERMINAL VA EFFACER TOUT LE CONTENU DE VOTRE TERMINAL.
  • Assurez-vous que fastboot est dans votre PATH, ça sert toujours.
  • Décompressez l'image factory où vous voulez, pour ma part c'est toujours dans /tmp/ qui est effacé à chaque boot.
  • Mettre le téléphone en boot loader par adb ou par "recovery" dans le menu d'extinction ou par la manipulation maintenir "Vol+" et "Vol-" en simultané lorsque le mobile est éteint et maintenir en appuyant en plus sur le bouton "On"

Commandes
Dans /tmp/ (pour moi)
$ . flash-all.sh
$ fastboot reboot-bootloader
Plutot que le reboot-bootloader je conseille l'extinction du terminal et le retrait de batterie (et un reset électrique).
$ fastboot flash recovery recovery-clockwork-5.5.0.2-maguro.img
$ fastboot reboot-bootloader
(bis) Plutot que le reboot-bootloader je conseille l'extinction du terminal et le retrait de batterie (et un reset électrique).

Maintenant que ClockWorkMod est installé, il faut l'activer par le menu bootloader (Vol+ ou Vol-) ou par adb (ma préférence).
  • Install zip from SDCARD
  • choose zip from sdcard (qui mount la sdcard)
Avant d'aller plus loin, je pousse la rom dans la sdcard via ADB
$ adb push ~/Téléchargements/aokp_maguro_build-27.zip /sdcard/
2333 KB/s (125522961 bytes in 52.534s)
Il n'y a plus qu'a choisir la ROM avec "choose zip from sdcard" et c'est fini.

2012-03-03

La faille photo Android

[billet écrit sur un MacBookPro ;)]

Ah ah ah ... Mac4Ever toujours les premiers sur les news moisies sur Android. Voici ma lecture d'un andro-convaincu : Mac4Ever a raison sur le fond et c'est flippant de simplicité ...

2012-03-02

FreeMobile devient Coucou-Networks.fr


Crédits : http://lpomoselle.oiseaux.net/
Hier, en lisant les logs de mon application DirectRepondeur j'ai eu la surprise de voir un curieux host apparaitre dans le rapport d'activité de lighttpd, coucou-networks.fr ????

Voici le rapport (odieusement pompé sur le rapport quotidien d'Apache de FreeBSD) :

   4 37-8-188-132.romanichel.net 
   4 37-8-184-38.romanichel.net