rapport projet asr - faure et raoust

DÉVELOPPEMENT D’UNE APPLICATION DE COMMUNICATION BLUETOOTH SUR ANDROID

Projet de fin d’étudeVAP «Architecte de Services en Réseau»

Guillaume Faure et Maxime RaoustJanvier 2010

Guillaume Faure & Maxime Raoust - Telecom SudParis - Janvier 2010

Acteurs du projet

Étudiants

Guillaume Faure

Elève ingénieur en troisième année à Telecom [email protected]

Maxime Raoust

Elève ingénieur en troisième année à Telecom [email protected]

Encadrants

Laurent Bernard

Enseignant-chercheur à Telecom SudParis, département [email protected]

Sébastien Leriche

Enseignant-chercheur à Telecom SudParis, département [email protected]

Avec l’aide de

Toko Luyeye

Ingénieur de recherche à Telecom [email protected]


tAble des mAtières

5 1Présentationduprojet

5 1.1 Le sujet

6 1.2 Nos objectifs

7 2Travailréalisé

7 2.1 Étude préliminaire7 2.1.1 Obtention du SDK7 2.1.2 Environnement de travail8 2.1.3 Environnement de test9 2.1.4 Pile Bluetooth9 2.1.5 Ouverture10 2.1.6 Tableau récapitulatif11 2.1.6 Conclusion

12 2.2 Prise en main de l’environnement12 2.2.1 Présentation du SDK15 2.2.2 L’échec du Samsung Galaxy16 2.2.3 La victoire du Hero17 2.2.4 Application test

18 2.3 Le problème du profil PAN18 2.3.1 Architecture d’Android20 2.3.2 Profil PAN sous Android20 2.3.3 Nouvelle orientation de notre problématique

21 2.4 Première solution21 2.4.1 Théorie22 2.4.2 Pratique23 2.4.3 Bilan de la première solution


24 2.5 Deuxième solution24 2.5.1 Présentation du NDK25 2.5.2 Théorie25 2.5.3 Pratique27 2.5.4 Bilan de la deuxième solution

28 3Bilan

29 4Suiteduprojet

29 4.1 Tests de VoIP

30 4.2 Automatisation de l’application

30 4.3 Android Dev Phone

31 Conclusion

32 Bibliographieetréférences32 1 Documents relatifs au projet32 2 Liens Internet

34 Chargedetravail


1.1 Le sujet

Ce projet de déve-loppement sur téléphone mo-bile, encadré par

Laurent Bernard du dépar-tement RST de Telecom Sud-Paris et Sébastien Leriche du département Informatique, s’insère dans un projet de recherche plus large mené à Telecom SudParis à la demande de la RATP. En effet, dans le cadre de la modernisation des services de télécommunication entre agents et usagers, la RATP souhaite mettre à profit les évo-lutions observées dans les technologies de l’in-formation et de la communication en faveur des personnes à mobilité réduite.

Elle a dans ce but fait appel à Telecom Su-dParis pour étudier la faisabilité d’un service d’interphonie mobile visant à mettre en rela-tion les usagers concernés avec un agent RATP. L’idée est de permettre à l’usager de connecter simplement son téléphone mobile à un point d’accès et d’accéder au service qui lui permettra d’établir une communication bidirectionnelle avec un agent sans utiliser le réseau d’un quel-conque opérateur GSM.

Les deux aspects importants pour ce service sont d’une part l’utilisation de Bluetooth comme

1 présentAtion du projet

technologie de réseau d’accès et d’autre part une disponibilité du service pour l’usager sur de multiples plate-formes pour smartphones (ou ordiphones, la traduction officielle depuis peu).

Le schéma ci-contre présente l’architecture réseau simplifiée qui supportera le service en question.

Les premiers travaux menés ont démontré la faisabilité d’un tel service grâce à la mise en œuvre d’une plate-forme d’expérimentation et de tests de communications entre usager et agent. Ces résultats concluants ont été réalisés avec un smartphone Sony-Ericsson embarquant le système d’exploitation Symbian. Mais d’autres tests, notamment avec des smartphones em-barquant Windows Mobile, ont mis en évidence des verrous technologiques qui peuvent éven-tuellement être levés moyennant des dévelop-pements spécifiques.


La faisabilité d’un tel service de com-munication a déjà été démontrée sur quelques supports. Cependant, elle de-vra à terme avoir été démontrée sur la

plupart des environnements pour smartphone existant aujourd’hui. Notre équipe de projet ASR a donc eu pour tâche d’étudier cette fai-sabilité sur un support n’ayant pas encore fait l’objet d’études, parmi ceux-ci : Mac OSX Mobile (ou iPhone OS, embarqué par exemple sur les Iphone 3GS) et Android (embarqué par exemple sur le Samsung Galaxy). Nos objectifs de projet à proprement parler furent les suivants :

»» Prendre connaissance de tous les tra-vaux effectués dans le cadre du projet global

»» Explorer les possibilités offertes par les environnements iPhone et Android

»» Fournir une étude comparative de ces deux supports

»» Choisir celui qui semble le plus adapté à la mise en place du service

»» Développer un prototype d’application client permettant d’accéder au service sur la plate-forme choisie

La fenêtre temporelle de notre projet ASR étant assez courte (environ 10 semaines) et ce sujet nécessitant un investissement impor-tant, un calendrier a dû être rapidement mis en place. Des réunions d’avancement avec nos en-cadrants étaient organisées toutes les deux se-maines. D’autre part, nous devions également donner régulièrement dans le cadre du projet des retours à l’équipe de projet RATP, par l’inter-médiaire de réunions d’échange ou de rapports écrits.

Nous avons donc mis en place le planning prévisionnel ci-contre.

1.2 Nos objectifs


2 trAvAil réAlisé

Après avoir pris connaissance du sujet, une réunion de démarrage avec l’ensemble de l’équipe de projet de Telecom SudParis a eu lieu, afin que nous puissions prendre connais-sance de tous les avancements effectués jusqu’à présent sur le projet global. Les diffé-rents rapports nous ont été transmis, et leur lecture nous a permis d’avoir une vision

