Système Expert pour Smartphones

(1)

INSA Rennes – Département INFORMATIQUE

Système Expert pour Smartphones

Rapport de Pré-‐étude

Olivier Corridor; Romain Boillon; Quentin Decré; Vincent Le Biannic;; Germain Lemasson; Nicolas Renaud; Fanny Tollec 2010-‐2011

Projet sous la direction de Laurence Rozé

(2)

T ABLE DES MATIERES

1. INTRODUCTION ... 3

1.1. PRÉSENTATION DE TÉLÉLOGOS ... 4

1.2. PRÉSENTATION DE DREAM ... 4

2. PRÉSENTATION DU PROJET 09/10 ... 6

2.1. SYSTÈME EXPERT ... 6

2.2. DÉCOUPAGE DU PROJET ... 7

2.3. APPRENTISSAGE ... 8

2.4. COMMUNICATION (MÉDIA CONTACT) ... 8

3. PREREQUIS POUR LA MISE EN PLACE D’UN SYSTEME EXPERT SUR MOBILE ... 9

4. IPHONE ... 11

4.1. PRÉSENTATION GÉNÉRALE ... 11

4.1.1. Côté matériel ... 11

4.1.2. Côté OS : l’iOS 4 ... 11

4.2. FONCTIONNER EN TÂCHE DE FOND ... 12

4.2.1. Introduction ... 12

4.2.2. Audio en tâche de fond ... 13

4.2.3. VOIP ... 13

4.2.4. Positionnement en tâche de fond ... 14

4.2.5. Notifications Push ... 14

4.2.6. Notifications locales ... 14

4.2.7. Finir une tâche ... 14

4.2.8. Basculement rapide entre applications ... 15

4.2.9. Solution pour permettre un fonctionnement en tâche de fond. ... 15

4.3. LECTURE D’INFORMATIONS SYSTÈME ... 15

4.4. AGIR SUR LE SYSTÈME ET LES AUTRES APPLICATIONS ... 16

4.5. LE SYSTÈME EXPERT IOS ... 16

4.6. TESTS RÉALISÉS ... 17

5. ANDROID ... 18

5.1. PRÉSENTATION GÉNÉRALE ... 18

5.1.1. Côté matériel ... 18

Lyrkan 22/10/10 00:52

Commentaire [1]: NE PAS OUBLIER DE METTRE A JOUR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

(3)

5.1.2. Côté OS : Android ... 18

5.2. FONCTIONNEMENT INTERNE ... 19

5.2.1. Développement sous Android ... 21

5.3. FONCTIONNER EN TÂCHE DE FOND ... 21

5.4. LECTURE D’INFORMATIONS SYSTÈME ... 22

5.5. LE SYSTÈME EXPERT D’ANDROID ... 23

5.6. TESTS RÉALISÉS ... 23

5.6.1. Lecture d’informations système ... 23

5.6.2. Lecture de logs ... 23

6. APPRENTISSAGE ... 25

6.1. INTRODUCTION ... 25

6.2. OUTILS ... 27

6.3. ANNÉE PRÉCÉDENTE ... 27

6.4. CETTE ANNÉE ... 29

7. OUTILS DE DÉVELOPPEMENT ... 29

7.1. ECLIPSE ... 29

7.2. XCODE ... 29

7.3. APPCELERATOR TITANIUM ... 30

8. CONCLUSION ... 34

9. BIBLIOGRAPHIE ... 35

10. ANNEXES ... 36

10.1. ANNEXE : EXEMPLE DE RÉCUPÉRATION D’INFORMATIONS SOUS ANDROID ... 36

10.2. ANNEXE : APPLICATION DE LECTURE DES LOGS SOUS ANDROID ... 38

10.3. ANNEXE : APPLICATION DE LECTURE DES INFORMATIONS SYSTÈME RÉALISÉE SOUS TITANIUM ... 43

10.4. ANNEXE : PREMIER PROGRAMME SUR IPHONE ... 44

(4)

1. Introduction

Aujourd’hui, le téléphone mobile devient Smartphone. En effets, un public de plus en plus conséquent est intéressé par ces appareils multitâches, capables aussi bien de recevoir des appels que d’exécuter des taches diverses et variées, devenant de véritables ordinateurs miniatures. La taille des boutiques d’applications pour Smartphones explose. Mais comme sur tout matériel informatique, une telle quantité de logiciels pose le problème de la stabilité et fiabilité des appareils. Il semblerait alors judicieux d’être capable d’effectuer des diagnostics sur ces Smartphones, afin de comprendre et corriger ces erreurs. C’est ce en quoi consiste le projet

« ManageYourself ».

ManageYourself est un projet de diagnostic et surveillance de plates-‐formes embarquées, il s'inscrit dans le cadre d'une collaboration entre Telelogos et DREAM. Telelogos est une entreprise éditant des logiciels professionnels qui automatisent, administrent et optimisent les processus d’échanges entre système informatique central et ceux des utilisateurs distants. DREAM est une équipe de recherche de l'IRISA spécialisée dans l'aide à la surveillance et au diagnostic de systèmes évoluant dans le temps. Le besoin de développer une telle application émane de Telelogos, qui cherche à exploiter les possibilités dans le domaine du MBM (Mobile Device Management).

L’année passée, un groupe d’étudiants est parvenu à développer un outil permettant d’effectuer des diagnostics, grâce à des systèmes experts, sur des assistants personnels fonctionnels. Ceux-‐ci fonctionnant sous Windows mobile. Mais comme sur nos ordinateurs, le système d’exploitation produit par Windows n’est pas seul sur le marché. Il se trouve aujourd’hui en position de dominé. En effet, La part de marché des Smartphones Android et des iPhone est plus grande de jour en jour. Notre projet d’étude est basé sur cette idée : comprendre le projet de l’année précédente, pour ensuite produite un logiciel similaire, voir amélioré, adapté a l’iOS4 des iphones, et à la plateforme Android pour Smartphone.

