Affichage des articles dont le libellé est apk. Afficher tous les articles
Affichage des articles dont le libellé est apk. Afficher tous les articles

2013-10-02

ADB Lock non-root mode [fr / en]

English version below…

Android réserve ses fonctions les plus sensibles aux applications "système". C'est par exemple le cas de "Paramètres", l'application système que vous utilisez le plus souvent, qui est autorisée à activer ou désactiver ADB sans recourir au root.

Une application Système est une application classique : elle est au format APK, elle doit déclarer ses permissions. LA différence est qu'elle est placée dans /system/ (un dossier spécial et protégé) au lieu de /data/app comme toutes les autres apps.

L'app ADB-Lock est capable de détecter toute seule si elle est Système et dans ce cas cesse d'utiliser le mécanisme ROOT pour permuter l'état de l'ADB.

Il y a au moins 4 manières de passer ADB-Lock en mode Système : avec une app, avec le shell adb, avec un script  ou avec un zip (recovery ou TWRP). Bref vous avez l'embarras du choix.

2012-09-13

Achat in-app : attention aux signatures

APK avec signature de test vs signature développeur. 

 Le plug-in ADT pour Eclipse simplifie considérablement le travail de signature d'une application. En effet ADT signe avec une clef de test votre APK pour une future installation sur un terminal (ou émulateur).

Si pratique qu'elle soit, la clef de test sera refusée par le PlayStore : chaque développeur doit créer sa propre clef pour une signature unique.

Dans ce monde manichéen nous avons donc des APK signés avec la clef développeur sur le PlayStore et des APK signées par ADT. Et lorsqu'on essaye de faire un achat in-app :


Erreur liée à l'application
Cette version de l'application n'est pas configurée pour la facturation via Google Play. Pour plus d'informations, veuillez consulter le centre d'aide.


Ne cherchez pas trop longtemps le centre d'aide. Cette erreur est causée par la signature de l'APK.

Comment automatiser la signature avec sa clef de développement ?

Utilisons encore la documentation Android sur la signature avec jarsigner :
$ jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore my.keystore \
-storepass PA55W0RDST0RE -keypass PA55W0RDKEY my.apk myDevNickName

Il y a de très fortes chances que vous obteniez ce message :

jarsigner: unable to sign jar: java.util.zip.ZipException: invalid entry compressed size (expected 765 but got 771 bytes)

Ce message, comme son code erreur ne l'indique pas, est causé par la présence d'une signature dans l'APK : vous avez utilisé l'APK créée par ADT et stockée dans workspace/MyAndroidApp/bin/ qui est en fait signée avec la clef temporaire.

Pour supprimer la précédente signature, une simple commande zip (manpage):
zip my.apk -d "META-INF/*"

En un script : signandup.sh

#!/bin/sh
zip my.apk -d "META-INF/*"
jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore my.keystore \
-storepass PA55W0RDST0RE -keypass PA55W0RDKEY my.apk myDevNickName
adb install -r my.apk

2012-06-25

Maîtrisez vos versions beta avec Zubhium

[Billet non sponsorisé]

Google Play Store

Distribuer des versions instables de ses applications via le Play Store est périlleux pour la distribution et surtout pour son image de marque.

Le principal avantage est que l'utilisateur n'a pas besoin de changer les paramètres de son terminal pour installer l'application, on bénéficie des serveurs de google et on est tiré vers le haut par les exigences (capture d'écran, bannière, description, ...).

Comme inconvénients, il y a justement la lourdeur des informations obligatoires, l'absence de kill-switch et la suppression des versions anciennes (juste désactivées). Le principal inconvénient est (de très loin) la horde de crétins insidieusement infiltrée dans le reste des utilisateurs :

Jusqu'à présent j'utilisais l'auto hébergement avec un réducteur d'URL efficace et prévenais mes volontaires par sms/mail. C'est au détour d'une lecture de StackOverFlow que j'ai découvert Zubhium ...

La solution zubhium.com