plus précise du contexte et des moyens dont nous disposions pour mener à bien notre projet. Nous présentons dans cette partie les différentes étapes de notre travail.

2.1 Étude préliminaireNotre premier travail a été l’étude compara-

tive des environnements iPhone OS et Android, afin de choisir la plate-forme sur laquelle nous allions nous concentrer. Voici les éléments que nous avons étudiés et retenus pour notre com-paraison.

2.1.1 Obtention du SDK

Développer sur un iPhone ou sur Android nécessite l’installation d’un «kit de développe-ment logiciel» (ou SDK), fourni par les concep-teurs du système. Dans le cas d’Android, cet outil est totalement libre d’accès et gratuit, dis-ponible en téléchargement sur le portail des dé-veloppeurs d’Android. Le SDK pour iPhone OS est également gratuit et disponible sur le portail des développeurs d’Apple, mais nécessite une inscription gratuite à la communauté des déve-loppeurs Apple.

2.1.2 Environnement de travail

C’est principalement à ce niveau que ces deux environnements se sont avérés différents.

Environnement de développementL’environnement de développement pour

l’iPhone est Xcode. C’est l’environnement de développement utilisé pour toutes les techno-logies Apple, c’est pourquoi c’est outil n’est dis-ponible que pour Mac OS. Le développement d’applications Android est possible aussi bien sur Eclipse, que sur Apache Ant ou JDK. C’est pourquoi le développement d’applications An-droid est possible aussi bien sur Windows que sur Linux ou Mac.

Langage utiliséLe développement d’applications pour An-

droid se fait entièrement en Java. Java est un puissant langage orienté objet, utilisé très lar-gement dans le monde du développement. Le développement d’applications pour iPhone OS


se fait avec Objective C, une extension du lan-gage C, orienté objet et réflexif.

Accès à la documentationDans les deux cas, on dispose d’une part

d’une riche documentation sur les sites officiels de développement des deux plate-formes, et d’autre part d’une communauté bien vivante de développeurs. Il existe donc de nombreux sites, blogs et forums, professionnels ou amateurs, traitant du développement sur ces deux plate-formes. La documentation officielle d’Android semble cependant plus claire que celle propo-sée pour l’iPhone OS.

Publication d’applicationsLes deux plate-formes permettent de

rendre disponibles les applications aux utilisa-teurs finaux via une plate-forme de télécharge-ment intégrée aux terminaux.

Android propose la plate-forme Android Market pour la publication des applications. Notons qu’a l’heure où nous écrivons ces lignes, il y a environ 20 000 applications sur l’Android Market.

http://www.android.com/market/

Pour publier une application sur l’Android Market, il faut s’inscrire sur le site en question et payer des frais d’inscription de 25$.

http://market.android.com/publish/signup

Apple propose la fameuse plate-forme App Store, pionnière, avec à ce jour environ 200 000 applications.

http://www.apple.com/iphone/apps-for-iphone/

Il est nécessaire pour publier des applica-tions sur iPhone de souscrire à un des deux pro-grammes pour développeurs proposés:

http://developer.apple.com/iphone/program/apply.html

»» Le programme standard, à 99$, permet aux développeurs de publier des appli-cations gratuites ou payantes sur l’App Store

»» Le programme entreprise, à 299$, per-met aux sociétés de plus de 500 em-ployés de créer des applications pro-priétaires et de les distribuer de manière privée au sein de leur entreprise

2.1.3 Environnement de test

Il est également très important de pouvoir effectuer des tests facilement et rapidement à chaque étape du développement, sans avoir à installer à chaque fois son application sur un ter-minal. Heureusement, dans les deux cas, les SDK intègrent un simulateur d’environnement d’exé-cution (émulateur) reproduisant sur la machine du développeur le comportement du téléphone et permettant de tester le fonctionnement de l’application sur un terminal virtuel. Cependant, ces simulateurs ont des fonctionnalités moindre qu’un vrai terminal; dans les deux cas, l’émula-teur ne propose pas de gestion du Bluetooth.


2.1.4 Pile Bluetooth

Dans un système d’exploitation, les fonc-tionnalités Bluetooth sont gérées par un com-posant logiciel du coeur du système appelé «pile Bluetooth» (ou «Bluetooth stack»). Compa-rons les piles Bluetooth de chacun des environ-nements.

AndroidAndroid contient Bluez, la pile Bluetooth

open source utilisée par le noyau Linux.

http://www.bluez.org/

D’après la documentation officielle d’An-droid, le profil Bluetooth PAN n’est pas encore supporté officiellement dans Android 2.1. Ce-pendant, le démon «pand» permettant d’ef-fectuer des connexions Bluetooth PANU est compilé dans le système et peut être utilisé de manière expérimentale (voir paragraphe sur la première approche).

iPhoneLa documentation de l’iPhone fait très

peu état du Bluetooth. Il semble que les déve-loppeurs n’aient aucun accès aux couches bas niveau de la pile Bluetooth. Nous avons seule-ment trouvé des méthodes haut niveau (par exemple dans la librairie GameKit, pour connec-ter deux téléphones via Bluetooth). Même si une partie du profil PAN est implémenté (PAN-NAP pour l’utilisation du terminal comme mo-dem Internet), le rôle PANU ne semble pas être présent.

2.1.5 Ouverture

Les deux plate-formes présentent chacune quelques limitations. Cependant, des solutions officieuses existent pour les contourner. Même si ces solutions ne sont pas viables dans un en-vironnement de production, elle permettent de faire des expérimentations sur les différentes plate-formes.

Certains terminaux embarquant Android ne sont pas mis à jour par les constructeurs lorsqu’une nouvelle version d’Android est ren-due disponible. Cependant, une technique offi-cieuse permet de modifier la version d’Android présente sur le terminal («flasher la ROM»). Cette technique permet ainsi d’installer une ROM al-ternative, soit avec plus de fonctionnalités, soit avec un système plus récent ce qui peut être in-téressant pour le développeur si une nouvelle version d’Android intègre la gestion du profil Bluetooth PAN avec le rôle PANU.

