android

Intégrer les Google Apps à la compilation d’une rom Android

android
Posted on Leave a comment on Intégrer les Google Apps à la compilation d’une rom Android

Ce post décrit une méthode permettant d’inclure les Google Apps directement dans une rom Android.
Cela évite ainsi de devoir flasher l’appareil 2 fois de suite à chaque mise à jour de la ROM : une fois pour la rom elle-même, puis une seconde fois avec les Google Apps.

Ce post ne décrit pas comment compiler une ROM, il suppose que l’environnement est déjà en place et fonctionne !
L’intégration des Google Apps n’est clairement pas autorisée par Google dans le cadre d’une distribution publique de la ROM. La méthode n’est donc à faire que pour vos propres compilation et rien d’autre.

  1. La première chose à faire est évidemment de se procurer les Google Apps. Vous pouvez les trouver ici.
  2. Ensuite ouvrez un shell et sourcez le fichier ~/buid/envsetup.sh : source ${VOTRE_RACINE_ANDROID}/build/envsetup.sh
  3. Décompressez les Google Apps dans le dossier suivant $ANDROID_BUILD_TOP/vendor/extra/google. Créez le dossier s’il n’existe pas. Pour préciser, vous devriez avoir un fichier $ANDROID_BUILD_TOP/vendor/extra/google/install-optional.sh  après décompression
  4. Exécutez le script ci-dessous dans ce même shell
  5. Ouvrez le fichier $ANDROID_BUILD_TOP/vendor/asus/tf700t/tf700t-vendor.mk  (remplacez évidemment ce qu’il faut pour votre apareil) et ajoutez-y $(call inherit-product-if-exists, vendor/extra/google.mk)
  6. Plus qu’à lancer une compilation
#!/bin/bash
FOUT=$ANDROID_BUILD_TOP/vendor/extra/google.mk

cd $ANDROID_BUILD_TOP/vendor/extra/google
echo 'PRODUCT_COPY_FILES += \' > $FOUT
find system -type f -exec echo -e \\tvendor/extra/google/\{\}:/\{\} \\ \; | sort >> $FOUT
echo 'PRODUCT_COPY_FILES += \' >> $FOUT
find optional -type f -exec echo -e \\tvendor/extra/google/\{\}:/\{\} \\ \; | sort >> $FOUT

 

ERRATA: il faut enlever les 2 \ finaux qui trainent dans le fichier généré.

Accès nvFlash sur l’Asus Transformer Prime TF700T

android, hack
Posted on Leave a comment on Accès nvFlash sur l’Asus Transformer Prime TF700T
Avertissement : cette bidouille a le pouvoir de transformer votre tablette en brique technologique complètement inerte sans moyen de récupération. Ce tutoriel n’est pas destiné aux apprentis sorciers sans le sou et je ne pourrais pas être tenu pour responsable des conneries qui pourraient arriver à votre téléphone.

Description

Ce billet détaille la procédure permettant d’avoir un accès nvFlash à la tablette Asus Transformer Prime TF700T. La procédure a été testée avec succès sur ma tablette en Jelly Bean, plus précisément avec le firmware 10.6.1.14.10, le dernier mis à disposition à l’heure où j’écris. Jusqu’à récemment, il n’était possible de bénéficier de cet accès qu’avec la tablette en version ICS (Ice Cream Sandwich).

L’accès nvFlash, est un accès très bas-level, dont le principal intérêt est de pouvoir récupérer sa tablette quelque soit son état, notamment et surtout suite à un flash moisi. En d’autre terme, on bénéficie ainsi d’une tablette « brick-safe ».

Vu qu’ASUS permet de déverrouiller suffisamment le bootloader pour installer des roms customs, mais pas suffisamment pour éviter de la transformer en brique, l’accès nvFlash est donc plutôt recommandé, bien que la procédure soit risqué.

Pré-requis