Zubhium est un service en beta et gratuit qui se propose pour l'hébergement de vos apk, la notification des nouvelles versions, le recueil des crashlogs (optionnel) et des feedback (anonymes) des utilisateurs. Il faut préalablement s'inscrire et le système est prêt à fonctionner.

Déclarer un apk

Tout commence par la déclaration de votre beta. Plus simple que Google : un nom, une icône et une description.

L'étape suivante est l'envoi de l'apk, phase très simple qui fonctionne même si on utilise l'apk signée par Eclipse (disponible dans bin/ !).

La dernière étape est la déclaration des adresses e-mail des vos cobayes. Vos cobayes n'ont pas besoin de s'inscrire, l'adresse ne sert qu'à les prévenir.

Les règles de confidentialité sont précisées ici, à vous de juger de l'opportunité de déclarer telle ou telle adresse e-mail.

Vous pouvez également distribuer un lien direct vers votre beta en le copiant/collant dans un tweet par exemple.

Déclarer une nouvelle version


Les nouvelles versions sont nommées "push". Il n'y a que deux contraintes pour faire un nouveau push ce qui rend l'opération largement plus simple que sur le Play Store. Votre apk doit avoir une version supérieure aux "push" existants et vous devez déclarer les modifications apportées.

Ces modifications seront transmises à vos volontaires dans le corps de l'email de notification. Notez que jusqu'à présent il n'est pas nécessaire d’intégrer le SDK de Zubhium à l'application.

Bloquer une ancienne version

Plusieurs raisons peuvent vous emmener à clôturer une version : cesser de recevoir des crash-logs dus à un bug résolu, orienter vers une nouvelle beta ou tout simplement passer à la version officielle sur le site marchand de Google ou Amazon.

Pour pouvoir interagir avec une ancienne beta, il faut nécessairement intégrer le SDK. La documentation est suffisamment bien rédigée pour ne pas l'aborder dans ce billet. Si vous avez des soucis on peut en causer sur twitter.

Le blocage se fait dans l'onglet "Manage" et en cliquant sur "LIVE" :

L'interface vous propose de
  • Envoyer un message qui sera affiché à chaque démarrage de l'application dont la version beta a expiré.
  • Proposer aux utilisateurs un lien vers une beta plus récente OU un store (Google ou Amazon)
  • Forcer l'utilisateur à passer à la version officielle (Google ou Amazon) en bloquant complètement l'application (Kill-switch)

Les crashlogs


Comme précisé dans la documentation, Zubhium peut servir de back-end à ACRA et ainsi agréger les informations obtenues :

En savoir plus sur le terminal:

L'état du réseau :

La pile :