Une manipulation officieuse existe aussi pour l’iPhone. Cette opération appelée «jail-break» consiste à modifier les droits d’accès à la partition système afin de pouvoir modifier directement le système de l’appareil et y ins-taller des applications alternatives. Il semble que beaucoup de choses soient faisables sur un iPhone jailbreaké. Malheureusement peu de documentation existe pour les développeurs, la communauté ne s’exposant que très peu sur In-ternet. Notons que cette manipulation annule la garantie du téléphone et qu’Apple fait tout pour rendre cette manipulation impossible.


2.1.6 Tableau récapitulatif

iPhone OS Android

SDK iPhone SDK Android SDK

Obtention du SDK Gratuit, sur inscription Gratuit

IDE supportés Xcode Eclipse, JDK, Apache Ant

Plate-forme de dévelop-pement

Mac Windows, Mac, Linux

Langage applicatif Objective C Java

Portail des développeurs http://developer.apple.com/iphone

http://developer.android.com

Emulateur Oui Oui

Gestion du Bluetooth dans l’émulateur

Non Non

Plate-forme de publica-tion des applications

App Store Android Market

Frais d’inscription à la plate-forme de publica-tion

99$ ou 299$ 25$


2.1.6 Conclusion

Cette étude préliminaire a fait apparaître les forces et faiblesses de chacun des environ-nements proposés, de sorte que nous avons pu faire le choix de notre environnement de déve-loppement. Nous avons décidé de concentrer nos efforts sur Android (avec le Samsung Galaxy acheté par le département RST de Telecom Su-dParis), et ce principalement pour deux raisons :

La portabilitéLe développement d’applications pour An-

droid peut se faire sur de nombreux systèmes (Windows, Mac, Linux) alors que le développe-ment d’applications pour iPhone OS est réservé aux possesseurs de Mac. Etant deux sur le projet et Maxime habitant à Paris, nous avons estimé que le fait de pouvoir travailler séparément sur nos machines personnelles (des PC sous Win-dows) représenterait un gain de temps consi-

dérable et faciliterait grandement l’organisation du travail.

L’ouvertureCette étude nous a permis de voir que

l’étendue des possibilités en terme de déve-loppement Bluetooth sur iPhone OS est très limitée. Certaines fonctions haut niveau sont disponibles, mais ne correspondent pas à nos besoins. Le développeur n’a par ailleurs pas suf-fisamment accès aux couches bas niveau pour implémenter ce type de fonctionnalité. An-droid, quant à lui, dispose d’une API Bluetooth qui semble plus complète. Si elle ne permet pas encore d’effectuer des connexions Bluetooth PANU, il est raisonnable de penser que l’implé-mentation de ces fonctionnalités aura lieu tôt ou tard. En attendant et dans le cadre de l’étude de faisabilité, la solution de l’utilisation du dé-mon expérimental «pand» nous est apparue comme une solution intéressante.

Ce choix étant fait, nous avons rapidement récupéré le Samsung Galaxy, et avons commencé nos premiers pas dans le monde merveilleux d’Android.


La première étape de notre travail avec l’environnement Android a été d’appré-hender le SDK, l’architecture et le déve-loppement d’une application ainsi que

son déploiement sur un terminal embarquant Android.

2.2.1 Présentation du SDK

Google a mis en place un grand nombre d’outils pour aider les développeurs Android.

Le portail des développeursLa première chose à visiter est le portail des

développeurs Android, mis en place par Google.

http://developer.android.com/

Très complet, ce site présente Android, ex-plique comment installer et utiliser les différents outils (SDK, NDK etc.), propose un ensemble de tutoriels et articles concernant le développe-ment d’applications Android, expose la réfé-rence de l’API Android ainsi que les actualités

liées à Android. Le tout est très bien fait et per-met de rapidement être confortable vis-à-vis du développement sur Android.

Le SDK AndroidL’outil le plus important est le SDK Android.

Facile à installer, il permet de télécharger tous les outils indispensables au développement d’applications. Un petit logiciel permet d’abord de télécharger les différentes versions du SDK (une version du SDK par version d’Android : 1.4, 1.5, 1.6, 2.0 etc.). Il permet également de télé-charger les différentes versions des Google APIs (APIs pour intégrer des fonctionnalités liées aux services Google tels que Maps etc.) ou de la do-cumentation JavaDoc. Son fonctionnement est similaire aux gestionnaires de paquets de Linux.

2.2 Prise en main de l’environnement


ADT pour Eclipse

Eclipse est l’Environement de Développe-ment Intégré (ou IDE) le plus largement utilisé pour la programmation Java; très performant, il est de plus gratuit et open source.

http://www.eclipse.org/

Le langage privilégié pour le développe-ment d’applications Android est justement Java. Google a donc tout naturellement conçu

un plugin pour Eclipse (un plugin est un module qui complète un logiciel hôte pour lui apporter de nouvelles fonctionnalités).

Android Development Tools, ou ADT, est très complet et surtout très pratique : concep-tion graphique d’interfaces utilisateur, debug distant sur un téléphone, gestion de l’architec-ture de fichiers d’une application etc.


Emulateur

Nous l’avons évoqué plus haut, le SDK pro-pose un émulateur Android. Il permet de lancer sur la machine du développeur un terminal vir-tuel représentant à l’écran un téléphone embar-quant Android. C’est bien évidemment un outil indispensable pour le développement mobile. A chaque version d’Android est associée une ver-sion de l’émulateur, permettant au développeur

de voir exactement à quoi ressemblera son ap-plication sur un matériel réel.

Rappelons cependant que l’émulateur ne propose pas toutes les fonctionnalités d’un vrai téléphone. Il ne permet par exemple pas d’ému-ler la gestion du Bluetooth.


2.2.2 L’échec du Samsung Galaxy

Nous venons de voir que l’émulateur Android ne permet pas la gestion du Bluetooth. Or, nous avi-ons bien évidemment be-soin de cette fonctionnalité pour l’application d’inter-phonie. Le département RST de Telecom SudParis a donc fait l’acquisition d’un téléphone embarquant An-droid : le Samsung Galaxy.