Le projet est clairement une étude de faisabilité. Les systèmes iOS pour l’iPhone, et Android diffèrent de façon importante de Windows mobile 6. Aussi, l’objectif est d’étudier les caractéristiques de ces deux systèmes mobiles afin de parvenir à mettre en place un système expert. Parallèlement à cela, il faut faire évoluer le projet de l’année passée dans son ensemble, et non simplement adapter le système aux iPhones et Smartphones Androïd. Il est donc indispensable de passer un certain temps à étudier le travail déjà mené les années précédentes, pour en tirer le maximum, puis mener des recherches et tests plus poussés pour explorer

différentes pistes, et en déduire des solutions plus aptes à remplir le cahier des charges.

Hurlebibi 19/10/10 14:25

Commentaire [2]: Ca va mieux comme ca?

Hurlebibi 19/10/10 14:30

Commentaire [3]: Pas sure que la modif soit mieux que l’original.

(5)

1.1. Présentation de Télélogos

Télélogos est une société spécialisée dans le développement et l’entretien de middleware, gestion de parc, synchronisation de données, transfert de fichiers volumineux, affichage dynamique, etc. Ces logiciels sont principalement destinés à la grande distribution (point de vente, galerie marchande), au fonctionnement interne d’entreprises, et à la communication (agences de communication, régies publicitaires). A ce jour, 250 000 logiciels Telelogos sont en exploitation dans le monde. 2 000 grands comptes ou PME les utilisent quotidiennement pour gérer leurs échanges de données stratégiques, dont Intermarché, Jardiland, Picard Surgelés, Pimkie, Cadbury, Champagne Taittinger, Danone, Aéroports de Paris…

1.2. Présentation de DREAM

L’IRISA (Institut de Recherche en Informatique et Systèmes Aléatoires), est une unité mixte de recherche (UMR 6074) créée en 1975, partenaire avec le CNRS, l’Université de Rennes 1, l’INSA de Rennes, et l’ENS Cachan (antenne de Bretagne), et associée à l’INRIA par le biais de nombreuses équipes communes au centre INRIA Rennes, Bretagne Atlantique, dont l’équipe DREAM fait partie, et a pour thème de recherche principal l’aide à la surveillance et au diagnostic de systèmes ou activités complexes évoluant dans le temps. Le but est d’inférer l’état d’un système (détection de dysfonctionnements) à partir d’observations relevées sur ce dernier, en effectuant dans l’idéal, d’éventuelles réparations.

Les principaux axes de recherche sont :

-‐ L’acquisition automatique de modèles en utilisant des techniques d’apprentissage symbolique à partir d’exemples telles que la PLI (Programmation Logique Inductive).

-‐ Le développement d’algorithmes efficaces utilisant la notion de diagnostiqueur (inversion et compilation du modèle). Ces algorithmes produisant un modèle compact liant directement observations et pannes.

-‐ L’interaction entre diagnostic et décision dans un univers incertain.

(6)

Les domaines d’application de l’équipe sont :

-‐ Le monitoring cardiaque : L’analyse en ligne d’électrocardiogrammes, l’étude de prothèses cardiaques « intelligentes » (stimulateurs et défibrillateurs).

-‐ La protection de l’environnement : Amélioration de la classification de parcelles agricoles à partir d’images de télédétection, modélisation qualitative du transfert de polluants tels que les pesticides et les nitrates.

-‐ Le diagnostic industriel : Supervision de réseaux de télécommunications et de

distribution d’électricité.

(7)

2. Présentation du projet 09/10

2.1. Système expert

Le projet ManageYourself, entreprit l’année dernière était un projet de surveillance de plates-‐formes embarquées. Leur but était de développer une plateforme de surveillance sur des appareils de type Smartphone ou PDA, fonctionnant sous Windows mobile. L’application devait être embarquée sur l’appareil et constamment renseignée sur l’état du système afin de détecter et de remédier à n’importe quel problème du PDA.

Cette application contient un système expert. C’est la partie du logiciel qui gère l’aspect décisionnel. A partir d’une base de faits et de règles, il doit être capable de déduire des faits et d’exécuter des actions.

Un fait instancié est l’association d’un fait et de sa valeur. Par exemple la couleur du pelage d’un chat est un fait (son pelage à une couleur, mais on ne sait pas laquelle), et un fait instancié associé peut être « le pelage du chat est: roux »).

Ce système expert se devait d’être léger, afin de ne pas prendre beaucoup de ressource du Smartphone, capable de tourner constamment en tache de fond, et lancé régulièrement part le serveur. Ce système expert possède une base de connaissances, constituées de trois parties :

• D’une base de fait : données du système surveillées par l’application

• D’une base de règles

• D’un moteur d’inférence : sorte de logiciel décisionnel, capable d'utiliser des faits et des règles pour produire de nouveaux faits et exécuter des actions.

Le chainage avant fut utilisé pour ce moteur d’inférence. A partir de nos connaissances sur le système, des règles sont sélectionnées (celles donc les conditions de départ sont validées), puis appliquées. Cette méthode est réitérée jusqu'à qu’il n’y ait plus aucune règle applicable.

Ces règles sont des liens entre des conditions et des actions. Lorsque les conditions d’une règle sont validées, les actions associées sont effectuées. Par exemple, une règle pourrait être

« éteindre l’application X lorsque la mémoire est remplie à plus de tant… » Si la condition de cette règle est validée (mémoire trop remplie), l’application X est alors éteinte.

Pour simplifier la mise en œuvre, l’hypothèse a été émise que seule la partie droite de la condition pouvait comporter une valeur.

(8)

2.2. Découpage du projet

Ce projet était découpé en deux parties : Une application mobile, tournant en tache de fond sur le Smartphone, et une partie serveur (Figure 1). L’application mobile a pour objectif de surveiller le Smartphone (système expert) et de générer un rapport sur celui-‐ci. Le serveur quant à lui a pour objectif de faire de l’apprentissage de règles grâce aux rapports reçus, et d’envoyer de nouveau le système expert dans le Smartphone à chaque apprentissage. Le Smartphone est alors en mesure de suivre les règles et intervenir sur le système pour éviter certains plantages.

Système Expert Smartphone

Agir sur le systèmeSurveillance du système

Serveur

Surveillance

Génération De rapports

Inférence (faits, règles)

