Partager
Affiche les résultats de 1 à 5 sur 5

Sujet : Android When Google said "YES WE DROID"

  1. #1
    Inscrit
    juin 2012
    Lieu
    Not Available
    Messages
    537
    Remerciements
    15
    Remercié(e) 188 fois dans 140 messages
    Pouvoir de réputation
    8

    Android When Google said "YES WE DROID"

    "D’après Google, Android est une plate-forme logicielle destinée aux appareils mobiles comprenant un système d’exploitation, des applications, et les couches intermédiaires nécessaires pour faire fonctionner le tout. Nous remarquons d’entrée de jeu que Google se place dans le domaine du logiciel. Android n’est donc pas lié à un appareil donné ; il a au contraire vocation à être intégré par différents constructeurs dans des appareils mobiles,moyennant le respect de quelques règles de compatibilité."

    Meet the legend :
    Lorsque Google annonça en octobre 2008 la mise à disposition du code source, ce fut une motivation supplémentaire pour s’intéresser à ce système. La lecture du code leva le voile sur de nombreux aspects du système qui avaient jusque là dû être devinés par tâtonnement, faute de documentation.

    En plus des constructeurs de matériel, Google entend fédérer autour d’Android tout un écosystème de développeurs et d’utilisateurs « avertis », créateurs de contenu. Pour leur
    faciliter la tâche, il a été prévu dès le départ qu’Android serait facilement programmable.
    C’est le langage Java qui a été retenu et Google fournit aux développeurs de nombreux outils pour écrire et mettre au point leurs programmes : émulateur pour les tests, SDK Java et plugin Eclipse pour le développement, ainsi qu’une documentation fournie, disponible sur internet Android em !

    Android a des couches : ( sans commentaires )
    Voici un shema qui représente les couches constituante d'Android :


    Question :
    Crois - tu vraiment que je vois de quoi "sa s'agit" ?
    Réponse :
    Ehh bein on va rendre sa plus facile a comprendre

    Explication :
    Hardware :
    Au plus près du matériel, on trouve le système d’exploitation. Il s’agit d’un noyau Linux 2.6 standard, auquel Google a apporté quelques améliorations, notamment dans le domaine de la gestion de l’énergie (appareil mobile oblige) et de la communication inter processus. Précisons que pour l’instant, Android tourne sur des processeurs embarqués de type ARM, qui sont nativement gérés par Linux.

    Librairie :
    Vient ensuite la couche des bibliothèques. Google a écrit pour Android sa propre bibliothèque C, bionic, dont la faible taille est adaptée à un environnement embarqué. On trouve aussi d’autres bibliothèques, dont beaucoup seront familières aux utilisateurs de Linux : Webkit, SQLite, OpenGL, SGL, SSL, ainsi qu’une bibliothèque multimédia.

    Runtime : ( valdik VM )
    Directement sur cette couche vient se greffer le runtime Android, qui comprend la machine virtuelle Java et ses bibliothèques. Cette machine virtuelle, développée spécifiquement pour Android, porte le nom de Dalvik virtual machine. Conçue pour fonctionner dans un environnement embarqué limité en ressources, elle utilise un format d’exécutable compressé (.dex), afin de minimiser l’empreinte mémoire.

    Plate-forme logicielle :
    La couche « plate-forme logicielle » permet quant à elle de mutualiser au maximum les ressources
    entre applications Java. Elle propose également un moyen pour ces applications d’échanger des données. On retrouve par exemple dans cette couche la boîte à outils graphique qui permet d’afficher des boîtes de dialogue, des boutons, des menus, etc. C’est cette couche qui est rendue disponible au développeur Java au moyen d’un ensemble d’API.

    Application :
    La dernière couche, la seule finalement dont l’utilisateur aura à se préoccuper, est celle des applications. Elle sont sous forme de paquets .apk, qui permettent une installation et une
    désinstallation facile. Certaines sont fournies par l’équipe Android : navigateur web, gestionnaire de contacts, agenda… à vous de compléter la liste avec vos propres programmes !

    Le SF :
    La hiérarchie des fichiers d’Android peut paraître déroutant pour quiconque a un peu l’habitude des système Unix (et a fortori pour quiconque n’y est pas du tout habitué !). Pas
    de répertoire /bin, ni de /home, mais un dossier /system. Les fichiers de configuration, que l’on s’attend à retrouver dans /etc, sont en fait pour la plupart stockés dans une base
    de données. Ce système n’a clairement pas été conçu pour être exposé directement à l’utilisateur !

    À ces répertoires sont en fait associés (au sens Unix mount) les images système suivantes :
    - ramdisk.img est associée à la partition racine /, au format rootfs,
    - system.img est associée au dossier /system, au format yaffs2, conçu pour la mémoire flash,
    - dans l’émulateur, /data est associé au fichier ~/.android/SDK/userdata-qemu.img, en yaffs2,
    - enfin, /sdcard correspond sur le téléphone à la carte SD, au format FAT – sur l’émulateur, il est possible dans les options de démarrage de charger une image FAT à la place.

    User Side :
    Pour pouvoir l'utiliser deux choix se pose devant vous :
    - Dll l'iso en question juste
    - Utiliser l'émulateur d'android proposé sur leur site web

    Remarque :
    Personnellement , j'ai commencé par l'iso que j'ai utilisé comme VM (avec VMware Workstation ) , et le résultat fut probant , CA MARCHE NICKEL sauf pour la carte son qui n'été pas détecté , donc je suis passé par l'émulateur pour modifier le kernel ( article en anglais pour m'aider ) et sa fonctionner , bon le test a été éfféctué sur un HP mini avec "Windows Starter" installé par default que j'ai vite remplacé par un "Linpus Light" ( non mais ) mais n’empêche ma carte a été détecté ( atheos ) ..... bon après j'ai crié un bon coup ( de joie )

    Les premiers modèles (téléphones G1) sont arrivés sur le marché aux USA fin 2008, puis ont été diffusés dans de nombreux autres pays. ( tous sauf chez nous => elle a sautée LA CIVILISATION )
    Bref, pour répondre à la demande de nombreux développeurs, Google a mis sur le marché un téléphone qui leur est dédié, le Dev Phone 1. Contrairement aux téléphones destinés au grand public, dont les couches basses sont parfois verrouillées , le Dev Phone 1 est prévu pour être modifié facilement : il est en effet possible de remplacer l’image système (firmware) par une image personnalisée.


    Dev Side :
    Pour l'installer je suis aller voir (ailleurs si j'y été mais enfet non , donc je suis de retour ..3..2..1) leur site web Android Web Site pour Dll le SDK (un fichier zip) .

    Une fois décompresser j'ai ajouter à la variable d’environnement PATH le chemin du répertoire tools de l’archive ca c'est pour Winduff euhh je veux dire Windob .

    Sous linux :
    Code:
    export PATH=$PATH:android-sdk-linux_x86-version/tools
    En utilisant la console ; et pour vérifier si on est bon ou pas ( j’espère que oui ) , tous simplement en tapant emulator dans la console et une interface va s'afficher sur l'écran , l'interaction se fait par le biais des périphériques d'entrée .

    Remarque :
    Pour pouvoir interagir avec les couches basse de l’émulateur , l'outil adb est a votre disposition .
    Dernière édition par TeamWorK; 25/06/2012 à 18h05
    Not Available

  2. # ADS
    Inscrit
    Toujours
    Lieu
    Monde des annonces
    Messages
    Plusieurs






     
  3. #2
    Inscrit
    juin 2012
    Lieu
    Not Available
    Messages
    537
    Remerciements
    15
    Remercié(e) 188 fois dans 140 messages
    Pouvoir de réputation
    8

    Re : Android When Google said "YES WE DROID"

    Compiler Du Code Sous Android :


    Rappel :
    Comme nous l’avons vu dans l’introduction, Google a choisi de donner au développeur l’accès aux seules couches « hautes » à travers le langage Java. Il reste cependant possible de contourner cette limite et de programmer directement en C et en C++ pour accéder à toutes les couches, jusqu’au noyau. En effet, une fois maîtrisée la compilation C, rien n’empêche d’écrire des modules pour le noyau Linux.

    Remarque :
    Comme j'ai si bien expliqué ( bein je trouve que j'explique bien ) , la suite sera destiné aux développeur C/C++

    Pourquoi ne pas se contenter de Java ? ( la question qui fâche )
    C'est partis pour le troll .....

    1- Les performances: ce n’est pas une surprise, le code C compilé sera plus rapide qu’un code Java équivalent. Ceci est d’autant plus vrai que la machine virtuelle Java d’Android (la Dalvik Virtual Machine) n’a pas été conçue pour être particulièrement rapide . Les programmes pour lesquels la rapidité est un critère important seront donc plutôt écrits en C ou C++, quitte à faire une interface en Java.

    TeamWorK's Knowledge :
    La Dalvik Virtual Machine ne possède pas de compilateur JIT (Just in Time ..... qui n'est pas une règle de gestion de stock ..... celle de Toyota ). Il s’agit là pourtant d’une optimisation classique pour les machines virtuelles. Les développeurs de Google justifient leur choix ainsi : selon eux, la plupart des programmes Java pour lesquels les performances sont cruciales peuvent soit faire appel à des bibliothèques optimisées fournies par Google, soit utiliser un accélérateur matériel, soit appeler un programme C rapide écrit pour l’occasion.
    Précisons que la Dalvik Virtual Machine a été conçue avant tout pour avoir une empreinte la plus faible
    possible, en terme de mémoire et de consommation d’énergie. ( ce qui explique son utilisation pour Android avec sa plateforme basse consommation/puissance) .


    2- L’utilisation de programmes existants : pouvoir utiliser le langage C ou C++ donne immédiatement accès à une quantité impressionnante de programmes tiers, notamment des programmes Open Source. C’est le cas par exemple de la plupart des programmes destinés aux systèmes Unix. Ceux-ci étant fournis avec le code source, il est souvent possible de les compiler et de les utiliser directement sur Android.

    3 - L’accès direct au système : en l’absence de machine virtuelle, un programme C accède directement au système Linux d’Android. Cela permet d’éliminer une grande partie des limitations imposées par la machine virtuelle (souvent pour des raisons de sécurité). On peut par exemple accéder à l’ensemble du système de fichiers, ou lancer des programmes en tâche de fond avec une priorité ajustable.

    4 - La programmation de pilotes : il est certains domaines pour lesquels le langage C est le seul choix possible. C’est le cas, par exemple de la programmation de pilotes de périphériques. Ceux-ci doivent pour des raisons de compatibilité être écrits dans le même langage que le noyau Linux (le langage C, donc...).

    Quelle méthode de compilation choisir : avec ou sans SDK ?

    Moi j'opte et j'ai toujours opté pour la méthode DSK euhh je veux dire SDK . Alors pourquoi ?

    1 - Type d'application :
    Et bien , c'est un choix une fois que l'on sais que le résultat et similaire , cependant cela differe si en souhaite diffuser l'application .
    En effet, si écrire en C ou C++ n’est officiellement pas permis sous Android, cela l’est encore moins lorsqu’on utilise une chaîne de compilation tierce. Pour l’instant, le seul moyen de placer du code C ou C++ sous Android de façon stable est de développer avec le SDK et de placer son code dans le dépôt officiel sous une licence libre.( pour des raison précédemment cités )
    Plus d'information sur le site : GroupsGoogle

    2 - Application :
    Cela dépend également de l’application elle même, de sa taille et de ses dépendances. La bibliothèque C fournie par le SDK, bionic, est en effet assez limitée, et certaines fonctionnalités offertes par exemple par la bibliothèque C GNU ne sont pas présentes. À moins de réécrire le code, il n’y a alors pas d’autre solution que de compiler en statique avec une chaîne telle que scratchbox, qui intègre la bibliothèque C GNU.

    3 - Votre investissement :
    Cela dépend de l’investissement auquel vous consez, en terme de temps et de travail. car le coût initial pour placer son application dans le SDK Android soit plus élevé. Tout d’abord parce qu’il faut compiler tout le SDK avant de pouvoir l’utiliser, ce qui prend du temps, de la place disque et de la patience.

    Mais pour résumé tous ca , faisant une comparaison :
    Méthode SDK :
    - Compatibilité avec Android .
    - Taille des programmes .
    Méthode scratchbox :
    - Facilité de mise en oeuvre
    - Richesse de la bibliothèque C
    - Compatibilité avec des projets existants


    Voila , espérons que sa vous a intéressés , je sais que certains diront "Trop de Parlotte" mais c'est une étape importante donc prenez votre mal en patience .

    A Venir : Outils de compilation à installer et a configurer
    Dernière édition par TeamWorK; 26/06/2012 à 11h16
    Not Available

  4. #3
    Inscrit
    juin 2012
    Lieu
    Not Available
    Messages
    537
    Remerciements
    15
    Remercié(e) 188 fois dans 140 messages
    Pouvoir de réputation
    8

    Lightbulb Re: Android When Google said "YES WE DROID"

    [Ok , on reprends .

    Outils de compilation à installer et a configurer


    Remarque :
    Bon je vais pas ressortir le fameux speech autour des outils a bien installer et bien configurer pour ne pas avoir de problème de compilation ( quoi que je l'ai fais ) , je dis ca car on va compiler du bon code en C .

    Rappel :
    Développer en C pour Android nécessite d’avoir au préalable installé un compilateur. En temps normal, la compilation d’un programme C est chose aisée. Le compilateur, généralement fourni par défaut sur les systèmes Unix, sait produire du code machine pour l’ordinateur sur lequel il est installé.
    Il en va tout autrement dans notre cas : le compilateur doit produire du code non pas pour l’ordinateur, mais pour Android...

    Compilation croisée :

    TeamWorK's Knowledge :
    Un compilateur croisé est un soft qui permet de traduire un code ayant un environnement d’exécution différent de celui ou la compilation est effectuée , le DAS de ces compilateurs touche les OS et systèmes embarqués .


    Il nous faudra donc installer :
    - Un compilateur spécial, capable de produire du code non pas pour le processeur de l’ordinateur (par exemple, un processeur Intel type x86), mais pour un processeur ARM (sur lequel tourne Android) .
    - En plus du compilateur, tout un ensemble d’outils appelé "binutils" : l’éditeur de liens, l’assembleur, etc.
    - Les versions "ARM" des bibliothèques, et notamment de la bibliothèque C.

    PS:
    Ca devrait marché même pour les plateformes "Intel" .

    Remarque :
    Tous ces programmes sont souvent regroupés en des « chaîne de compilation croisée » , qui facilitent l’installation de l’environnement de développement.

    Installation de la chaîne de compilation croisée libre Scratchbox :
    Scratchbox est une chaîne de compilation croisée libre, disposant d’une version pour processeur ARM. Pour l’installer, il faut tout d’abord télécharger les paquets suivants à cette adresse : Download Page
    - core-1.0.1
    - devkit-cputransp-1.0.7
    - libs-1.0.10
    - toolchain-arm-linux-2007q1-21-1-07


    Remarque :
    Je vais assumé que vous avez deja travaillé sur un environnement sous linux .( commandes linux )

    Chacune de ces archives devra ensuite être extraite en tant que root grâce à la commande suivante :
    Code:
    # tar zxf <archive> -C /
    Voila, l'installation est terminé , passant maintenant a la Scratchbox.

    Configuration et démarrage de Scratchbox :
    La commande suivante doit être tapée en tant que root. On utilisera les valeurs par défaut.

    Code:
    # /scratchbox/run_me_first.sh
    On ajoute ensuite un utilisateur (par exemple l’utilisateur courant), avec la commande suivante (toujours en tant que root) :

    # /scratchbox/sbin/sbox_adduser <utilisateur>

    Voila notre chère user fait désormais partis du groupe sbox ( bienvenue ) , on peut aussi vérifier qu'il est la ( pas de confiance ) avec la commande groups

    Note :
    Il peut être nécessaire de redémarrer la session.

    Une fois membre de ce groupe, on lance Scratchbox en tapant :

    Code:
    /scratchbox/login
    Remarque :
    On sort de l’environnent Scratchbox comme d’un shell classique, en tapant exit.

    Il faut ensuite, en tant que root, lancer la commande :

    Code:
    # /scratchbox/sbin/sbox_umount_all
    * En effet, pour s’isoler complètement du système hôte et éviter toute interférence entre les composants « natifs » et les composants « croisés », Scratchbox fonctionne dans un chroot, sur des partitions virtuelles qui lui sont propres. Ce sont ces partitions qu’il faut "démonter" une fois la session terminée. ( comme un ISO quoi )

    Pour redémarrer Scratchbox, on utilisera la commande suivante, en tant que root :

    Code:
    /scratchbox/sbin/sbox_ctl start
    Configuration de la cible Android :
    Une fois Scratchbox installée, il faut configurer l’environnement pour pouvoir compiler à destination du processeur ARM. On utilisera pour cela la commande sb-menu, disponible une fois connecté dans l’environnement Scratchbox. Un menu s’affiche, proposant plusieurs options.

    * Ouvrez bien vos yeux car les étapes qui vont suivre sont très importante , une erreur et c'est bon . ( le nombre de fois que j'ai du tous reprendre ..... rien qu'a y repensé ca me donne des migraines )

    1 - On choisira tout d’abord le menu Setup, puis l’option New pour configurer notre nouvelle cible de compilation. Le nom de la cible importe peu, choisissons par exemple de l’appeler "Android".

    2 - Comme compilateur, on choisira arm-linux-2007q1-21 ( ce qui été mon seul choix possible , a vous de voir )
    3 - On sélectionnera ensuite cputranspdans le menu intitulé devkits.
    4 - Une longue liste s’affiche, dans laquelle il faut sélectionner qemu-arm-0.8.2-sb2.
    5 - Le menu demande alors si l’on désire extraire un rootstrap, à quoi il faut répondre No. En effet, un rootstrap est nécessaire si l’on souhaite construire non pas de simples programmes, mais un système entier, avec notamment un système de fichiers.
    6 - On répondra par contre Yes à la question suivante, pour installer des fichiers pour notre cible.

    TeamWorK's Knowledge :
    Android propose d’autres moyens de personnaliser le système de fichiers. Nous n’avons donc pas besoin de cet outil.
    On répondra enfin Yes à la dernière question, pour utiliser notre nouvelle cible.

    Premier programme en C :
    Pour vérifier que l’installation et la configuration se sont bien passées, nous allons écrire un programme en C très simple, qui se contentera, tradition oblige, d’afficher " Hello Android!" sur la console. À l’aide d’un éditeur de texte, nous allons tout d’abord créer dans le répertoire /tmp le fichier hello.c, contenant le code suivant :

    Code:
    #include <stdio.h>
    int main{
    printf("Hello Android!\n");
    return 0;
    }
    Remarque :
    On nommera le fichier hello.c qu'on sauvegardera dans /tmp

    Question :
    Oui bon , mais comment fait-on pour compiler ce code ?

    Réponse :
    Et bien pour ce faire , on utilisera la commande suivante, à l’intérieur de l’environnement Scratchbox :

    Code:
    gcc -static hello.c -o hello
    Question :
    Ahhh , comment tester cette connerie ?
    Réponse :
    1 - Démarrer l’émulateur depuis une autre console (en dehors de l’environnement Scratchbox) .

    Remarque :
    On peut brancher le téléphone sur une prise USB.

    2 - Transférer le binaire sur Android avec la commande :
    Code:
    adb push hello /data/local/
    3 - On terminera par la commande suivante :
    Code:
    adb shell /data/local/hello
    Le résultat sera donc :
    Code:
    Hello Android!
    TeamWorK's Knowledge :
    L’option static est ici indispensable. En effet, la bibliothèque C d’Android (qui est bionic ), est incompatible avec la bibliothèque C GNU. GCC ne sait donc pas, par défaut, créer du code pouvant l’utiliser. Il est donc nécessaire de compiler une application statique embarquant directement le code de la bibliothèque C dont elle a besoin et qui n’utilisera donc pas la bibliothèque C présente dans Android. Cette approche, qui résout les conflits de bibliothèques, a l’inconvénient de créer des fichiers binaires de grande taille.


    Remarque :
    On peut créer des applications dynamiques utilisant bionic , on utilisant d'autres outils
    Dernière édition par TeamWorK; 27/06/2012 à 15h19
    Not Available

  5. #4
    Inscrit
    juin 2012
    Lieu
    Not Available
    Messages
    537
    Remerciements
    15
    Remercié(e) 188 fois dans 140 messages
    Pouvoir de réputation
    8

    Lightbulb Re: Android When Google said "YES WE DROID"

    Me revoilà donc revenue tous droit des enfers ( éh il fait chaud comme même ) pour continuer nos cours autour de la compilation sous Android .

    Modification du système


    Rappel :
    Nous avons vu comment créer des programmes en C pour les faire fonctionner sur Android. Il est en effet possible de transférer ces programmes sur le téléphone ou l’émulateur et de les utiliser directement sur la plate-forme. Cependant, de telles modifications sont nécessairement limitées :
    - On ne peut installer les applications que dans certains répertoires.
    - On ne peut pas choisir de lancer certains programmes au démarrage, etc.
    Nous allons voir comment modifier l’image système d’Android et détailler le processus de démarrage pour nous affranchir de ces limitations. ( et bein oui s'il n y a pas de porte alors j'en crée une )
    Nous allons, en fait essayer de créer une version personnalisée d’Android. ( j'ai bien dis essayé )

    L’image système d’Android :
    L’image système que nous allons modifier est l’image correspondant au fichier ramdisk.img, associé à la partition racine.

    Question :
    A bon , et pourquoi ça monsieur je vais crée une version personnalisé d'Android ?

    Réponse :
    Pour les raisons suivantes :
    * Cette image est facilement modifiable. Il s’agit en fait d’une archive compressée, qui ne nécessite aucun outil particulier pour être extraite et modifiée.
    * C’est l’image la plus importante. En effet, elle est associée à la partition racine et contient entre autres le fichier de démarrage.(autrement dis c'est LA CASA DEL PRESEDENTE ) .

    Afin de créer une image système personnalisée, nous allons nous baser sur une image existante, que nous modifierons. L’image fournie avec l’émulateur semble être un bon point de départ. Nous allons donc la copier depuis le fichier tools/lib/images/ ramdisk.img du SDK Android vers un répertoire créé pour l’occasion, que nous appellerons mon_image/. (faite simple car ça va se compliquer).

    Cette image, au format initramfs, est en fait une archive de type cpio compressée. Pour l’extraire, nous allons utiliser les commandes suivantes :

    Code:
    gunzip -S.img ramdisk.img //cette commande décompresse l’archive
    cpio -i -F ramdisk // extraction 
    cpio -t -F ramdisk > contenu // cette commande dresse la liste du contenu de l'archive
    Une fois ces commandes exécutées, on obtient un ensemble de fichiers. Le plus important, sur lequel nous reviendrons plus tard, est le fichier init.rc (le fichier de démarrage).
    On obtient également quelques répertoires. Ceux-ci ne sont en fait que des points de montage pour d’autres images, ou pour des systèmes de fichiers spéciaux (tel /proc). Ils sont donc vides et ne sont remplis qu’après le démarrage.

    Première modification :
    Nous y voila , donc pour ajouter un fichier à l’image système, il faut tout d’abord l’ajouter au répertoire contenant l’archive. Créons par exemple un fichier test, dont le contenu importe peu, dans le répertoire mon_image/.(si vous avez changer le nom donc ce n'est pas ce nom de répertoire que vous allez ciblé )

    Code:
    cd mon_image/
    echo ceci est un test > test
    Il faut ensuite ajouter le nom du fichier à la liste du contenu de l’archive, avec la commande :

    Code:
    echo test >> contenu
    On utilise ensuite cpio pour créer une archive selon la liste fournie, puis on la compresse :

    Code:
    cat contenu | cpio -o -H newc -O mon_image
    gzip -S.img mon_image
    On obtient une nouvelle image système : mon_image.img. Pour la tester, le plus simple est d’avoir recours à l’émulateur, qui dispose d’une option prévue à cet effet :

    Code:
    emulator -ramdisk mon_image/mon_image.img
    Voila il est possible d'aller très loin avec les personnalisation , moi j'utilise la BusyBox

    A Venir : Un exemple de personnalisations complet
    Dernière édition par TeamWorK; 12/07/2012 à 16h32
    Not Available

  6. #5
    Inscrit
    juin 2012
    Lieu
    Not Available
    Messages
    537
    Remerciements
    15
    Remercié(e) 188 fois dans 140 messages
    Pouvoir de réputation
    8

    Arrow Re: Android When Google said "YES WE DROID"

    Un exemple complet de personnalisation :


    Remarque :
    On s'assoie , on met les deux sur le keyboard , on fixe le clavier avec le fameux regard de l'aigle et on va pouvoir commencer .
    J'ai mis du temps car j'ai préféré m'assurer de deux trois , cinq , dix chose été bien réglés .
    Ahh oui j'utilise BusyBox pour ce cour donc prenez vos dispositions.

    Nous allons voir les étapes qui permettent de créer une image système complète. Cela nous permettra d’aborder tour à tour et de façon concrète les différentes manières de modifier et d’améliorer l’image système.

    Installation de Busybox :
    Comme nous l’avons vu dans le chapitre précédent, Busybox est un programme particulier, qui se comporte de façon différente suivant le nom sous lequel il est lancé. En pratique, cela signifie qu’il faut créer de nombreux liens symboliques pointant vers Busybox,dont les noms sont ceux des applets. Nous allons donc créer dans notre image système un nouveau répertoire /bin, contenant Busybox et les liens symboliques associés aux applets.
    1. Tout d’abord, il s’agit de créer le répertoire bin dans notre dossier mon_image. Il faut ensuite copier le binaire busybox dans ce répertoire bin.
    2. La liste de applets varie selon les options choisies lors de la compilation. Pour la récupérer, il va donc falloir la recréer à partir des sources. En effet, lors du choix des applets, effectué avant la compilation, un fichier d’en-tête contenant entre autres la liste des applets est généré automatiquement. Il s’agit du fichier include/applet_tables.h.
    3. On peut créer l’ensemble des liens symboliques en se plaçant dans le nouveau répertoire mon_image/bin et en lançant la commande suivante après avoir remplacé source par le nom du répertoire contenant les sources de Busybox :

    Code:
    awk -F\" ’/applet_names/,/;/{if($2) system("ln -s busybox " $2)}’
          source/include/applet_tables.h
    Une fois les liens créés, on ajoute les fichiers de ce nouveau répertoire bin au contenu de l’archive :
    Code:
    find bin >> contenu
    Important :
    Le but de ce cour n’est certes pas l’étude du langage AWK(et bein oui je vais pas tous déballé du premier coup ), mais la commande ci-dessus mérite une explication. Le fichier applet_tables.h contient la liste des noms des applets formatée comme un groupe de chaînes de caractères en langage C. Voici un aperçu du fichier :
    Code:
    const char applet_names[] ALIGN1 = ""
    "[" "\0"
    "[[" "\0"
    "addgroup" "\0"
    "adduser" "\0"
    "adjtimex" "\0"
    […]
    "zcip" "\0"
    ;
    On notera que les différentes chaînes de caractères sont séparées par des \0, ou caractères nuls, qui délimitent les chaînes en langage C. Décomposons maintenant la commande AWK :
    - /applet_names/,/;/ indique que le traitement n’aura lieu qu’entre la chaîne ‘applet_names’ et le ‘;’ final. Cela permet d’isoler la partie du fichier qui nous intéresse.
    - L’option -F\" indique à AWK de séparer les champs à l’aide du caractère ". Ce caractère est échappé (précédé d’un \) pour éviter que le shell ne l’interprète. Le champ 1 est donc tout ce qui, sur une ligne, précède le premier guillemet, le champ 2, celui qui nous intéresse, se trouve après le premier guillemet et avant le second, etc.
    - Le champ 2 contient normalement le nom de l’applet. On s’assure avec if($2) que ce champ
    n’est pas vide. On invoque ensuite le shell avec la commande ln -s busybox suivie du nom de
    l’applet. Par exemple pour la ligne 4 on aura : ln -s busybox addgroup.
    On a donc bien créé des liens vers Busybox portant le nom des applets.

    Personnaliser la procédure de login :
    Une fois Busybox correctement installé, la partie n’est pas gagnée pour autant. En effet, le shell fourni par Android par défaut n’est pas celui de Busybox (Ash), et le répertoire /bin
    nouvellement crée ne fait pas partie du PATH, et n’est donc pas consulté... Il faut donc à chaque connexion modifier la variable d’environnement $PATH et changer de shell en invoquant manuellement /bin/ash.
    Sur un " vrai " système Unix, ce travail est habituellement effectué par la procédure de login, une fois que celle-ci a pu authentifier l’utilisateur (le plus souvent grâce à son mot de passe). Nous allons mettre en place une telle procédure.
    Le problème qui se pose sous Android est que les fichiers /etc/passwd et /etc/group sont absents. Ces fichiers stockent en temps normal les informations sur les utilisateurs et les groupes et sont donc requis par le programme login. Il va donc nous falloir les créer.
    Or, comme nous l’avons constaté au début de ce chapitre, le répertoire /etc ne fait pas partie de l’image système que nous sommes en train de modifier. En fait, /etc n’est qu’un lien vers /system/etc, dont le contenu se trouve sur l’image système system.img. Plutôt que de modifier cette image, nous allons nous aussi avoir recours à des liens symboliques une pratique courante au sein du système de fichiers d’Android.
    Choisissons par exemple de placer ces fichiers dans le répertoire /usr/etc. Le choix du répertoire importe peu du moment que les liens sont crées correctement. Nous allons donc créer le répertoire usr/etc dans le dossier mon_image/ :
    Code:
    mkdir -p usr/etc
    Plaçons-nous ensuite dans ce répertoire pour créer nos deux fichiers :

    Code:
    cd usr/etc
    echo root::0:0:root:/home:/bin/ash > passwd
    On se contente d’un seul utilisateur, l’administrateur (root), dont le répertoire personnel sera /home et le shell /bin/ash (shell fourni par Busybox). Pour des raisons de simplicité, on ne définit pas de mot de passe. On crée ensuite le groupe associé :

    Code:
    echo root::0: > group
    Bien évidemment, on peut ajouter de la sorte plusieurs utilisateurs et définir si on le désire des mots de passe pour chacun d’eux.
    Une fois ces opérations terminées, n’oublions pas d’ajouter les fichiers au contenu de l’archive :

    Code:
    find usr >> contenu
    Modifier le fichier de démarrage :
    Le répertoire /usr/etc étant en place, il nous faut maintenant ajouter des liens dans /etc pointant vers lui. Le montage des différentes images systèmes et la création éventuelle de liens entre elles se faisant lors du démarrage, il va donc nous falloir modifier le fichier qui contrôle l’étape du boot.
    Ce fichier, init.rc, fait partie de notre image système. Il est composé d’une série de commandes qui sont exécutées dans l’ordre lors du démarrage. Nous allons l’ouvrir avec un éditeur pour le modifier (les modifications sont mises en exergue) :

    Code:
    # Backward compatibility
    symlink /system/etc /etc
    symlink /data/local /home
    symlink /cache /tmp
    On ajoute sous forme de lien les répertoires /home et /tmp. Le premier nous servira de répertoire personnel. L’utilisation de /data/local est particulièrement judicieuse puisque ce répertoire est monté en écriture et que son contenu est conservé après un redémarrage.
    Le répertoire /tmp pointe en fait vers /cache qui a déjà vocation de répertoire " temporaire ". Beaucoup d’applications Unix étant habituées à la présence du dossier /tmp, il est recommandé de le créer.
    On supprime ensuite les deux lignes suivantes :

    Code:
    mount rootfs rootfs / ro remount
    mount yaffs2 [email protected] /system ro remount
    Ces lignes avaient pour rôle de verrouiller en lecture seule :
    - le répertoire racine (correspondant à notre image système), ainsi que
    - le répertoire /system (correspondant à l’image system.img).
    Garder l’accès en écriture nous permettra notamment de créer des liens symboliques.

    Important :
    Limite de l’accès en écriture : des modifications qui ne sont que temporaires
    L’accès en écriture permet des modifications temporaires sur ces deux points de montage. En effet, les images système ne sont pas modifiables depuis Android, et les modifications faites ne sont donc pas enregistrées : elles seront perdues lors d’un redémarrage.
    La seule partition qui échappe à cette règle est la partition /data (d’où notre choix pour /home).

    Enfin, on crée les liens vers passwd et group en ajoutant ces deux lignes :

    Code:
    chown root root /cache/lost+found
    chmod 0770 /cache/lost+found
    symlink /usr/etc/passwd /system/etc/passwd
    symlink /usr/etc/group /system/etc/group
    A Venir : La suite de la personnalisation
    Dernière édition par TeamWorK; 14/07/2012 à 20h11
    Not Available

Sujets similaires

  1. Google Totalise 25 Milliards de Téléchargements sur sa plateforme "Google Play"
    Par Hicham dans le forum Actualité informatique et high tech
    Réponses: 0
    Dernier message: 26/09/2012, 18h31
  2. L'iPhone 5 enfin Dévoilé : "Processeur Apple A6" , "APN 8MP Full HD 1080p" , "iOS 6"
    Par Hicham dans le forum Actualité informatique et high tech
    Réponses: 7
    Dernier message: 14/09/2012, 17h52
  3. Android ..... When "Ubuntu Inside"
    Par TeamWorK dans le forum Actualité informatique et high tech
    Réponses: 0
    Dernier message: 20/06/2012, 20h18
  4. Google dénonce une "campagne hostile" de Microsoft, Oracle et Apple
    Par Milax dans le forum Actualité informatique et high tech
    Réponses: 1
    Dernier message: 04/08/2011, 11h18
  5. Google+ réactive les invitations pour "doubler sa base d'utilisateurs"
    Par Essedik dans le forum Actualité informatique et high tech
    Réponses: 0
    Dernier message: 07/07/2011, 14h17

Règles des messages

  • Vous ne pouvez pas créer de sujets
  • Vous ne pouvez pas répondre aux sujets
  • Vous ne pouvez pas importer de fichiers joints
  • Vous ne pouvez pas modifier vos messages
  •  
  • Les BB codes sont Activés
  • Les Smileys sont Activés
  • Le BB code [IMG] est Activé
  • Le code [VIDEO] est Activé
  • Le code HTML est Désactivé



Liens annexes