La configuration du Samsung Galaxy est tout à fait classique :

»» Android 1.5

»» Écran tactile AMOLED HVGA 3.2Mp

»» 3G, WiFi b/g, Bluetooth, GPS

»» 8Go de mémoire interne et port mi-croSDHC

»» 115 x 56 x 11,9 mm

Sur le papier, ce téléphone était donc par-fait pour nous permettre de travailler sur le projet dans de bonnes conditions. En pratique, nous avons rencontré beaucoup de difficultés et nous avons ainsi perdu du temps avec ce ma-tériel.

Lorsqu’un terminal Android est branché sur un ordinateur via son port USB, deux types de drivers permettent de gérer le matériel :

»» Le driver standard permet d’interagir avec le système d’exploitation pour les usages standards : synchronisation du télé-phone avec les contacts de l’ordinateur, le calendrier etc.

»» Le driver ADB est le driver dédié aux déve-loppeurs. Il permet de dé-ployer sur le téléphone une application en développe-ment, et de débuguer une application tournant sur le téléphone depuis l’IDE

Eclipse sur l’ordinateur du développeur.

En pratique, le driver ADB ne fonctionne pas avec le Samsung Galaxy. Nous ne le savions pas au début et nous avons ainsi perdu beau-coup de temps avec ce problème. Voici l’extrait d’un article trouvé plus tard sur Frandroid, un excellent portail francophone dédié à Android:

Enfin pour les développeurs, sachez que le fonctionnement d’adb sur le Samsung reste pour le moment approximatif et des solutions non officielles existent.

http://www.frandroid.com/4178/comparatif-htc-hero-et-samsung-galaxy/

Nous étions ainsi complètement bloqués sur le projet. Il nous fallait absolument trouver une solution pour pouvoir concrètement déployer une application sur un matériel.


2.2.3 La victoire du Hero

Le département Informatique de Telecom SudParis a fait l’acquisition de deux téléphones embarquant Android, des HTC Hero, a peu près au moment où le département RST a acheté le Samsung Galaxy. Ils ont donc gracieusement ac-cepté de nous prêter un HTC Hero le temps du projet.

Voici les caractéristiques du HTC Hero:

»» Android 1.5 avec une couche graphique personnalisée développée par HTC

»» Écran TFT LCD tactile multi-touch de 3,2Mp (320 x 480)

»» 3G, WiFi 802.11b/g, Bluetooth, GPS

»» Processeur Qualcomm MSM7200A 528MHz

»» 288MB de RAM

»» 512MB de mémoire interne et slot mi-croSDHC

»» 112 x 56.2 x 14.35 mm

Le HTC Hero est très bien géré par le driver ADB. Nous pouvions ainsi facilement déployer nos applications sur le téléphone. Nous étions alors dans de bonnes conditions pour continuer notre travail sur le projet.


2.2.4 Application test

Rien de mieux pour s’habituer à un environnement de développement que de pratiquer cet environnement. C’est pourquoi nous avons commencé par développer une application de test pour appréhender les concepts liés aux applications Android : architecture de l’application, manifeste de l’application, architecture et conception des interfaces utilisateur, «Activities» et «Services» (qui per-mettent d’afficher une fenêtre ou de lancer un service en tâche de fond) et liens entre ces entités, persistance des données etc.

Ce travail nous a confortés dans l’idée que le SDK Android est vraiment agréable à utiliser: bien conçus, les différents outils permettent de faire gagner beaucoup de temps au développeur. Le SDK Android est donc un modèle d’ergonomie.


2.3 Le problème du profil PAN

Le sujet de notre projet précise que notre application de communication doit se connecter au réseau de la RATP en uti-lisant la technologie Bluetooth. Cette

technologie de communication sans fil propose différents «profils» de communication, qui cor-respondent à des spécifications fonctionnelles liés à un usage particulier. Il existe de nombreux profils Bluetooth : le profil HeadSet par exemple, qui permet de gérer la connexion Bluetooth entre un ordinateur et des écouteurs sans fils, ou encore le File Transfer Profile, utilisé pour le transfert de fichiers entre deux appareils. Dans notre cas, le smartphone doit se connecter au point d’accès en utilisant le profil PAN, pour «Personal Area Network», qui est un profil gé-néral pour la connexion à un réseau local. Ce

profil PAN implémente différents rôles, dont le rôle PAN-U (pour PAN-User, utilisateur du ré-seau) dont va se servir notre téléphone et le rôle PAN-NAP (pour PAN-Network Access Point, ou point d’accès réseau) qui sera utilisé sur les points d’accès de la RATP. Nous avons donc be-soin d’accéder au profil PAN sous Android pour effectuer la connexion au point d’accès.

2.3.1 Architecture d’Android

Pour bien comprendre comment accéder à ce profil, commençons par détailler l’architec-ture du système Android. Le portail des déve-loppeurs Android nous présente l’architecture du système avec le schéma ci-contre.


Linux Kernel

Android s’appuie sur le noyau Linux 2.6 pour les services système de base tels que la sé-curité, la gestion de la mémoire et des proces-sus, le réseau et la gestion des drivers. Le noyau sert de couche d’abstraction entre le matériel et le reste de la pile logicielle.

Android RuntimeAndroid inclut un ensemble de librairies

fournissant la plupart des fonctionnalités des librairies standard de Java. Chaque application Android s’exécute dans un processus, avec sa propre instance de la machine virtuelle Java, appelée Dalvik. Dalvik a été écrit pour optimi-ser l’exécution d’une multitude d’instances de la machine virtuelle, avec une empreinte mé-moire réduite. Dalvik s’appuie sur le noyau Linux pour les fonctionnalités bas-niveau tels que les threads ou la gestion de la mémoire.

LibrariesAndroid fournit un ensemble de librairies