Application de la correction Sur demande du

serveur : Envoi des rapports

Lecture des rapports

Déduction des causes de plantage

Décision des correction à appliquer pour éviter les plantages

Envoi de la mise à jour du système

expert Règle applicable

FIGURE 1: PRESENTATION GLOBALE DU PROJET

Les rapports possédaient tous une étiquette « plantage de Windows », « plantage de l’application X », ou « aucun plantage », et des données pertinentes pour prévenir le plantage (informations sur batteries, Wifi, mémoire, etc.). Ces informations étaient collectées grâce à des librairies spécialisées.

(9)

2.3. Apprentissage

Un simulateur a été créé permettant de tester l'algorithme choisi. On lui donne des règles et il génère une quantité d'exemples voulue. Les tests se sont faits en plusieurs étapes.

Premièrement avec uniquement des données discrètes donc limitées et ensuite avec des données numériques qui complexifient les règles. Deuxièmement avec un nombre équitable de plantages et non plantages, puis réduction sensible du nombre de plantages. Ensuite avec des exemples erronés et enfin avec des règles indéterministes amenant oui ou non à un plantage. Ces différentes étapes ont permis de tester l'algorithme en se rapprochant de plus en plus d'un cas réel d'utilisation. Nous verrons par la suite les problèmes rencontrés.

2.4. Communication (Média contact)

La communication client/serveur était gérée par MediaContact, un logiciel de TELELOGOS.

Ce logiciel est composé de :

• Un logiciel MediaContact serveur.

• Une console d'administration pour gérer les communications.

• Un logiciel client à déployer sur chaque station, principalement sur les téléphones portables.

La communication se faisait en deux parties :

• L’utilisateur devait d’abord s’abonner à l’application : Celle-‐ci était installée sur le mobile.

• Dans un second temps, l’application installée est régulièrement lancée à distance, afin de récupérer des rapports, et de réinstaller l’installation modifiée par les apprentissages.

(10)

FIGURE 2: SYSTEME DE FONCTIONNEMENT DE MEDIACONTACT

3. Prérequis pour la mise en

place d’un système expert sur mobile

Il existe un certain nombre de prérequis pour pouvoir implanter un système expert sur un Smartphone.

Si ces prérequis étaient bien présents sur la plateforme Windows mobile 6.x utilisée l’année passée, la vérification de la présence de ces derniers sur Androïd et iOS est une partie intégrante de notre projet.

Nous pouvons distinguer 3 catégories de prérequis, intimement liés au principe du système expert :

• La lecture d’informations

• L’écriture d’informations

• L’intervention sur le système

(11)

Le schéma ci-‐dessous reprend les différentes actions qui se déroulent lors de l’exécution d’un système expert, et sur quel périphérique elles ont lieu. Les légendes indiquent quels sont les prérequis pour chaque étape qui concerne le Smartphone.

Partie Smartphone

Lecture d’informations

système (logs, processus, mémoire…)

Génération des

rapports Envoi sur le serveur

Partie Serveur

Appliquer les règles (tuer un processus par

exemple)

Prérequis :

·∙ Librairies permettant d’accéder aux informations

·∙ Pouvoir repérer un plantage (logs…)

·∙ ...

Prérequis :

·∙ Pouvoir écrire des fichiers sur le téléphone

Prérequis :

·∙ Pouvoir agir sur le système

·∙ Tuer des processus

·∙ ...

FIGURE 3: DEROULEMENT DE L'ACTION DU SYSTEME EXPERT

On peut voir qu’il existe trois catégories de prérequis, correspondant à trois étapes clés pour un système expert. Ainsi, dans les développements concernant l’iPhone, puis Androïd, nous reprendrons ces trois catégories, et regarderons dans quel mesure le système d’exploitation mobile répond aux prérequis.

(12)

4. iPhone

4.1. Présentation Générale

L’objectif n’est pas de répertorier les évolutions de la gamme iPhone, et des systèmes d’exploitation associés, mais bien de donner un aperçu de l’état actuel du Smartphone Apple, que ce soit d’un point de vu matériel que logiciel.

4.1.1. Côté matériel

Les derniers iDevices¹ bénéficient de caractéristiques matériel solides. Ils sont équipés d’un processeur A4 à 1 Ghz, et de 256 à 512 Mo de RAM.

4.1.2. Côté OS : l’iOS 4

L’iOS est le nom donné (depuis sa version 4) au système d’exploitation destiné aux iDevices. Nous sommes actuellement rendus à la version 4. C’est un système désormais multitâche.

L’OS est structuré en couches (Figure 4). La base est un dérivé du noyau d’OSX. Un Framework complet est mis à disposition des applications : U-‐Kit. La plupart des applications se basent sur la couche Cocoa Touch. Les couches média, et core services sont utilisées par des applications dont les besoins exigent des fonctions plus bas niveau, que ce soit pour de la 3D, ou manipuler une base de donnée par exemple.

1iDevice : Appareil mobile Apple dérivé de l’iPhone. On peut citer actuellement le trio : iPhone, iPod touch et iPad

(13)

iOS

Core OS Core Services

Media Cocoa Touch

Haut niveauBas niveau

[C] BASE de l’OS, types bas niveau, gestion des threads...

[C + Objective-‐C] Base pour la 2D, 3D, audio, vidéo, animations...

[C essentiellement] SERVICES : bonjour, sockets, SQLite...

[Objective-‐C] Infrastructure de base des applications : gestion de fichiers, réseau, + Ukit

FIGURE 4: DIFFERENTES COUCHES COMPOSANT L'IOS

La force des iDevices est les Apps. Une App est le nom donné à une application conçue pour ces derniers.

4.2. Fonctionner en tâche de fond

La première priorité pour un système expert est de pouvoir fonctionner en tâche de fond.

4.2.1. Introduction

Le multitâche sous iPhone est implémenté par un système de services.

Un service désigne en fait un type de service (au sens propre) qu’une application peut rendre. Par exemple, une application déclarant le service audio en tache de fond sera autorisée par le système à continuer à lire le flux audio, même réduite.

Concrètement, l’objectif est de définir des catégories de services rendus par l’application, et de définir les conditions d’exécution correspondant à tel ou tel service.