Les logs (que je n'active JAMAIS) :

Et le dump :

Limite plus pratique que DDMS non ?

Bilan

Ça marche et ça marche excellemment bien ! C'est un outil bien pensé et gratuit.

Le SDK permet, sans effort de développement de garder la main sur sa beta et de récupérer les crash de manière textuelle ET graphique. J'adooooore la possibilité d'uploader un apk non signé !

Il est dommage que la fenêtre de feedback ne soit pas (encore) internationalisée, ça peut freiner les cobayes anglophobes. Il y aurait également la possibilité de faire pointer la fin d'une beta vers la toute dernière version.

Bref, je souhaite à Zubhium un bon développement et de perdurer dans la philosophie KISS et surtout de perdurer dans le temps.

Nice works guys.

2012-04-23

Mettre à jour un Galaxy Nexus chiffré sans perdre de données.

Dans un précédent billet, je donnais une méthode propre pour passer son Galaxy Nexus en rom aokp. Propre, ok mais au prix de vos données.
Il est possible de mettre à jour la partie ROM du terminal sans toucher à la partie RWM. Simple sans être trivial, voici comment faire.
Attention, cette méthode de mise à jour est conforme à l'esprit de la norme ISO 1664.

Sauvegardez vos données. Sauvegardez vos données. Sauvegardez vos données.

Cette méthode n'a été vérifiée QUE et UNIQUEMENT sur un terminal chiffré équipé d'une ROM AOKP.

Préparer la rom AOKP qui va bien.

Durant cette phase, les commandes seront exécutées sur mon ordinateur personnel. La préparation doit se faire sur une machine séparée pour plusieurs raisons :
  • On ne peut pas échanger de données entre une session chiffrée et une session en clair (cwm).
  • Zip et Bzip2 sont des opérations gourmandes en temps CPU et I/O.
Le billet est réalisé avec la build 32 de la rom aokp récupérable ici
Une fois téléchargé, je prépare 2 archives supplémentaires : system.zip et system.tar.bz2
$ cd /tmp/
$ unzip aokp_maguro_build-32.zip
$ cd aokp_maguro_build-32/system/
$ # Création de l'archive ZIP
$ zip -r ../../system.zip *
$ # Création de l'archive tar.bz2
$ tar cjf ../../system.tar.bz2 *
Un ordre d'idée des tailles obtenues :
$ ls -alh  /tmp/system.*
 -rw-r--r--  1 ckg  ckg   107M 17 avr 14:23 /tmp/system.tar.bz2
 -rw-r--r--  1 ckg  ckg   108M 17 avr 14:20 /tmp/system.zip

Sauvegardez apk+data (méthode intelligente)

Pour une sauvegarde en toute tranquillité, utilisez Titanium Backup ou Rerware Backup sur le play store.

Sauvegardez apk+data (méthode barbare)

~ # # Création des dossiers
~ # mkdir /mnt/sdcard/backup/apk
~ # mkdir /mnt/sdcard/backup/apk-data
~ # # Sauvegarde des apk
~ # cp /data/app/*.apk /mnt/backup/apk
~ # cd /data/data/
~ # # Purge des caches
~ # rm -r */cache/*
~ # # Dans l'absolu, lib/ est optionnel
~ # for i in *;do tar cjf /mnt/sdcard/backup/apk-data/$i.tar.bz2 $i;done;
Si vous souhaitez récupérer les sous-dossiers de /mnt/sdcard/backup via MTP il faut forcer le daemon mtp à recharger sa liste de fichier :
~ # pkill -HUP f_mtp 
il ne reste plus qu'a sauvegarder la carte SD.

Shell minimal : Clockwork Mode Recovery

La suite des opérations se fait dans le mode recovery.
$ adb reboot recovery
Une fois le recovery actif, je lance une session shell.
Le mount m'indique que seule la partition /cache est chargée :
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/platform/omap/omap_hsmmc.0/by-name/cache on /cache type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
Visiblement, pas de /system monté. Le chemin pour trouver /system est indiqué par /cache.
Pour monter /system :
~ # mkdir /x
~ # mount /dev/block/platform/omap/omap_hsmmc.0/by-name/system /x/
On peut vérifier :
~ # ls /x/
addon.d     build.prop  framework   media       tts         xbin
app         etc         lib         su-backup   usr
bin         fonts       lost+found  system      vendor
La partition /system/ n'est pas chiffrée.
Si votre téléphone est saisi par un tiers vous pouvez le considérer comme corrompu. Je reviendrai un autre jour sur le "comment détecter la compromission d'un terminal". C'est la fin de la phase de préparation depuis le shell minimal.

Pousser la rom aokp complete

Normalement, vous devriez avoir la place de pousser la rom complete dans le /data/media de votre terminal. Depuis l'ordinateur :
$ adb push system.zip /data/media
Depuis la session shell (adb shell)
~ # unzip -o /data/media/system.zip -d /x/
Si vous obtenez "unzip: zip flags 1 and 8 are not supported", utilisez l'archive system.tar.bz2 définie plus haut alors, depuis l'ordinateur :
$ adb push system.tar.bz2 /data/media
Depuis la session shell (adb shell)
~ # cd /data/media/
~ # bunzip2 system.tar.bz2
~ # tar xf system.tar -C /x/

Fin

Avant de débrancher, il faut umount puis reboot :
~ # umount /x/
~ # reboot

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.