C/C++ utilisées par différents composants du système. Ces fonctionnalités sont rendues dis-ponibles aux développeurs au travers du fra-mework d’application d’Android. On trouve parmi ces librairies: librairie C standard, moteurs d’affichage 2D et 3D, SQLite, rendu des polices de caractères etc.

Application FrameworkLe framework d’application est la couche

qui nous intéresse tout particulièrement. C’est elle qui fait le lien, grâce à un ensemble d’APIs Java, entre le système et l’application. Étant un système ouvert, Android permet aux dé-veloppeurs de concevoir des applications très

riches et de tirer partie d’un maximum de fonc-tionnalités. Les développeurs ont donc accès aux même fonctionnalités que celles utilisées par les applications fournies avec Android. Toute application Android repose sur un ensemble de services et systèmes parmi lesquels :

»» Un ensemble de «Views» permettant de construire l’interface graphique de l’ap-plication : listes, grilles, champs textes, images, et même intégration d’un navi-gateur web ou d’une vue Google Maps

»» Des «Content Providers» qui permettent aux applications d’accéder à des don-nées d’autres applications ou de parta-ger ses propres données

»» Un «Ressource Manager» pour accéder à des éléments autres que du code : don-nées textuelles traduites, images, des-criptions XML d’interfaces graphiques etc.

»» Un «Activity Manager» pour gérer le cycle de vie de l’application

Ce rapide survol de l’architecture du sys-tème nous permet de mieux comprendre com-ment fonctionne une application Android. Confinée dans la couche la plus haute, elle ac-cède au système uniquement via les APIs Java exposées par la couche Application Framework. Ainsi, si une fonctionnalité est présente dans le noyau Linux (couche rouge sur le schéma) ou dans les libraires système (couche verte), mais qu’elle n’est pas reliée au framework d’applica-tion, elle ne sera pas utilisable directement dans une application Android.


2.3.2 Profil PAN sous Android

Le profil PAN est bien présent sous Android, cependant il se trouve au niveau du noyau Li-nux, et n’a pas encore été relié à l’API Java de dé-veloppement d’applications. Cela signifie que les développeurs d’applications d’Android n’ont pas accès à ce profil. Normalement le profil PAN se trouve donc hors de notre portée. Il est donc impératif pour nous de trouver un moyen de contourner ce problème et de faire fonctionner une connexion utilisant le profil PAN sur le télé-phone.

2.3.3 Nouvelle orientation de notre problématique

Nous avons donc dû réviser nos objectifs initiaux, puisque le développement d’une ap-plication serait inutile tant que nous n’avons au-cun moyen d’effectuer la connexion Bluetooth entre le téléphone et le point d’accès. Nous nous sommes donc concentrés sur les diffé-rents moyens de faire marcher le profil PAN sous Android, et les tests de ses différents moyens, avant de se servir de ces résultats pour dévelop-per l’application finale. Nos recherches nous ont permis d’identifier deux solutions, que nous dé-taillons dans la partie suivante.


2.4 Première solution

2.4.1 Théorie

La gestion du Bluetooth dans une application passe par l’API Java Bluetooth d’Android. Mal-heureusement, au moment du projet, le profil Bluetooth PAN n’était pas intégré à l’API Java et donc pas utilisable directement dans une application. Nous venons de voir qu’Android est basé sur le noyau Linux 2.6 et il contient Bluez, la pile Bluetooth open source du noyau Linux.

Bluez supportant le profil PAN, on pouvait penser que le système contenait les briques nécessaires pour la gestion du profil en question, même si ces briques n’étaient pas reliées au framework d’ap-plication.

Le schéma ci-contre présente l’architecture du Bluetooth dans An-droid. Les «briques de base» du profil PANU sont pré-sentes dans le rectangle «Bluez» mais ne sont pas reliées à l’API Java comme c’est le cas, par exemple, pour RFCOMM.


C’est le démon «pand» qui permet de gé-rer le profil PAN sous Linux (avec ses trois rôles PANU, NAP et GN). Cet exécutable est com-pilé avec Android et est donc présent dans le système. En théorie, il suffit donc de lancer ce démon pour établir une connexion Bluetooth PANU. Le problème est que le système Linux, et encore plus Android, est très restrictif en terme de droits d’accès. Lorsqu’un usager (un utilisa-teur physique) interagit avec son terminal, il utilise de manière transparente un utilisateur virtuel sur le système (on peut faire l’analo-gie avec les comptes utilisateurs de Windows). Ainsi, l’utilisateur virtuel standard d’Android n’a pas accès aux fichiers système et notamment au démon «pand». Pour y accéder, il faut bénéficier des droits d’accès du super utilisateur «root».

Bien évidemment, par défaut «root» n’est pas utilisable. Il est cependant possible d’avoir accès à cette fonctionnalité en «débloquant» le téléphone. Cette manipulation officieuse consiste à modifier le système installé sur le té-léphone (flasher la ROM). Des acteurs de la com-munauté ont ainsi rendu disponible des ROM alternatives permettant, entre autre, l’accès à l’utilisateur «root».

Notons cependant qu’une solution offi-cielle (et plus pratique, comme nous le verrons plus loin) existe. Google distribue des «Android Dev Phone» ou ADP, téléphones dédiés aux dé-veloppeurs et complètement débloqués : l’uti-lisateur «root» est accessible et il est facile de flasher la ROM pour installer une version modi-fiée.

Dans notre cas, nous avions un téléphone standard sans accès à l’utilisateur «root». Il suf-fisait donc, en théorie, d’installer une ROM al-ternative et de lancer avec l’utilisateur «root» le démon «pand» créant ainsi une connexion Blue-tooth PANU avec notre point d’accès Bluetooth. Un article lu sur le blog d’un développeur nous montra que cette solution était théoriquement possible. Notons que l’auteur de ce billet utili-sait un ADP !

http://mrkunkel.com/2009/08/11/the-other-tether-the-g1android-as-a-bluetooth-panu-client/

Il est important de préciser que cette ap-proche est une «bidouille» et n’est donc absolu-ment pas envisageable dans un environnement de production. Les utilisateurs finaux de l’appli-cation ont pour la plupart un système standard et donc pas l’accès à l’utilisateur virtuel «root». Cette approche permet cependant de montrer que le système contient les éléments néces-saires à l’établissement d’une connexion Blue-tooth PANU.

