Android pour l'industrie - Pierre Ficheux () Octobre 2013

Android pour l’industrie

Pierre Ficheux (pierre.ficheux@openwide.fr)

Octobre 2013

                      Android pour l’industrie   1

Ecosystème

●   Environ 1,5 M d'activations par jour, plus d’un milliard
    de téléphones depuis l’été 2013 !
●   1M d'applications sur Google Play (Android market)
●   75 % du marché des smartphones (17% pour iOS)
●   Répartition des versions :

                          Android pour l’industrie             2

Android et l'industrie ?
●   Android est conçu pour la téléphonie + tablettes
●   Les projets industriels abandonnent les RTOS
    propriétaires pour Linux (embarqué)
●   Le développement sous Linux (embarqué) est
    complexe
         –   Souvent C/C++ (Qt)
         –   Outils hétérogènes
●   Android nécessite (souvent) une adaptation pour
    l’utilisation industrielle
●   Typologie des projets
         –   Avec ou sans temps réel « dur »
         –   Avec ou sans interfaces graphique (headless)
●   Android n’est pas une solution universelle !
                           Android pour l’industrie                          3

Android, open source project ?
●   Le monde de la téléphonie est peu enclin à utiliser du
    logiciel libre
●   Les sources d'Android sont disponibles via AOSP →
    adaptation possible ou BSP constructeur :)
●   En pratique, Android ne suit pas les règles de
    fonctionnement des projets libres
         –   Développements réalisés « behind de doors »
         –   Nombreux projets « non officiels », comme Android-
              x86
         –   Nombreux développements spécifiques (et
              propriétaires) réalisés par/pour les constructeurs
         –   Si possible, Google évite les composants sous GPL
               → ré-écriture + licence Apache 2
●   Départ à l’été 2013 du leader du projet (JBQ) !!

                            Android pour l’industrie               4

Licences

●   Android est constitué de nombreux composants
        –   Noyau Linux (GPL)
        –   Composants Google (Apache 2)
        –   Composants externes (user space) souvent GPL
        –   Propriétaires (pilotes binaires)
●   Les applications de Google Play (Android Market) sont
    pour la plupart propriétaires (idem AppStore) → non
    disponibles dans les sources d’Android

                            Android pour l’industrie          5

La licence GPL en bref
●   La GPL a pour origine le projet GNU de la Free
    Software Foundation (Richard M. Stallman)
●   GPL = General Public License
●   Intègre la notion de « copyleft » (vs « copyright »)
●   La GPL v2 (1991) est la plus répandue (exemple :
    noyau Linux)
●   Principes :
         1.   La licence s'applique uniquement en cas de
                redistribution
         2.   Un code source utilisant du code GPL est du travail
               dérivé et doit être publié (i.e. celui qui reçoit la
               version binaire peut obtenir le code source)
         3.   Pas de lien (ld) possible entre du code GPL et du
                code « propriétaire » !

                             Android pour l’industrie                    6

Licence Apache 2

●   Fournie par ASF en 2004
●   Proche des licences BSD et MIT
●   Principale différence avec la GPL/LGPL : pas de
    « copyleft » (dérivation) → pas de publication du code
●   Pour plus d'information voir :
        –   http://source.android.com/source/licenses.html
        –   http://www.apache.org/licenses/LICENSE-2.0.html

                           Android pour l’industrie                  7

Architecture générale (Google)

Android pour l’industrie          8

Le noyau Linux (rouge)
●   Assure l'interface matérielle
●   Différent du noyau standard nommé « mainline » et
    disponible sur http://www.kernel.org
        –   Nouveau système d'IPC (Inter Process Comm.)
        –   Gestion d'énergie améliorée
        –   Système trace (logs)
●   Initialement (et toujours) un « fork » du noyau
●   Pilotes retirées du noyau officiel en 2009
●   De retour sur drivers/staging/android depuis le
    3.3
●   Convergence (partielle) avec le mainline en cours
●   Google est contributeur par nécessité, choix
    pragmatique
●   Noyau binaire fourni par défaut dans AOSP
                          Android pour l’industrie                   9

Bibliothèques + HAL (vert)
●   Bibliothèques spécifiquesGoogle ou externes
●   Spécifiques :
        –   Bionic, libC « allégée » sous licence BSD,
              partiellement POSIX → difficulté de portage de
              code « legacy »
        –   Surface Manager, Audio Manager, ...
●   Externes (sources fournies par Google dans AOSP) :
        –   Webkit
        –   OpenSSL
        –   …
●   Hardware abstraction layer → accès aux pilotes noyau
        –   Graphique, audio, Wi-Fi, ...
        –   Pas d'accès direct au noyau (différent de
              GNU/Linux)
                            Android pour l’industrie               10