Vous avez besoin :

  • des pilotes Windows. Ceux-ci sont signés afin de pouvoir les utiliser simplement sous Windows 8. Il s’agit des pilotes fournit par Google, auxquels j’ai ajouté les identifications de l’ASUS Transformer Prime TF700T et du Nexus 4, que j’ai signé avec mon propre certificat. Etant donné la nature de mon certificat, ces pilotes expireront en 2015.
  • de nvFlash (à télécharger sur le site de AndroidRoot)
  • un recovery spécialement modifié (à télécharger sur le site de AndroidRoot)
  • une tablette déverouillée

Déverrouiller la tablette

Installez et exécutez l’application Unlock_v8. Elle n’est officiellement compatible qu’avec Jelly Bean. Pour Ice Cream Sandwich, il vous faut la version v7, disponible sur les serveurs d’Asus.

Obtention de l’accès APX

La procédure n’est à faire que la première fois. Elle permet de construire un blob permettant de déverrouiller les commandes en mode APX. Ce blob est nécessaire à chaque fois qu’on désire accéder au mode APX.

  1. Sauvegardez tout ce dont vous avez besoin sur la tablette, y compris la mémoire interne ; on n’est jamais trop prudent
  2. Branchez la tablette au PC si ce n’est déjà fait
  3. Démarrez la tablette en bootloader.
    • A partir de la tablette éteinte, appuyez sur Power, puis sur Volume-Down jusqu’à voir trois icônes au milieu : RCK (pour accéder au recovery), Android (pour démarrer Android), et la dernière icône pour une réinitialisation de la tablette
    • A partir de la tablette allumée, envoyez la commande adb reboot-bootloader , c’est le plus simple
  4. Flashez le recovery spécial: fastboot flash boot flatline_tf700.img . Si le transfert dure plus de 5 min, vérifier les points suivants :
    1. la tablette est bien reconnue sous Windows. Si ce n’est pas le cas, le câble USB est peut-être mal enfichée, ou il faut tester avec une autre prise USB, ou bien tentez de passer dans le bootloader avec la commande adb.
    2. sinon tentez de renommer le fichier en tf700.img  (sans underscore) et réessayez
  5. Redémarrez la tablette complètement dans le bootloader (c’est à dire, n’accédez pas directement au recovery // normalement (avec Volume-Up pour sélectionnez l’item du milieu, puis Volume-Down pour valider) , sous Android, puis repassez dans le bootloader
  6. Accédez au recovery en validant l’item RCK
  7. Sélectionnez dans les menus : Advanced > Wheelie
  8. Acceptez l’avertissement, puis sélectionnez l’étape 1 : « Step 1: Flash AndroidRoot BL »
  9. La tablette devrait s’éteindre. Allumez-la normalement sous Android, puis repassez dans le recovery (via le bootloader ou bien avec la comande @@adb reboot recovery@@)
  10. Dans le recovery, sélectionnez Advanced > Wheelie
  11. Acceptez à nouveau l’avertissement, puis sélectionnez l’étape 2 : « Step 2: Generate wheelie blobs ». L’opération va prendre un certain temps…
  12. Une fois terminez, récupérez les blobs avec la commande indiqué dans la console. Gardez les au moins en double exemplaire, ils sont indispensable pour accéder au mode APX, et ce dernier est le seul moyen permettant de récupérer sa tablette sans l’envoyer en SAV.
  13. Vérifiez que vous avez bien accès au mode APX en passant à la section suivante

Accès au mode APX

Le mode APX n’est accessible qu’à partir de la tablette à l’état éteint. La combinaison de touche est la suivante : Power suivit de Volume-Up.
Si la combinaison a bien été réalisée, l’écran de la tablette devrait s’éteindre, et le PC devrait reconnaître un nouveau périphérique intitulé APX.

Le déverrouillage des commandes APX se fait à ce moment là en tapant la commande suivante : wheelie –blob blob.bin  où blob.bin  correspond à l’un des fichiers récupérés avec le recovery modifié. Si le blob est reconnu et accepté par la tablette, wheelie  devrait afficher l’id de la tablette et l’écran devrait afficher le bootloader.

Si c’est la première fois que vous accédez au mode APX, il est vivement conseillé de sauvegarder également certaines partitions :

  • une image utile dans la récupération de sa tablette : nvflash -r –rawdeviceread 0 2944 bricksafe.img
  • la configuration d’usine avec la commande nvflash -r –read 14 14_factory-config.img
  • le token de déverrouillage du bootloader nvflash -r –read 7 07_unlock-token.img
  • d’autres partitions peuvent être sauvegardées avec le paramètre read, en spécifiant le numéro de la partition. La liste des partitions est décrite ci-dessous.

On quitte le mode APX avec la commande nvflash -r –go .

Table de partitions

La tablette TF700T contient au moins 18 partitions :

  • Partition 02 : BCT, le Boot Configuration Table.
  • Partition 03 : PT, le Partition Table
  • Partition 04 : EBT, le Encrypted Bootloader
  • Partition 05 : SOS, le recovery kernel
  • Partition 06 : LNX, le kernel linux
  • Partition 07 : CER, le bootloader unlock token
  • Partition 08 : IMG
  • Partition 09 : GP1, espace libre pour une table de partition GP1
  • Partition 10 : APP, partition /system, ext4
  • Partition 11 : CAC, partition /cache, ext4
  • Partition 12: MSC, partition /misc, ext4
  • Partition 13 : USP, Upgrade Staging Partition, monté sur /stating et au format ext3. Utilisé durant les mises à jour du firmware
  • Partition 14 : PER, partition /btmac monté durant le boot, au format fat32. Contient des données système spécifique au périphérique
  • Partition 15 : YTU, contient peut-être des données de chiffrage pour les DRM.
  • Partition 16 : CRA, usage inconnu
  • Partition 17 : UDA, /data, ext4.

Ces partitions peuvent être sauvegardées

Le Bootloader

Le bootloader est accessible en appuyant sur Power puis Volume-Down lorsque la tablette est éteinte. Il est également possible d’y accéder depuis Android en tapant adb reboot-recovery .
Une fois dedans, 4 options sont disponibles :

  • la commande fastboot, à condition que la tablette soit déverrouillée
  • le recovery (la première icône RCK)
  • la continuation du démarrage normal sous Android (la seconde icône Android)
  • la réinitialisation de la tablette (wipe data/cache, c’est la dernière icône)

On navigue entre les différentes icônes avec Volume-Down, et on valide l’item sélectionné avec Volume-Up.
A partir d’un certain temps, le bootloader peut sembler être planté ou super long, mais tant qu’on n’a pas bidouillé avec fastboot, c’est juste qu’il est très long.

Voir aussi

Construction d’une chaîne de compilation pour Android

android, développement, gentoo
Posted on Leave a comment on Construction d’une chaîne de compilation pour Android

Il existe plusieurs méthodes pour avoir une chaîne de compilation pour le système Android. Mais pourquoi une toolchain ? Android est un système d’exploitation basé sur le noyau Linux et dédié aux processeurs de type ARM (actuellement, c’est le cas). Il ne s’agit donc pas de processeurs « classiques » de type x86 ou ia64, et par conséquent, les chaînes de compilation fournies avec les distributions Linux ne sont pas adaptées, car elles ne peuvent générer que du code x86 ou ia64…

Avertissement : Pour l’instant, j’ai réussi à compiler un kernel qui boot, mais j’ai perdu la radio, j’ai seulement le wifi.
Cet article est donc présent surtout à des fins théoriques ou pour les plus persévérant à commencer les bidouilles de bas niveau :p.

Quelques chaînes de compilation pour architecture arm

  • Gentoo, avec son paquet crossdev. Actuellement non fonctionnel chez moi.
  • la chaîne de compilation pré-compilé fourni par le SDK d’Android. Actuellement non fonctionnel chez moi.
  • la chaîne de compilation fournie par crosstool-ng. La plus configurable, la plus chiante à mettre en place, mais la seule qui a marché.

Il est possible que les autres chaînes de compilation marchent parfaitement bien, j’ai juste du louper un truc sur les paramètres à passer… c’est dire que contrairement au monde x86, des architectures ARM, il y en a à la pelle et pas souvent compatibles entre elles (pas sans recompilation).

Cette article détaillera uniquement la dernière chaîne de compilation, qui a l’avantage d’avoir beaucoup de paramètres que l’on peut utiliser pour optimiser sa chaîne.

Les étapes décrites ci-dessous s’appliquent à Gentoo, mais peuvent s’appliquer à n’importe quel UNIX-like avec quelques modifications mineures.

# si ce n'est pas déjà fait, on installe git
emerge -v git

# récupération du kernel cyanogen
export KERNELDIR=/home/kernel-cyanogen
export CROSSTOOLDIR=/home/crosstool-ng
mkdir -p $KERNELDIR
cd $KERNELDIR
#git clone git://github.com/CyanogenMod/cm-kernel.git
# pour certains appareils htc dont le vision, un autre repo est utilisé
git clone git://github.com/CyanogenMod/htc-kernel-msm7x30.git
# aller boire un café, ça va prendre 10bonnes minutes...
#cd cm-kernel
cd htc-kernel-msm7x30
make headers_install ARCH=arm INSTALL_HDR_PATH=../kern_h/

# construction de la toolchain
echo 'sys-devel/ct-ng' >> /etc/portage/package.keywords
emerge -va ct-ng
eselect bashcomp enable ct-ng --global
mkdir -p $CROSSTOOLDIR
cd $CROSSTOOLDIR
# placez le fichier uClibc.config ici, depuis l'archive à télécharger
#mv XVilka-uClibc-msm7200a.config uClibc.config
ct-ng menuconfig

Ci-dessous les changements à effectuer pour le menuconfig de crosstool-ng

Paths and misc options --->
(1) Number of parallel jobs
Target options --->
Target Architecture (arm)
(armv7-a) Architecture level
(cortex-a8) Emit assembly for CPU
(vfpv3) Use specific FPU
(-O2) Target CFLAGS
Toolchain options --->
(android) Tuple's vendor string
Operating System --->
Target OS (linux)
Linux kernel version (2.6.37.6) // à adapter en fonction de la version du kernel du cyanogenmod
C compiler --->
[*] C++
[*] Java
C-library --->
C library (uClibc)
(uClibc.config) Configuration file
Threading implementation to use: (linuxthreads)

Et on retourne à la ligne de commande…

ct-ng build
# là on reprend une tasse de café

# récupération des sources du cyanogenmod
export CYANODIR=/home/cyanogen
cd $CYANODIR
repo sync
make adb
export PATH=/out/host/linux-x86/bin:$PATH

# compilation d'un nouveau kernel
export _XXCFLAGS=" -march=armv7-a -mtune=cortex-a8 -mfpu-abi=softfp -mfpu=vfpv3 -O2"
export PATH=~/x-tools/arm-android-linux-uclibcgnueabi/bin:$PATH
export CCOMPILER=~/x-tools/arm-android-linux-uclibcgnueabi/bin/arm-android-linux-uclibcgnueabi-
cd $KERNELDIR/htc-kernel-msm7x30
# branchez le téléphone au pc
adb pull /proc/config.gz .
zcat config.gz > .config
# menuconfig pour changer deux ou trois choses avant de compiler (à faire avec beaucoup de précautions)
CFLAGS=$_XXCFLAGS make ARCH=arm CROSS_COMPILE=$CCOMPILER menuconfig
CFLAGS=$_XXCFLAGS make ARCH=arm CROSS_COMPILE=$CCOMPILER oldconfig
CFLAGS=$_XXCFLAGS make ARCH=arm CROSS_COMPILE=$CCOMPILER -j`grep 'processor' /proc/cpuinfo | wc -l` all
cd $CYANODIR/device/htc/vision
mv kernel kernel.bak
mv modules/bcm4329.ko modules/bcm4329.ko.bak
ln -s $KERNELDIR/htc-kernel-msm7x30/arch/arm/boot/zImage kernel
ln -s $KERNELDIR/htc-kernel-msm7x30/drivers/net/wireless/bcm4329/bcm4329.ko modules/
cd $CYANODIR
. build/envsetup.sh && brunch cyanogen_vision-eng

Et voilà, plus qu’à flasher.

Tous les crédits vont à XVilka, pour avoir décrit sa méthode pour le milestone.

Voir aussi

Importer des certificats d’autorité racine dans Android 2.x

android, hack
Posted on Leave a comment on Importer des certificats d’autorité racine dans Android 2.x

Comme d’habitude comme tout ce qui concerne une manip sous Android nécéssitant l’accès root, je fourni ce tutoriel sans aucune garantie contre la casse ni la bêtise. A vos risques et périls donc.

Il peut arriver de se monter sa propre PKI (pourquoi pas), et de l’utiliser à tout va pour crypter les échanges entre son mobile et ses sites web (les urls qui commencent par https://), ou son serveur de mails perso (pour utiliser pleinement TLS ou le SSL implicite). Bref, pour tous ceux qui voudraient ajouter un certificat d’autorité racine dans leur téléphone Android pour valider tout ce qu’il y a à valider, voici la marche à suivre.

Tout d’abord le matériel requis pour la manipulation :

# on récupère le magasin de certificats depuis son téléphone vers son PC, c’est là que l’ADB devient utile :

adb root
# extract certificates store on the computer
adb pull /system/etc/security/cacerts.bks cacerts.bks
# import mon-ca.crt to the store
keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -importcert -trustcacerts -alias MON-CA -file mon-ca.crt
# type "yes" to confirm the import of the new ca cert
# remount android /system as read-write
adb shell mount -o remount,rw /system
# push the new store
adb push cacerts.bks /system/etc/security
# remoube android /system as read-only
adb shell mount -o remount,ro /system
# done ;)

Plus qu’à redémarrer le téléphone pour qu’il prenne le nouveau CA en compte.

Mettre à jour le Milestone en version 2.0.1 avec le root

android, hack
Posted on Leave a comment on Mettre à jour le Milestone en version 2.0.1 avec le root
Avertissement : cette bidouille a le pouvoir de transformer votre téléphone en brique technologique complètement inerte sans moyen de récupération. Ce tutoriel n’est pas destiné aux apprentis sorciers et je ne pourrais pas être tenu pour responsable des conneries qui pourraient arriver à votre téléphone.

La technique décrite ci-après est dédiée au Motorola Milestone (la déclinaison européenne du Droid), en version 2.0 (la version d’origine). Elle fonctionne, je l’ai testé sur mon propre Milestone.

Remarque: officielle ou pas, la mise à jour 2.0.1 est une mise à jour différentielle, c’est à dire que tous les fichiers systèmes doivent être d’origine. Si vous avez enlevé des apk systèmes par exemple, il faudra les remettre avant d’effectuer la mise à jour, sinon celle-ci échouera lamentablement.

Instructions

  1. Primo, on récupère la mise à jour trafiquée, permettant l’ajout et l’accès au programme su. Ce fichier met à jour le Milestone de la version 2.0 à la version 2.0.1 et ajoute l’accès au root. Il n’est donc pas nécessaire de rooter le téléphone avant d’appliquer cette mise à jour. Télécharger update-2.0.1-no-recovery
  2. Placez cette mise à jour à la racine de la sdcard sous le nom update.zip
  3. Deuxio, passez en mode recovery. Deux techniques pour cela :
    1. Si vous avez un pc avec l’adb pas loin, branchez le téléphone et taper la commande adb reboot recovery . Le redémarrage est instantané et simple. Vous voilà en recovery.
    2. Sinon éteignez le portable complètement puis pressez la combinaison de touche suivante : pressez le bouton doré puis sans relâcher, le bouton on/off. Dès que l’écran s’allume, vous pouvez relâcher les boutons. Vous voilà en recovery.
  4. Affichez le menu du recovery en pressant la touche ‘volume up’ puis sans relâcher le bouton dorée. Un menu s’affiche, vous pouvez relâcher la combinaison de touches.
  5. Sélectionnez ensuite l’entrée ‘apply sdcard:update.zip’ avec les touches directionnelles puis validez.

Quelques informations sur cette mise à jour.

Le zip donné ici est basé sur la mise à jour officielle pour la version Européenne, il ne s’agit donc pas d’un hybride venu d’Hong-Kong, mais bien de la mise à jour qui vous est proposée par le téléphone lui-même.
Le script d’installation de cette mise à jour a été modifié sur le même principe utilisé pour avoir le root avec le Milestone 2.0.
Ce nouveau script d’installation effectue la même chose que le script initial, mais ne flash pas le recovery pour conserver la faille des mises à jour non signées, et push su avec les bons droits pour avoir l’accès root.

Je remercie caohung et poseidon pour les modifications apportées à la mise à jour officielle.

Enjoy

SHA-1 du fichier update-2.0.1-no-recovery.zip : 62E13F64F44AE56C53EE7BDE249717E7402365B4

Rooter le Motorola Milestone

android, hack
Posted on Leave a comment on Rooter le Motorola Milestone
Avertissement : cette bidouille a le pouvoir de transformer votre téléphone en brique technologique complètement inerte sans moyen de récupération. Ce tutoriel n’est pas destiné aux apprentis sorciers et je ne pourrais pas être tenu pour responsable des conneries qui pourraient arriver à votre téléphone.

La technique décrite ci-après est dédiée uniquement au Motorola Milestone (la déclinaison européenne du Droid), en version 2.0 (la version d’origine). Elle fonctionne, je l’ai testé sur mon propre smartphone.

Instructions

  1. Primo, on récupère la mise à jour trafiquée, permettant l’ajout et l’accès au programme su. Ce fichier ne met rien à jour, il ne fait qu’ajouter l’accès au root. Télécharger update-root.
  2. Placez cette mise à jour à la racine de la sdcard sous le nom update.zip
  3. Deuxio, passez en mode recovery. Deux techniques pour cela :
    1. Si vous avez un pc avec l’adb pas loin, branchez le téléphone et taper la commande adb reboot recovery . Le redémarrage est instantané et simple. Vous voilà en recovery.
    2. Sinon éteignez le portable complètement puis pressez la combinaison de touche suivante : pressez le bouton doré puis sans relâcher, le bouton on/off. Dès que l’écran s’allume, vous pouvez relâcher les boutons. Vous voilà en recovery.
  4. Affichez le menu du recovery en pressant la touche ‘volume up’ puis sans relâcher le bouton dorée. Un menu s’affiche, vous pouvez relâcher la combinaison de touches.
  5. Sélectionnez ensuite l’entrée ‘apply sdcard:update.zip’ avec les touches directionnelles puis validez.

Quelques informations sur cette mise à jour.

Le recovery du Milestone 2.0 présente une faille permettant de lui faire accepter des mises à jour mal-formées. Pour faire court, en accolant un zip officiel et signé à un zip contenant le nécessaire pour le root, on obtient un autre zip valide (accepté par le recovery) qui est la fusion des deux zips précédent. Ce zip final contient un script d’installation permettant l’ajout de su avec les bons droits et SuperUser.apk.

Pourquoi rooter son téléphone ?

Si vous ne connaissez pas la réponse à cette question, il est plus prudent de ne pas faire cette manipulation.%%%
Sinon les réponses sont assez diverses pour ma part :

  • flinguer les mises à jour OTA
  • naviguer dans le système de fichiers Android sans aucune restrictions
  • récupérer les *.apk (les applications du market) pour en faire une sauvegarde, y compris les apk chiffrés
  • tuner en profondeur le matériel comme l’utilisation cpu avec SetCPU (undercloacker lorsque le téléphone n’est pas utilisé par exemple)
  • ne pas attendre le bon vouloir de Motorola et faire de mon téléphone ce que je veux
  • …

Un grand merci à SeraphimSerapis, Andrea et Zinx Verituse pour avoir trouvé cette faille et avoir su l’exploiter.

Voir aussi

SHA-1 du fichier update-root.zip : 07DA7B71420D013D12885BD148BF3E9661034CC0

Enjoy