Le système d’exploitation gère plusieurs services :

§ Audio en tâche de fond

§ VOIP

§ Positionnement en tâche de fond

(14)

§ Notifications Push²

§ Notifications locales

§ Finir une tâche

§ Basculement rapide entre applications

Tous ces services ne permettent pas à une application d’exécuter du code en tâche de fond.

C’est un choix respectable, qui présente plusieurs avantages :

§ Les applications implémentant un ou plusieurs types de services sont bénéficient alors d’un accès au temps processeur parfaitement adapté au(x) service(s). Entre autre, les applications ne rendant pas de services inclus dans les sept, est simplement mise en pause lorsqu’elle est réduite.

Le processeur est donc moins sollicité, et l’autonomie est préservée.

§ La stabilité du système est assurée par un contrôle des possibilités offertes aux applications

Mais on peut dénoter un inconvénient majeur :

§ Une application remplissant une fonction nécessitant un fonctionnement en tâche de fond, mais qui ne correspond pas à l’un des sept services, ne sera pas autorisée.

Nous allons donc passer en revue les différents services et dresser un bilan de ce qu’ils laissent comme libertés.

4.2.2. Audio en tâche de fond

Cela permet à une application de continuer à lire une piste audio, même réduite en tâche de fond. Tant que l’application lit de la musique et qu’elle n’est pas interrompue, soit par l’utilisateur, soit par une autre application souhaitant lire de la musique, elle peut tourner en tâche de fond.

4.2.3. VOIP

Le service VOIP (voix sur IP) a été conçu pour des applications VOIP comme Skype. Cela permet de maintenir la réception d’appel, même si l’application est réduite.

Cela se fait grâce à deux mécanismes utilisés en parallèle :

2Notifications « poussées » vers le téléphone depuis un serveur

(15)

• Paramétrage des sockets pour que le système réveille l’application en cas d’appel

• Paramétrage du système pour que l’App ³soit réveillée régulièrement (minimum de 600 secondes d’intervalle, pour 30 secondes maximum d’exécution).

On voit clairement que le système impose des limitations pour éviter les abus.

4.2.4. Positionnement en tâche de fond

Permet à une application de rester informer de la position de l’iPhone. Soit en permanence, soit lorsqu’un changement a été détecté.

Comme pour l’audio, l’application est autorisée à travailler malgré la mise en arrière-‐

plan. Elle peut alors manipuler des données de localisation. C’est probablement le service le plus permissif.

4.2.5. Notifications Push

⁴

Permet à l’application de définir une alerte qui sera déclenchée, à une heure fixée par l’application. Cette alerte est enregistrée auprès d’un serveur qui se chargera de la délivrer au système. Ce dernier l’affiche à l’utilisateur, mais l’application reste donc inactive en tâche de fond.

4.2.6. Notifications locales

Permet à l’application de définir une alerte qui sera déclenchée, à une heure fixée par l’application. Cette alerte est enregistrée auprès du système qui se chargera de la délivrer.

Comme pour les notifications Push, si l’application est réduite, la notification n’entraine pas le réveil de l’application.

4.2.7. Finir une tâche

Comme son nom l’indique, cela permet à une application de terminer, en tâche de fond, une tâche commencée par l’utilisateur.

• L’application reçoit le signal lui indiquant qu’elle va passer en tâche de fond

• L’application déclare qu’elle a une tâche à terminer

3 Application pour iDevices

4 Notifications « poussées » vers le téléphone depuis un serveur

(16)

Le temps alloué pour l’achèvement de la tâche est limité, mais il est possible de l’étendre s’il ne s’avère pas suffisant.

4.2.8. Basculement rapide entre applications

C’est le service offert par défaut. Lorsque l’utilisateur réduit l’application, son exécution est suspendue, mais les données demeurent en mémoire. Cela permet à l’application d’être restaurée instantanément.

4.2.9. Solution pour permettre un fonctionnement en tâche de fond.

Aucun de ces services ne correspond aux besoins d’un système expert, à savoir rester actif en permanence, sans réaliser de service comme le positionnement ou la VOIP.

Seulement, nous envisageons la possibilité d’ « usurper » un de ces services pour dérouler notre système expert en tache de fond. Le service de positionnement semble le plus propice. Il est évident qu’une telle application ne pourra pas être à l’heure actuelle enregistrée sur l’AppStore⁵. Mais notre projet étant une étude de faisabilité, ce n’est pas un problème.

Il faut cependant noter que cette possibilité n’a pu être testée à l’heure actuelle, mais fait partie de nos priorités pour la suite des tests et recherches inhérents à un projet de test de faisabilité.

4.3. Lecture d’informations système

Comme nous l’avons vu, le système expert doit pouvoir être informé des processus en cours, informations système, des applications terminant sur une erreur…

Deux solutions complémentaires se profilent :

1. Utiliser les bibliothèques système pour récupérer des informations.

2. Lancer des commandes dans le terminal iOS (basé sur OSX), et en récupérer le résultat. C’est idéal pour être informé des processus en cours par exemple.

La lecture d’informations, bien que plus délicate que sous Androïd, n’est pas bloquante.

Des applications remplissant ce rôle sont déjà sur le marché (sans pour autant dévoiler leurs sources bien entendu). Ci-‐dessous, vous pouvez voir deux captures du programme aMonitor, qui informe l’utilisateur de l’état du système. Cependant, cette application ne fonctionne pas en tâche de fond, et n’a pas d’autre but que celui d’informer.

5 Boutique en ligne d’applications pour iDevices.

(17)

CAPTURE 1: APPLICATION TIERCE RECCEUILLANT

DES INFORMATIONS SYSTEME CAPTURE 2: APPLICATION TIERCE AFFICHANT LES PROCESSUS EN COURS

4.4. Agir sur le système et les autres applications

Ce point est plus délicat. Contrairement à ce qu’on trouve sur Androïd, aucune application ne permet de tuer un processus ou même fermer une tierce application. Aucune possibilité de ce genre n’est abordée dans la documentation du SDK iPhone.