HAL

●   Pour chaque « service » on a
        –   Un System service (Java)
        –   Une définition dans la HAL (interface matérielle) +
             pilote noyau
●   Le constructeur doit fournir une bibliothèque (.so)
    externe à AOSP (sous licence propriétaire) → à ajouter
    au répertoire /device
●   Le pilote noyau – également fourni par le constructeur -
    reste sous GPL
●   Voir un exemple sur
    http://www.opersys.com/blog/extending-android-hal

                            Android pour l’industrie              11

Architecture HAL
                             Répertoires AOSP

                                                  /frameworks/base/core/

                                                  /frameworks/base/services/java/
AOSP-provided
    ASL
                                                  /frameworks/base/services/jni/

                                                     /hardware/libhardware/

                                                     /device/[MANUF.]/[DEVICE]
                                                     /sdk/emulator/
Manuf.-provided
Manuf. license
                                                    Noyau ou module
Manuf.-provided
 GPL-license

  Schéma K. Yaghmour
                       Android pour l’industrie                               12

Android runtime (jaune)

●   Dalvik, LA JVM de Google
         –   Grosse valeur ajoutée au niveau performances
         –   Syntaxe Java
         –   Optimisée pour l'embarqué
         –   Non compatible avec JDK Oracle, utilise des
              fichier .dex
         –   .dex produit à partir du .class par dex →
               encombrement divisé par 2
●   Les « core libraries » venant du projet Apache Harmony
    remplacent les « JDK libs » pour le runtime
●   Contient également des scripts et binaires nécessaires au
    démarrage (ramdisk initial) dont Zygote qui démarre Dalvik

                            Android pour l’industrie                   13

Android framework (bleu)

●   Correspond à l'API fournie aux développeurs pour
    écrire les applications
●   Majoritairement écrit en Java
●   Utilisation de JNI pour l'accès aux couches basses
    (C/C++) depuis une application
●   La communication utilise Binder, une couche IPC
    écrite par Google en remplacement des IPC
    UNIX/POSIX

                        Android pour l’industrie                14

Architecture générale (K. Yaghmour)

Schéma K. Yaghmour
                        Android pour l’industrie      15

AOSP, introduction
●   AOSP = Android Open Source Project
●   Accessible sur http://source.android.com
●   Sources pour les plate formes de référence
         –   Émulateur goldfish
         –   Nexus 4, 7, 10
         –   Pandaboard (carte ARM)
         –   Certains Galaxy Nexus
    → http://source.android.com/source/building-devices.html
●   Bonne documentation
●   AOSP utilise aussi des composants propriétaires
    (exemple : pilotes graphiques)
             https://developers.google.com/android/nexus/drivers
●   Les sources représentent plusieurs centaines de
    dépôts Git (1 par projet) et plus de 16 Go !
                              Android pour l’industrie                   16

AOSP, pré-requis

●   Nombreux pré-requis pour la compilation AOSP (rien à
    voir avec Linux embarqué)
●   Machine (puissante) 64 bits sous Linux ou Mac OS X
    (pas de Windows !)
●   4 Go de RAM, 100 Go de disque
●   SMP conseillé
●   Distribution Ubuntu 10.04 LTS ou éventuellement 12.04
●   Quelques paquets à installer
●   Utilisation de VM déconseillée (mais fonctionne)
●   Java 6 → JDK 6.1
●   Largement basé sur GNU Make
●   La procédure d'initialisation est décrite sur :
          http://source.android.com/source/initializing.html
                          Android pour l’industrie                 17

AOSP « in a nutshell »

●   Google fournit l'outil repo (un script Python) afin de
    gérer les nombreux dépôts Git
●   Cet outil utilise un fichier manifest pour indexer les
    dépôts
    $ mkdir work && cd work
    $ repo init -u https://android.googlesource.com/platform/manifest
    [-b ]            sélection de la branche, exemple android-4.3_r2
    $ repo sync [-j N]      synchronisation avec le dépôt, N jobs
●   Sélection de la cible, compilation et test
    $ source build/envsetup.sh             chargement des variables
    $ lunch aosp_arm-eng          cible émulateur (goldfish) + mise au point (eng)
    $ make -j N
    $ emulator [-show-kernel -shell] &

                                Android pour l’industrie                             18

Les cibles AOSP
●   Différentes cibles dans le menu lunch (4.3)
    Lunch menu... pick a combo:
         1. aosp_arm-eng            Goldfish
         2. aosp_x86-eng            x86
         3. aosp_mips-eng
         4. vbox_x86-eng
         5. aosp_deb-userdebug
         6. aosp_flo-userdebug
         7. ...
        12. full_mako-userdebug                Nexus 4
         13. full_maguro-userdebug
         14. full_manta-userdebug
         15. full_arndale-userdebug
         16. full_toroplus-userdebug
         17. full_toro-userdebug
         18. full_panda-userdebug           Pandaboard