2.4.2 Pratique

En pratique, ce ne fut pas si simple. Nous avons installé différentes ROMs, chacune ve-nant avec son lot d’erreurs et de difficultés.

Modaco custom ROMhttp://android.modaco.com/content/htc-hero-hero-

modaco-com/292018/11-jan-3-1-modaco-custom-rom-for-gsm-hero/

La «Modaco custom ROM» donne accès à l’utilisateur root. Le démon «pand» n’est plus


présent dans le système, mais il est présent dans une application installée par défaut avec la ROM. Nous n’avons cependant pas réussi à créer une connexion Bluetooth PANU. Il nous manquait dans cette ROM des outils initialement fournis dans Android tels que «hcitool».

Firmware Smartphone Francehttp://android.smartphonefrance.info/actu.asp?ID=328

Le portail Smartphone France propose lui aussi une ROM alternative pour Android avec ac-cès à l’utilisateur «root». Nous avons avec cette ROM rencontré les mêmes problèmes avec la ROM Modaco, à savoir qu’il nous manquait cer-tains éléments clés du système pour faire fonc-tionner le profil PAN.

Modaco stock rooted ROMhttp://android.modaco.com/content/htc-hero-hero-

modaco-com/291942/22-jan-stock-roms-radios-in-update-zip-format-for-gsm-hero/

Le portail Modaco propose également une ROM «stock rooted», c’est-à-dire une ROM usine avec comme seule modification l’accès à l’utili-sateur «root». En théorie, cela devait résoudre nos problèmes. En pratique, nous n’avons pas trouvé le démon «pand» (ni d’ailleurs d’autres outils usuels tels que «locate», «which» ou même «grep» !). Nous avons donc eu des doutes sur le fait que cette ROM soit réellement une ROM usine.

2.4.3 Bilan de la première solution

Cette première approche se solde donc par un échec. Parce que nous n’avions pas accès à l’utilisateur «root», nous n’avons pu lancer un appel système au démon «pand». Nous n’avons de plus pas réussi à obtenir un système réunis-sant tout ce dont nous avions besoin: démon «pand», outils associés et utilisateur «root».


2.5 Deuxième solution

Cette solution nous est apparue as-sez tardivement (dans les deux der-nières semaines du projet), grâce aux conseils de Sébastien Leriche.

Elle consiste en l’utilisation du NDK.

2.5.1 Présentation du NDK

JNI

D’après http://fr.wikipedia.org/wiki/Java_Native_Interface

Le JNI (Java Native Interface) est un fra-mework qui permet à du code Java s’exécutant à l’intérieur de la JVM d’appeler et d’être appe-lé par des applications natives (c’est-à-dire des programmes spécifiques au matériel et au sys-tème d’exploitation de la plate-forme concernée), ou avec des bibliothèques logicielles basées sur d’autres langages (C, C++, assembleur, etc.). Voici quelques exemples d’utilisation de la JNI :

»» Implémentation de fonctions du système d’exploitation qui ne sont pas présentes dans la bibliothèque Java

»» Interfaçage avec des applications écrites dans d’autres langages

»» Amélioration des performances, un lan-gage compilé (c’est-à-dire du code natif ) étant plus rapide que de passer par le bytecode de Java.

NDK

Le NDK pour Android (Native Development Toolkit) propose un ensemble d’outils pour per-mettre aux développeurs d’utiliser le framework JNI dans leurs applications. Alors qu’une appli-cation s’éxécute au sein de la machine virtuelle Dalvik, le NDK permet d’implémenter une partie de l’application en utilisant du code natif tel que C ou C++. Cette technique permet d’une part d’améliorer les performances de certains algo-rithmes ou programmes, et d’autre part d’avoir


accès à plus de fonctionnalités que ce que pro-pose l’Application Framework. Le NDK fournit:

»» Un ensemble d’outils pour compiler du code source C ou C++ pour Android

»» Une manière de déployer ce code com-pilé sur un matériel Android et de l’inté-grer à une application Android écrite en Java

»» De la documentation, des exemples et des tutoriels

2.5.2 Théorie

Dans notre cas, ce qui est intéressant est de pouvoir accéder aux fonctionnalités du dé-mon «pand», situé dans la pile Bluetooth Bluez, elle-même faisant partie du noyau Linux tour-nant sur le téléphone. Bluez étant un projet open source, l’idée était de récupérer le code source du démon «pand» et, grâce au NDK, de l’incorporer dans du code natif qui sera ensuite appelé par notre application. Évidemment, cette méthode semble quelque peu archaïque, puisqu’elle consiste à recopier du code déjà pré-sent dans le système au sein de notre applica-tion. Cependant, son avantage principal est de ne pas nécessiter de modification préalable du téléphone, contrairement à la solution précé-dente. En effet, elle n’a pas recours à des opéra-tions nécessitant des droits d’administration, le flashage du téléphone est donc inutile. De plus, cette solution est potentiellement portable sur tout système Android. Cette solution semble donc la plus propre et la plus viable pour le pro-jet, tant que le profil PANU n’aura pas été implé-menté directement au sein de l’API Java. Elle est

tout à fait envisageable dans un environnement de production.

2.5.3 Pratique

Nous avons dans un premier temps télé-chargé et installé le NDK Android sur nos ma-chines. La configuration s’est faite sans pro-blème. Nous avons pu rapidement concevoir et développer une application permettant de tester le NDK en faisant appel à une fonction écrite en C++ depuis notre application Android écrite en Java. Les premiers tests furent donc concluants.

L’étape suivante a alors été de récupérer le code des fonctions qui nous intéressaient et de les incorporer dans notre application. Nous avons donc téléchargé le code source de Bluez et regardé les sources. Malheureusement pour nous, Bluez est un projet peu documenté avec un code source non commenté et assez obscur. Il nous a donc fallu un certain temps pour com-prendre la structure du code et isoler la partie concernant l’établissement d’une connexion Bluetooth PANU. Une fois cette partie isolée, il ne restait plus qu’à la recopier dans notre projet NDK et de compiler le tout pour Android.