Même si ce type de limitations fait partie des aléas d’une étude de faisabilité, nous espérons toujours pouvoir trouver une astuce.

4.5. Le système expert iOS

Nous avons pu constater que le système d’exploitation iOS, depuis sa version 4 intègre un système se montrant très efficace pour gérer les ressources. Nous avons pu découvrir et tester les fonctions suivantes de ce système :

• Demande de libération de mémoire à des applications

• Fermeture d’applications

(18)

Par exemple, un lancement d’une application A, réduite ensuite, suivi de plusieurs lancements d’applications lourdes entraine une fermeture de l’application A, et ce, sans intervention humaine.

4.6. Tests réalisés

Notre premier programme avait pour but de nous familiariser avec XCode, l’Objective-‐C et le SDK d’iOS. Le fait que nous découvrions un nouveau langage (l’Objective-‐C), qui est syntaxiquement différent de ce que nous connaissons déjà, rend la tâche plus difficile. De plus nous ne sommes pas familiers avec le développement pour iPhone.

Parallèlement, le développement pour iPhone ne se faisant que sous OSX avec l’aide de l’IDE Xcode, nous avons découvert un nouveau système d’exploitation et un environnement de développement qui nous était inconnu. Nous avons dû également gérer les formalités inhérentes au développement iPhone (enregistrement au programme de développement, licences …).

Ce programme affiche à l’écran le nom et la version du système d’exploitation du téléphone, le modèle, la quantité de mémoire totale et la quantité de mémoire libre (cf. Capture 3 et code annexe 3).

(19)

CAPTURE 3 PREMIER PROGRAMME POUR

IPHONE

Nous n’avons pas pu créer une application multitâche comme nous l’avons fait sous Android (voir partie 5.5), car le développement en multitâche (uniquement disponible sous iOS4) ne peut se faire qu’à partir de la dernière version de Xcode et du SDK iOS, uniquement disponible sous la dernière version de Mac OSX (la 10.6). Or le Mac mis à disposition par le département informatique utilise Mac OSX 10.5. Donc le développement en multitâche nous est pour l’instant impossible.

5. Android

5.1. Présentation générale

5.1.1. Côté matériel

Contrairement à l’iPhone, qui est un modèle à part entière de téléphone décliné sous plusieurs versions par Apple, il existe de nombreux types de téléphones utilisant Android. C’est pourquoi, d’un téléphone à l’autre, on peut parfois observer de grosses différences en termes de matériel.

5.1.2. Côté OS : Android

(20)

Android est un système d’exploitation pour appareils mobiles tels que Smartphones, PDA et tablettes développé par Google. Il a été conçu par Android Inc. avant d’être racheté par Google en 2005. Il a pour principaux concurrents Apple avec l’iOS, Research In Motion avec Blackberry Os et Microsoft avec Windows Mobile 7.

Android est basé sur une version modifié du noyau Linux et sous licence Apache version 2, c'est-‐à-‐dire qu’il autorise la modification et la distribution d’Android sous toute forme en maintenant le copyright lors de modification.

Android a été conçu pour une intégration optimale des applications de Google tels que Gmail, Google Maps, Youtube ou Google Agenda.

Plusieurs versions d’Android coexistent au sein des appareils mobiles. Il existe quatre versions commerciales :

• Cupcake (1.5)

• Donuts (1.6)

• Eclair (2.0/2.1)

• FroYo (2.2)

La prochaine version nommée Gingerbread est prévue pour le quatrième trimestre 2010.

Au 10 octobre 2010, 40.4% des appareils mobiles se connectant à l’Android Market étaient sous Eclair, 33.4% sous FroYo, 16.4% sous Donuts et 9.7% sous Cupcake. Le 0.1% restant étant des appareils fonctionnant sous des versions obsolètes.

5.2. Fonctionnement interne

Android est un système composé de plusieurs couches (voir Figure 5 ci-‐dessous) : le noyau, les librairies, la machine virtuelle Dalvik, le Framework, et les applications. Comme vu précédemment, le système d’exploitation est basé sur un noyau Linux. Celui-‐ci est chargé, à l’aide de ses pilotes de communiquer avec les différents périphériques du téléphone (Caméra/Ecran/Clavier/…). Ce système exécute également les fonctions de certaines bibliothèques telles qu’OpenGL, SSL, ou encore SQLite.

(21)

FIGURE 5: ORGANISATION DU SYSTEME ANDROÏD

Mais la partie la plus importante dans un système Android est celle gérant les machines virtuelles. En effet, les applications à destination de ce système ne sont pas directement compilées en langage machine mais en un bytecode qui est lu et interprété par des machines virtuelles : les Dalvik Virtual Machines. Celles-‐ci se serviront des bibliothèques noyaux pour communiquer avec le système. Une chose à noter sur ce type de système est que chaque processus est exécuté sur une machine virtuelle différente, ce qui permet une sécurité accrue, en empêchant les applications d’interférer de façon nuisible avec les autres processus.

Le SDK Android utilise du code Java, celui-‐ci étant très lié au fonctionnement d’Android, puisqu’il se base également sur du bytecode et des machines virtuelles (qui ne sont toutefois pas gérées de la même façon, celles de Java utilisant une approche par pile, tandis que celles d’Android utilisent une approche par registres).

Une fois compilé, le SDK génère un fichier .apk qui est un package contenant le bytecode et d’autres informations sur le programme. Ces dernières contiennent par exemple le nom de celui-‐ci, les versions d’Android sur lesquelles il est censé fonctionner, mais plus important, ses permissions d’accès. Lors du développement le programmeur doit en effet déclarer dans un fichier xml à quoi peut avoir accès le programme en choisissant dans une liste de permissions détaillées dans la documentation du SDK. Celles-‐ci seront affichées à l’utilisateur lors de

(22)

l’installation du package sur son téléphone, l’informant sur les données auxquelles l’application qu’il souhaite installer aura le droit d’accéder. Si une permission n’est pas déclarée mais que le programme tente malgré tout d’utiliser une fonction la nécessitant, la machine virtuelle refusera alors de poursuivre son exécution.

5.2.1. Développement sous Android

Nous allons nous intéresser aux moyens de développement mis à disposition et les différentes possibilités qu’ils nous offrent.