●   Différents type de build
         – user (production)

           –      userdebug (production + accès root + debug)
           –      eng (développement)
                                        Android pour l’industrie                19

Écran de l'émulateur

●   Déverrouiller l'écran en « tirant » le cadenas vers
    l'extérieur

                          Android pour l’industrie                     20

Remarques sur AOSP

●   Les sources occupent environ 16 Go (pour JB) car
    Google fournit l'intégralité, y compris les composants
    externes
●   Grosse différence avec GNU/Linux (Buildroot, OE, …)
    qui obtiennent les paquets à partir des dépôts et
    appliquent des « patch »
●   Le système de construction est rudimentaire, rien à voir
    avec GNU/Linux !
●   Après compilation, le répertoire occupe 40 Go
●   Les binaires sont produits sur le répertoire out et
    indexés sur le nom de la cible
          $ ls -1 out/target/product
          generic         cible émulateur (goldfish)

          panda
                         Android pour l’industrie                   21

Noyau Linux/Android
●   Le noyau Linux n'est pas conçu au départ pour la
    téléphonie
        –   Gestion d'énergie :-(
        –   Mise en veille
        –   IPC System V → « old style »
        –   Gestion de mémoire / processus (context switch)
●   Modifications par Google
        –   Wakelocks
        –   Binder
        –   Klogger
        –   Ashmem
        –   Alarm timers
        –   Low memory killer
                             Android pour l’industrie                    22

Noyau Linux/Android, suite.

●   Les pilotes Android sont dans drivers/staging → pas
    intégrés au mainline
●   Retirés en décembre 2009, ré-intégrés dans la version
    3.3
●   Effort de convergence sur les versions récentes
●   Bonne compatibilité de l’API noyau Linux (modules)
●   Rappel : un module noyau ne suffit pas à piloter un
    périphérique sous Android (HAL)

                        Android pour l’industrie             23

SDK
●   La plupart des développements Android se font en
    Java
         –   Langage « simple », très répandu
         –   Très bonne performances de Dalvik
●   Google fournit un SDK basé sur Eclipse → ADT
    (Android Developer Tools)
         –   Simple à utiliser pour les développeurs Java/Win$
               (mais pas forcément pour les autres)
         –   Approche « Visual Machin » → New Project, Next,
               Next, … , Finish
●   Test de l'application directement sur émulateur
●   Création d'un fichier .apk installable sur n'importe
    quelle cible Android

                            Android pour l’industrie             24

Diagramme de création

Android pour l’industrie                 25

NDK
●   Les développements C/C++ sont fait avec le NDK (pour
    Native Development Kit)
        –   Portage de code existant, proche de POSIX
        –   Possibilité de développer uniquement avec NDK
              (mais pas conseillé par Google)
        –   Plus souvent, interfaçage avec SDK par JNI (Java
              Native Interface)
●   Android utilise des fichiers Makefile dédiés et assez
    basiques → Android.mk
●   Pas de support officiel Autotools/CMake
●   Le NDK contient principalement les chaînes croisées
    dans toolchains et les bibliothèques (Bionic, …) dans
    platforms

                          Android pour l’industrie             26

NDK et POSIX
●   La plupart des RTOS ont une API POSIX (VxWorks,
    RTEMS, QNX, ...)
●   Android n'est pas totalement un système POSIX car la
    libC (Bionic) est simplifiée par rapport à GNU-libC
●   Souvent nécessaire d'importer du code (POSIX)
    existant (propriétaire ou libre) dans Android
        –   Porter le code en Java ?
        –   Utiliser NDK (plus simple en général)
●   Le cas le plus fréquent est l'utilisation d'une
    bibliothèque C/C++ depuis une application Java (ex :
    accès pilote noyau JNI)
●   Exemples fournis dans le NDK

                           Android pour l’industrie             27

Bionic
●   La libC Bionic est volontairement beaucoup plus légère
    que la Glibc
       The core idea behind Bionic's design is: KEEP IT
                         REALLY SIMPLE.
●   Pas de support IPC System V (Android utilise Binder) !
●   Quelques limites dans le support PThread
●   Pas de support des exceptions C++
●   Pas de compatibilité binaire avec la Glibc
●   Support ARM et x86 uniquement
●   Nécessite l'utilisation du compilateur Android (NDK)
●   Voir android-ndk-rX/docs/system/libc

                        Android pour l’industrie             28

Utilisation d’une chaîne externe ?

●   Le NDK a des limitations au niveau POSIX
●   Le noyau Android est un noyau Linux donc les appels
    systèmes standards sont disponibles