Mais bien entendu, la compilation s’est avé-rée assez difficile. En effet, de nombreuses fonc-tions déclarées dans ce code étaient en réalité définies dans d’autres fichiers. A l’édition des liens, nous obtenions donc de nombreux mes-sages d’erreur signalant des fonctions introu-vables. Aucune documentation n’étant dispo-nible, il a fallu pour chacune de ces fonctions rechercher le fichier la définissant, l’incorporer


au projet, puis corriger toutes les nouvelles er-reurs de syntaxe et de dépendance liées à l’arri-vée de ces nouveaux fichiers dans le projet. Ce fut donc un travail long et fastidieux.

Cependant, nous avons fini par réussir à éli-miner toutes les erreurs de compilation et d’édi-tions des liens et à compiler notre application. En pratique, notre application affiche un champ de texte dans laquelle on peut renseigner l’adresse

MAC du point d’accès Bluetooth auquel on dé-sire se connecter. Lorsque l’utilisateur appuie sur le bouton de validation, une fonction native est appelée, avec en paramètre l’adresse MAC fournie par l’utilisateur. Cette fonction essaie de se connecter au point d’accès avec le rôle PANU, puis affiche le code de retour du programme (message d’erreur ou de succès) dans un boite de dialogue.


2.5.4 Bilan de la deuxième solution

Nous n’avons malheureusement pas réussi à établir une connexion Bluetooth PANU avec succès en utilisant cette méthode. Le programme compile et la fonction s’exécute sur le téléphone, mais des erreurs se produisent à l’exécution. La suite du travail était donc de comprendre ces erreurs et de les corriger. Nous n’avons cependant pas eu le temps de continuer ce travail dans le cadre de notre projet.

Cela a cependant permis de montrer que l’intégration du code source du démon «pand» via le NDK est une solution très intéressante. Nous pensons qu’il s’agit de la meilleure solution tant que le profil PANU ne sera pas officiellement intégré dans l’API Java de gestion du Bluetooth.


Nous avons donc terminé notre projet avec un bilan plutôt mitigé.

D’un côté, nous avons effectué un grand travail de tri de l’information et de résolution de problèmes qui permettra aux groupes de travail après nous de gagner du temps et de directe-ment travailler sur le coeur du problème.

D’un autre côté, nous aurions aimé réussir à déployer avec succès une connexion Bluetooth PANU ! Notre intuition nous dit qu’avec tout le travail que nous avons réalisé, le déploiement effectif du profil PANU sous Android n’est pas loin. Nous regrettons donc ne pas avoir eu le temps de réussir cette tâche.

Enfin, sur un plan plus personnel, nous avons regretté de ne pas avoir eu plus de pro-grammation à faire, l’essentiel du travail réalisé sur le projet étant de manipuler Android sous toute ses coutures pour comprendre pourquoi telle ou telle manipulation ne marchait pas. Ce fut cependant une expérience enrichissante et surtout très intéressante. Nous sommes mainte-nant parfaitement à l’aise avec le système An-droid et le développement d’applications dé-diées. La technologie étant vraiment d’actualité,

c’est une expérience que nous pouvons donc valoriser auprès des entreprises, aspect impor-tant puisqu’à l’heure où nous écrivons ces lignes nous nous apprêtons à entrer dans la vie active.

Par rapport au planning initial, la réparti-tion effective du temps de travail s’est faite assez différemment, puisque presque tout le temps dédié au développement de l’application a été utilisé en réalité pour les tests des différentes solutions d’utilisation du profil PAN sous An-droid. Notre plan de charge effectif est dispo-nible en annexe, et reflète clairement cet état de fait. Rétrospectivement, nous nous sommes rendus compte que le planning initial aurait dû prévoir qu’une phase de tests de connexion Bluetooth serait nécessaire avant de se lancer dans le développement de l’application, et cet oubli n’a pas facilité l’organisation de notre tra-vail. Il aurait été cependant bien difficile de pré-voir quelle ampleur cette phase allait prendre, ainsi que tous les problèmes qu’elle allait nous apporter. Nous estimons que ce temps de re-cherche de solutions au problème du profil PAN et de test nous a coûté plus de 60 heures de tra-vail chacun, soit environ 40% de notre temps passé sur le projet.

3 bilAn


4 suite du projet

Notre projet ASR s’inscrivant dans le cadre d’un projet plus global, il nous semble important de faire en sorte que notre travail puisse être facilement réutilisé par la suite pour servir de base pour des développements futurs, d’autant plus que la reprise de nos travaux fera l’objet d’un projet PJ20 à Telecom SudParis cette année. Si nous n’avons pas pu remplir

tous les objectifs que nous nous étions fixés au début du projet, notre travail aura permis d’identifier les problèmes majeurs liés au développement de cette application, et d’apporter une base de solu-tion qui nous semble satisfaisante. Cette base permettra à l’équipe PJ20 de démarrer dans la bonne direction et d’éviter les problèmes que nous avons eus à résoudre. Voici selon nous les prochaines étapes du projet.

4.1 Tests de VoIP

Une fois la connexion Bluetooth mise en place, l’utilisateur devra pouvoir appeler un agent RATP via un protocole de voix sur IP. L’ap-plication devra donc, après connexion Blue-tooth et initialisation des paramètres réseau IP, lancer une application de VoIP permettant d’ap-peler un poste sur le réseau. Une fois l’applica-tion de VoIP choisie et reliée à notre application, des tests devront être effectués pour s’assurer que la communication via ce logiciel fonctionne correctement. Il existe différents logiciels VoIP disponibles sur Android, notamment «sipdroid», qui semble correspondre à nos besoins et fonc-tionner sur un réseau local. Il s’agit d’un projet open source, on peut ainsi s’intéresser à la pos-

sibilité d’adapter et d’intégrer le code source de cette application à l’application dédiée au projet (attention cependant aux questions de licence).