Le SDK (Software Development Kit)

Google fournit pour le développement d’applications pour Android un nombre important d’outils. Ceci inclus un SDK comportant l’Android SDK qui va permettre de compiler les fichiers sources, un Native Development Kit (NDK) pour optimiser une partie du code, le AVD Manager qui nous permet de créer des téléphones virtuels, d’émuler un système Android et d’exécuter les applications développées, un plugin pour l’environnement de développement Eclipse, un debugger, une documentation assez fournis et des tutoriels. Ce SDK peut être utilisé sous différents systèmes d’exploitation tels que Windows, Linux et MacOS.

Le SDK permet de développer des applications en Java. On peut aussi développer des parties qui nécessitent une optimisation en C ou C++ grâce au NDK.

Chaque version d’Android ont leurs spécificités, tant par les méthodes ou classes à utiliser que par les services qu’elles proposent. Ainsi pour rendre compatible une application à toutes les versions d’Android, il faudra spécifier des parties de code pour chaque version.

Google proposant un plugin pour Eclipse, l’Android Development Tool (ADT), pour faciliter le développement d’application Android, nous nous sommes orientés vers l’utilisation d’Eclipse pour développer nos premières applications pour Android.

5.3. Fonctionner en tâche de fond

Activity et Service sont les deux classes de base utilisées pour développer des applications Android. Une Activity est ainsi définie dans la documentation du SDK comme une chose sur laquelle peut se concentrer l’utilisateur, dans la pratique, on peut par exemple spécifier un écran ou une fenêtre d’une application comme étant une Activity. On peut ainsi en utiliser pour créer une interface étant une Activity, composée d’autres objets (boutons, textes,

(23)

image, …) avec laquelle peut interagir l’utilisateur. Lorsque l’on souhaite changer d’Activity (par exemple pour passer d’une fenêtre à une autre), l’Activity courante est mise en arrière-‐plan par le système en attendant d’être rappelée par l’usager. En contrepartie, une Activity en arrière-‐

plan peut être détruite par le système si ce dernier nécessite des ressources supplémentaires.

C’est pour cette raison que les applications Android ne possèdent pas, pour la plupart, de méthode « quitter », laissant au système le soin de s’occuper de cela.

Les Services fonctionnent sur le même principe que les Activity, à la différence près qu’ils ne sont pas créés avec pour but d’interagir directement avec l’utilisateur. Ils ont alors pour tâche d’exécuter par exemple des opérations longues en arrière-‐plan, d’effectuer des actions à des horaires spécifiques, ou encore de fournir d’autres fonctionnalités à certaines applications. On peut également informer le système qu’il ne devra pas arrêter ce service afin de libérer de la mémoire.

Un Service semble donc la meilleure solution pour effectuer une surveillance du système sans qu’il y ait besoin d’une intervention de la part de l’utilisateur du téléphone.

5.4. Lecture d’informations système

En termes de données accessibles, Android est un système assez ouvert. On peut ainsi accéder à l’état des divers composants du téléphone (batterie, réseaux, etc.) sans que cela ne pose de problèmes. Pour certains, certaines permissions (comme expliqué précédemment) sont requises, mais tout cela étant documenté dans le SDK, la recherche d’informations se fait facilement. Agir sur le système et les autres applications