●   Une solution est d'utiliser une chaîne croisée
    « standard » (exemples : CodeSourcery, ELDK, …) →
    installer les bibliothèques sur la cible (en plus de
    Bionic)
●   Problème : intégration dans SDK

                       Android pour l’industrie        29

Android et le temps réel

●   Android n’est pas conçu au départ pour les applications
    TR
●   L’API POSIX est cependant disponible dans le noyau
    Linux
●   L’application de « patch » TR n’est pas triviale car ces
    patchs sont prévus pour un noyau « mainline »
●   Tests réalisés sur des tâches périodiques avec
    PREEMPT-RT et Xenomai sous Android-x86 →
    résultats identiques à ceux de GNU/Linux
●   Test directement en mode « console »
●   Voir la démonstration :)

                         Android pour l’industrie                   30

PREEMPT-RT

●   Branche expérimentale pour la version 2.6 et 3.x, voir
    https://rt.wiki.kernel.org
●   Initié par Ingo Molnar, contributeur majeur du noyau
●   Aucun lien avec « preempt-kernel » !
●   Surtout utilisé sur x86 et des processeurs performants
    (nécessite TSC = Time Stamp Counter)
●   Fonctionne également sur ARM (9 ou plus), Nios II,
    Microblaze, ...
●   Nécessite un noyau « mainline » (ou proche) mais ne
    sera probablement jamais intégré à la branche officielle
●   Mise en place très simple (application d'un patch)
●   Mêmes API de programmation que Linux standard

                         Android pour l’industrie              31

PREEMPT-RT, suite

●   Threaded interrupt model → utilisation d'un thread
    noyau (donc interruptible) pour le traitement de chaque
    interruption
    4     2 root   SW<   0     0%      0% [sirq-high/0]
    5     2 root   SW<   0     0%      0% [sirq-timer/0]
    ...
    6     2 root   SW<   0     0%      0% [sirq-net-tx/0]

●   Prévention des inversions de priorité (par héritage)
●   Timers noyau haute précision (API hrtimer)
●   Réécriture complète des mécanismes de
    synchronisation (spinlock → mutex)
●   Le résultat est un noyau (presque) « préemptif », mais
    reste un noyau Linux
●   Sections critiques avec des tâches non TR

                             Android pour l’industrie                  32

Linux avec co-noyau

●   Utilisation d’un noyau temps dans l’espace mémoire du
    noyau Linux
●   Séparation entre le composant temps-réel et Linux
     –   Ordonnanceur temps-réel spécifique
     –   Pas de dépendance sur les sections critiques Linux
●   Virtualisation de la gestion d'interruptions Linux
     –   Routage prioritaire des IRQs vers le co-noyau
●   Linux comme tâche idle du co-noyau
●   Se rapproche de la technique de « para-virtualisation »
    des hyperviseurs (adaptation de l'OS)
●   Extensions RTLinux, RTAI, Xenomai

                            Android pour l’industrie                    33

Xenomai, architecture

     ●   Xenomai utilise un micro-noyau (ADEOS) pour partager
         le matériel avec le noyau Linux

pilote TR

API TR

noyau TR
                                                                  noyau Linux
                micro-noyau

                              Android pour l’industrie                          34

Domaines Xenomai

Code applicatif VxWorks                    Code applicatif POSIX

          Xenomai                                     Xenomai
glibc                                    glibc
          libvxworks                                  libpthread

                       Appels système

        Pile réseau                               Xenomai RTOS

        VFS/FS               ...                              Noyau

                          Adeos I-Pipe

                           Hardware

                       Android pour l’industrie                       35

Android industriel,
                                              avantages/inconvénients
●   Avantages
        –   Programmation Java (simple et répandue)
        –   IHM évoluée
        –   Communauté importante
        –   Fait rêver les managers et les comptables (tablette =
              grand public = bon marché)
●   Inconvénients
        –   Incompatibilité POSIX
        –   Système de « build » AOSP rudimentaire par rapport
              à GNU/Linux
        –   Pas réellement un projet libre ni communautaire
        –   Noyau Linux non standard (même si la situation
             évolue)
        –   Interfaces matérielles spéciales mal supportées !!
                           Android pour l’industrie                  36

Conclusions

●   Utiliser Android quand :
         –   Le projet nécessite une IHM
         –   Le projet ne nécessite pas de TR dur (pour l’instant)
         –   L’utilisation de Java est un avantage
●   Attention à la dépendance / Google → quelle part
    d’AOSP disponible et jusqu’à quand ?
●   Android ne peut remplacer GNU/Linux embarqué
         –   Développement communautaire
         –   Support matériel
         –   Système de construction bien plus avancé (Yocto)

                            Android pour l’industrie                 37

Questions ?

Android pour l’industrie            38