http://sipdroid.org/

D’autres logiciels comme Fring ou NimBuzz sont disponibles, mais semblent cependant moins intéressants, car ils nécessitent de créer un compte avant utilisation. D’autre part Fring nécessite pour fonctionner un accès à Internet, tandis que notre application est vouée à être exécutée uniquement sur un réseau local. No-tons que ces informations sont théoriques et qu’elles nécessitent d’être approfondies.


4.2 Automatisation de l’application

Un des aspects fonctionnels qui doit également être mis en place est l’automatisation de l’application. En effet, plutôt que de demander

à l’utilisateur d’entrer toutes les informations nécessaires, l’application doit une fois lancée découvrir d’elle-même tous les points d’accès à portée, choisir d’elle-même celui auquel se connecter, et une fois connectée lancer d’elle-même un appel vers un poste d’un agent de la RATP. En ce qui concerne la découverte des points d’accès bluetooth, nous avons trouvé au cours de nos recherches une méthode qui semblerait convenir. Nous n’avons pas pu la tes-ter par manque de temps mais nous pensons qu’elle mérite qu’on s’y attarde. L’article original

détaillant cette méthode peut être consulté à l’adresse suivante :

http://blog.bruary.net/2009/07/android-bluetooth-hacking-using-ndk.html

Notre travail effectué sur le projet est dis-ponible sur un serveur SVN, avec toute la docu-mentation correspondante.

http://code.google.com/p/gou1-sandbox/source/browse/#svn/trunk/android

Nous nous proposons de plus de rencontrer les futurs membres du projet PJ20 afin d’échan-ger sur le projet, de faciliter la transition.

4.3 Android Dev Phone

Google propose aux développeurs deux téléphones entièrement débloqués et sans au-cun blocage de la carte SIM : accès à l’utilisateur système «root», possibilité de flasher la ROM pour installer sa propre version du système An-droid etc., ce matériel est l’idéal pour les déve-loppeurs. Il serait éventuellement judicieux de faire l’acquisition d’un tel téléphone pour ré-duire les soucis liés au matériel; la difficulté que nous avons eu à trouver une ROM alternative

correcte pour le HTC Hero illustre bien ces sou-cis.

http://developer.android.com/guide/developing/device.html#dev-phone-1

Le premier ADP, surnommé ADP1 et basé sur un HTC Dream/G1, est proposé au prix de 399$ sur le portail des développeurs Android.


conclusion

Cette étude a permis de montrer que le déploiement de l’application de communication Bluetooth était théoriquement possible sur la plate-forme Android. Même si nos expéri-mentations concrètes ont échoué, nous sommes confiants qu’une solution est possible moyennant un travail supplémentaire. Il nous parait de plus judicieux de remarquer que

le profil PAN sera probablement implémenté, dans le futur, dans l’API Java Bluetooth d’Android. En effet, chaque nouvelle version d’Android apporte son lot de nouveautés, y compris concernant le Bluetooth; plusieurs profils ont ainsi été implémentés depuis Android 1.0. Aucune date n’est cepen-dant officiellement prévue concernant l’intégration du profil PAN à Android.


bibliogrAphie et références

1 Documents relatifs au projet

Rapport de projet «Projet RATP - Voix sur Bluetooth»

Lidia Rodriguez Fernandez & Oussama Ben Cheikh Souguir, Juin 2007

Rapport de projet «Expérimentation de la voix sur Bluetooth»

Achille Notue Souop & Philippe Tagoum Fogang & Dafé Gnabaly, 2008

Rapport de stage «L’interphonie mobile sur Bluetooth»

Toko Luyeye, novembre 2008

2 Liens Internet

Portail des développeurs Apple (références, documentation, tutoriels)

http://developer.apple.com/

Portail des développeurs Android

http://developer.android.com/

Documentation officielle du Bluetooth sur Android

http://developer.android.com/guide/topics/wireless/bluetooth.htmlhttp://developer.android.com/reference/android/bluetooth/package-summary.html

Etablissement d’une connexion Bluetooth PANU sur un ADP1

http://mrkunkel.com/2009/08/11/the-other-tether-the-g1android-as-a-bluetooth-panu-client/

Site officiel de Bluez

http://www.bluez.org/

Référence du NDK Android

http://developer.android.com/sdk/ndk/1.5_r1/index.html


Application alternative de «Tethering» pour Android, utilisant le démon «pand»

http://code.google.com/p/android-wifi-tether/

Tutoriel sur le NDK avec utilisation du Bluetooth

http://blog.bruary.net/2009/07/android-bluetooth-hacking-using-ndk.html

API Bluetooth expérimentale pour Android

http://code.google.com/p/android-bluetooth/

Tutoriel en français pour flasher la ROM du HTC Hero

http://wiki.smartphonefrance.info/%28X%281%29S%28r1onbd554mjg4rntopujcy45%29%29/Default.aspx?Page=hero-upgrade-modaco-rom&AspxAutoDetectCookieSupport=1

Communauté anglophone dédié au HTC Hero, nombreuses ROM disponibles

http://android.modaco.com/content/htc-hero-hero-modaco-com/


chArge de trAvAil

Guillaume Maxime

Total»en»heures 153 151TâcheProposition calendrier 1 1Recherche de documentation sur Android et iPhone 10 15Rédaction du rapport préliminaire 5 4Récupération du SDK Android, installation, configuration, premiers tests 5 5Tests de pilotage du Samsung Galaxy via l'interface USB 5 10Construction d'une première application "bac à sable", installation sur HTC Hero 10 10Préparation & présentation RATP 4 4Documentation sur le rootage, premier rootage du HTC Hero 10 10Tests d'exécution du démon "pand" sur Hero rooté 20 30Documentation sur le NDK, récupération, installation 5 4Configuration du NDK, Développement d'une application Hello World utilisant le NDK 3 0Récupération, étude du code de Bluez 10 5Développement d'un prototype d'application de à un point d'accès Bluetooth utilisant le NDK

20 8

Rédaction rapport 20 20Préparation présentation 10 10Réunions d'avancement 15 15