Les interventions sur le système peuvent quant à elle être plus restrictives. Pour certaines (pouvant nuire à l’appareil, des droits root (administrateur) sont nécessaires, ce qui n’est pas le cas par défaut. En revanche, peu d’applications nécessitent réellement ces droits, les pratiques les plus courantes (manipulation des processus entre autre) étant autorisées pour un utilisateur normal. On peut ainsi créer sans aucun problème un logiciel permettant de gérer les processus en cours et pouvant les lister, les stopper, etc… .

Il est également possible d’exécuter directement des lignes de commandes depuis un programme, permettant ainsi l’accès à des utilitaires de base présents sur le système. Pour notre étude, nous avons ainsi pu utiliser le programme « logcat », qui centralise tous les logs du système. Il a alors été possible de récupérer des Exceptions levées par les diverses machines virtuelles, et de notifier l’utilisateur pour certaines d’entre elles.

(24)

Ces points ont été testés et vérifiés par deux applications test que nous avons développé.

Elles sont présentées en 5.6 (Tests réalisés).

5.5. Le système expert d’Android

Comme vu précédemment, et de la même façon que pour l’iOS, Android intègre un système expert. Celui-‐ci se charge de la gestion des applications en cours afin de pouvoir libérer de la mémoire lorsque cela est nécessaire.

5.6. Tests réalisés

5.6.1. Lecture d’informations système

Pour confirmer cela, nous avons développé une application simpliste listant diverses propriétés du téléphone (Capture 4).

CAPTURE 4 : EXEMPLE DE DONNEES RECUPERABLES SUR ANDROID

5.6.2. Lecture de logs

(25)

Nous avons alors créé une application Android lançant un service en arrière-‐plan, récupérant la sortie de logcat afin de capturer certaines Exceptions. Comme montré dans les captures d’écran ci-‐dessous, on lance tout d’abord la surveillance via une fenêtre composée de deux boutons (Capture 55). La confirmation de l’exécution du service est alors affichée dans la zone de notification du système (Capture 66). Dans la capture d’écran suivante, une autre application est lancée, cette dernière tentant d’accéder à un objet n’existant pas et provoquant donc une exception de type NullPointerException (Capture 77). L’erreur est alors récupérée par le service, qui le signale dans la zone de notification (Capture 88).

CAPTURE 5 : FENETRE DE LANCEMENT DU

SERVICE

CAPTURE 6 : NOTIFICATION DE L’EXECUTION DU

SERVICE

(26)

CAPTURE 7 : LANCEMENT D’UNE APPLICATION

PROVOQUANT UNE EXCEPTION

CAPTURE 8 : NOTIFICATION DE LA CAPTURE DE

L’EXCEPTION

6. Apprentissage

6.1. Introduction

L'apprentissage se fait grâce à des machines learning qui ont pour but de trouver des motifs, relations entre des données. L'apprentissage se fait sur un ensemble de données plus ou moins grand.

La plupart du temps les ensembles de données sont organisés en individus qui possèdent différent attributs.

Mémoire appliA appliB Batterie Plantage

normale lancée lancée faible oui

normale nonLancée lancée normale non

(27)

saturer nonLancée nonLancée normale non

saturer lancée nonLancée faible oui

Il existe de nombreuses machines learning : arbre de décision, règle de classification, règle d'association, cluster.... Chacune d’entre elle ont leurs avantages et leurs inconvénients.

Elles permettent aussi de faire face à différents problèmes notamment ceux liés aux individus qui peuvent être incomplets (attribut vide) ou erronés (bruit).

Comme cela a été dit précédemment notre but est de trouver des règles qui amènent à un plantage total ou partiel du mobile. Elles seront créées à partir des rapports envoyés par le téléphone. Ces rapports sont récupérés sur un serveur ou s’effectue lors de l’apprentissage.

Serveur

Apprentissage

Script Concaténation

Convertisseur bin -‐> rep

Système Mobile

Interface Administration

Base de règles

Actions InferenceEngin

e.dll SE

Compilateur mrf -‐

> cs

Compilateur C#

Media Contact Report.bin

Report.rep Report.arff

NewRules.appr

newRule.mrf

RuleBase.cs

RuleBase.exe

FIGURE 6 : ORGANISATION COTE SERVEUR

Ci-‐dessus un diagramme montrant l’organisation du serveur de l’année dernière. Le serveur récupère les rapports et les réécrit en format lisible pour weka. Après traitement un

(28)

administrateur décide des actions à effectuer selon les règles. L’ensemble est recompilé et expédié sur le mobile. Dans un souci de simplicité et de généricité, nous envisageons cette année, la possibilité d’envoyer les règles sous format générique type xml. Cela rend le serveur indépendant de la plateforme sur laquelle tourne le système expert.

6.2. Outils

Comme l'année dernière les outils seront la librairie Java Weka où sont implémentés de nombreuses Machine Learning et le simulateur d'exemple évoqué précédemment qu’il faudra adapter à nos exigences. La partie serveur sera donc implémentée principalement en Java.

6.3. Année précédente

L’année dernière le choix s’est porté sur un algorithme de type arbre de décision.

Ce type a pour but de classer les individus selon un attribut cible. Dans notre cas c’est le fait que le mobile oui ou non planté. Les nœuds de l’arbre correspondent à des choix sur les autres attributs, ils mènent aux feuilles qui sont le résultat sur l’attribut cible.

Arbre possible sur notre exemple avec plantage en attribut cible : Mémoire appliA appliB Batterie Plantage

normale lancée lancée faible oui

normale nonLancée lancée normale non saturer nonLancée nonLancée normale non saturer lancée nonLancée faible oui

Mémoire

Appli A batterie

normale saturée

Plantage oui Plantage non Plantage oui Plantage non

lancée nonLancée faible normale

FIGURE 7: ARBRE POSSINLE

(29)

Comme vous pouvez le remarquez sur le schéma ci-‐dessus, un homme peut directement interpréter les résultats, les arbres peuvent aussi être écrit sous forme de règles.

Si Mémoire==normale Si appliA==lancée

Plantage=oui Sinon Si appliA==nonLancée

Plantage=non Fin si

Sinon Si Mémoire==saturée Si batterie==faible

Plantage=oui Sinon Si batterie==normale

Plantage=non Fin si

Fin si

Cependant lors des tests évoqués précédemment différents problèmes sont apparus notamment la taille de l'arbre qui a explosé lors du test avec des règles indéterministes. L’arbre perd alors tous sont intérêt car illisible et difficile à exploiter.

FIGURE 8 REGLES GENEREES AVEC INDETERMINISME

Un autre problème apparait lorsque l’on veut rajouter un attribut : tous les exemples générés avant l’ajout ne sont plus exploitables. Au mieux on peut les réécrire pour qu’ils

(30)

prennent en compte cet attribut avec une valeur par défaut mais cette solution n’est pas rigoureuse. Il faut donc gérer des individus incomplets avec des attributs indéterminés.

6.4. Cette année

Cette année a donc pour but de trouver une machine learning plus itérative et acceptant mieux l'arrivée de nouveaux attributs. Ceci est indispensable car cela correspondra généralement à une nouvelle application installée sur le mobile, ce qui arrivera forcement. La partie pré-‐étude va donc se poursuivre le temps que l’on trouve un algorithme correspondant à nos attentes. D’autant plus qu’aucun d’entre nous n’a de base dans ce domaine. Cependant quelques pistes sont en vue comme l'utilisation de règles de classification ou d'association.

7. Outils de développement

Nous avons répertorié les principaux outils de développement que nous pensons utiliser grâce à leur avantage multiplateforme, ou encore les différents langages supportés. Bien entendu tous les outils énoncés par la suite ne seront pas obligatoirement utilisés dans notre projet.

7.1. Eclipse

Eclipse est un environnement de développement intégré libre et polyvalent. En effet, il permet de créer des projets dans n’importe quel langage de programmation. Eclipse est conçu autour de la notion de plugin. Les fonctionnalités permettant de développer dans un langage donné vont être apportées par un plugin. Ainsi grâce à l’ADT plugin nous allons pouvoir développer des applications pour Android et lancer l’exécution à partir d’Eclipse. Tout comme le SDK d’Android, Eclipse est multiplateforme et est disponible sous Windows, Linux et MacOS.

7.2. Xcode

Xcode est un environnement de développement pour Mac OS X développé par Apple. Il possède deux API de programmation, Carbon qui permet de programmer en C et C++, et Cocoa qui permet de programmer en Objective-‐C, AppleScript et Java. Pour notre étude nous

(31)

retiendrons bien entendu l’API Cocoa pour compiler notre application native iPhone en Objective-‐C.

Cette plateforme de développement n’est disponible que pour MacOSX.

7.3. Appcelerator Titanium

Les langages de programmation pour l’iPhone et pour Androïd sont différents. Il en va de même pour les environnements de développement. Ainsi, il nous a paru intéressant de faire des recherches sur un moyen de programmer pour les deux plateformes simultanément. C’est ainsi que nous avons expérimenté la plateforme Appcelerator Titanium.

Appcelerator Titanium est une plateforme libre, développée par Appcelerator Inc., pour développer des applications mobiles et de bureau en utilisant des technologies web. Les applications peuvent être développées nativement pour l’iOS de l’iPhone, ou bien encore pour le système Android. Cette plateforme comporte plusieurs versions, une pour Linux, une pour Windows et enfin une pour Mac.

Appcelerator Titanium comporte de multiples avantages pour le développement d’applications mobiles. Les technologies supportées pour coder les applications mobiles peuvent être HTML, CSS et JavaScript. La plateforme joue un rôle de compilateur pouvant aboutir à de l’Objective-‐C pour les applications iPhone, et Java pour Android. De plus Appcelerator Titanium possède de multiples bibliothèques spécifiques au langage cible. Par exemple certaines nous donnent des informations sur le système, à savoir les processus en marchent, la mémoire utilisée, etc. L’avantage étant que l’on peut obtenir une même application sur iPhone et Android en générant un code avec peu de différences. Enfin la plateforme intègre des émulateurs de systèmes iOS et Android pour pouvoir tester les applications sans avoir obligatoirement la machine concernée à disposition.

Une application test a été développée sous Titanium. Elle permet la lecture d’informations système (Capture 9). Son code est disponible en annexe.

(32)

CAPTURE 9 : APPLICATION DE LECTURE DES INFORMATIONS SYSTEMES DEVELOPPEE SOUS TITANIUM

Cependant, malgré les multiples avantages de Titanium, un problème survient : celui du SDK iPhone. En effet ce dernier, payant, n'est disponible que sous MacOS. Nous pouvons donc nous poser la question quant à l'utilité de la plateforme Titanium pour notre projet et si nous l'utiliserons par la suite. De plus, Titanium permet de créer des applications native pour iPhone et Android, mais cependant ne permet pas de créer d'application Windows Mobile. Malgré le fait que ceci ne corresponde pas à notre projet, cela pourrait être intéressant. Mais envisager cette possibilité rend l'utilisation de Titanium un peu plus restrictive.

8. Plannification

Nom de la tâche Durée Début Fin

Apprentissage : Continuation de la pré-‐étude 20 jours Jeu 21/10/10 Mer 17/11/10 Apprentissage : WEKA : prise en main &

algorithmes 10 jours Jeu 18/11/10 Mer 01/12/10

Apprentissage : Application au projet 43 jours Jeu 02/12/10 Lun 31/01/11

(33)

Tests iPhone 10 jours Jeu 04/11/10 Mer 17/11/10 Installation Snow Leopard, Xcode… 10 jours Jeu 21/10/10 Mer 03/11/10 iPhone : spécification & Faisabilité 7 jours Jeu 18/11/10 Ven 26/11/10

Réflexion & tests autours de la généricité (Titanium, machine virtuelle, fichier de règles générique…)

15 jours Jeu 21/10/10 Mer 10/11/10

Android : spécification & faisabilité 7 jours Jeu 11/11/10 Ven 19/11/10

Serveur : spécification (cas d'utilisation, fichier entrée, fichier sortie apprentissage, fichier sortie actions génériques)

10 jours Jeu 11/11/10 Mer 24/11/10

Conception 46 jours Lun 29/11/10 Lun 31/01/11

Développement 65 jours Mar 01/02/11 Lun 02/05/11

Tests 10 jours Mar 03/05/11 Lun 16/05/11

(34)

(35)

9. Conclusion

Nous avons pu prendre connaissance, de façon approfondie, du travail réalisé par les étudiants de l’année passée, d’en comprendre les tenants et les aboutissants, orientant ainsi nos recherches sur les deux systèmes iOS et Android. Nous avons ainsi pu découvrir et analyser les principes et le fonctionnement de ces deux systèmes, mais aussi tester des moyens pour développer de façon plus ou moins unifiée sur les deux plateformes (Appcelerator TItanium).

L’aspect apprentissage constituait un point important de la pré-‐étude.

Malgré les progrès et découvertes réalisés, des interrogations subsistent encore sur la faisabilité du projet sur l’iPhone avec sa conception différente du multitâche. De la même façon, au fur et à mesure de nos découvertes, de nouvelles voies de recherche s’ouvrent à nous. Les études de faisabilité impliquent intrinsèquement une répartition du temps plus axée sur la recherche et l’expérimentation. Il est ainsi évident que d’autres découvertes, et recherches font partie intégrante de nos prochains objectifs, au même titre que la spécification logicielle.

(36)

10. Bibliographie

1. iPuP. Programmez pour iPhone, iPod Touch, iPad avec iOS4. s.l. : Pearson, 2010.

2. Appcelerator, Inc. Appcelerator. [En ligne] [Citation : 21 10 2010.]

http://www.appcelerator.com/.

3. Xsysinfo -‐ Display bar graphs of system load. Linux Software Directory. [En ligne]

[Citation : 27 Septembre 2010.] http://linux.maruhn.com/sec/xsysinfo.html.

4. WITTEN, Ian H. et FRANK, Eibe. Data Mining. s.l. : Morgan Kaufmann, 2005.

5. McEntire, Norman. How to use iPhone with Unix System and Library Calls : A Tutorial for Software Developers. How to use iPhone with Unix System and Library Calls. [En ligne] 18 Janvier 2009. [Citation : 27 09 2010.] http://www.servin.com/iphone/iPhone-‐Unix-‐

System-‐Calls.html.

6. Guy, Romain. Painless threading. Android Developers. [En ligne] 2009.

http://android-‐developers.blogspot.com/2009/05/painless-‐threading.html.

7. Collins, Charlie. Android Application and AsyncTask basics. [En ligne] 2010.

http://www.screaming-‐penguin.com/node/7746.

8. Apple Inc. iOS Reference Library. [En ligne] 2010.

http://developer.apple.com/library/ios/navigation/.

9. Google. Android SDK. [En ligne] 2010.

http://developer.android.com/sdk/index.html.

Système Expert pour Smartphones