Embed Size (px)
Citation preview
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é
1 | P a g e
TABLE 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:52Commentaire [1]: NE PAS OUBLIER DE METTRE A JOUR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2 | P a g e
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
3 | P a g e
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:25Commentaire [2]: Ca va mieux comme ca?
Hurlebibi� 19/10/10 14:30Commentaire [3]: Pas sure que la modif soit mieux que l’original.
4 | P a g e
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.
5 | P a g e
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é.
6 | P a g e
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.
7 | P a g e
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ème
Surveillance du
système
Serveur
Surveillance
GénérationDe 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
expertRè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.
8 | P a g e
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.
9 | P a g e
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
10 | P a g e
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.
11 | P a g e
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 iDevices1 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
12 | P a g e
iOS
Core OS
Core Services
Media
Cocoa TouchHa
ut niveau
Bas n
iveau
[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
13 | P a g e
§ Notifications Push2
§ 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
14 | P a g e
• 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 3soit 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 Push4
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
15 | P a g e
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’AppStore5. 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.
16 | P a g e
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
17 | P a g e
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).
18 | P a g e
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
19 | P a g e
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.
20 | P a g e
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
21 | P a g e
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,
22 | P a g e
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.
23 | P a g e
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
24 | P a g e
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
25 | P a g e
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
26 | P a g e
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 InferenceEngine.dllSE
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
27 | P a g e
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
28 | P a g e
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
29 | P a g e
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
30 | P a g e
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.
31 | P a g e
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
32 | P a g e
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
33 | P a g e
34 | P a g e
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.
35 | P a g e
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. Coll ins, 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.
36 | P a g e
11. Annexes
11.1. Annexe : Exemple de récupération
d’informations sous Android Cette application affiche une liste d’informations récupérées à propos du système
(Modèle du téléphone, version du SDK, mémoire disponible, services en cours, …).
MainActivity . java
package com.TestProjetInsa1; import java.util.ArrayList; import java.util.List; import android.app.ActivityManager; import android.app.ListActivity; import android.content.Context; import android.net.ConnectivityManager; import android.net.NetworkInfo; import android.os.Bundle; import android.widget.ArrayAdapter; import android.widget.ListAdapter; publicclass MainActivity extends ListActivity { ArrayList<String> values; /** * Création de l'Activity */ @Override publicvoid onCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); values =new ArrayList<String>(); ListAdapter adapter = createAdapter(values); setListAdapter(adapter); addValues(); } /** * Ajout des valeurs à lister */ protectedvoid addValues(){ values.add("Manufacturer = "+android.os.Build.MANUFACTURER); values.add("Model = "+android.os.Build.MODEL); values.add("Product = "+android.os.Build.PRODUCT); ConnectivityManager cManager
=(ConnectivityManager)this.getBaseContext().getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo[] networkinfo = cManager.getAllNetworkInfo();
37 | P a g e
for(int i=0; i<networkinfo.length; i++){ values.add(networkinfo[i].getTypeName()+" :
"+networkinfo[i].getState()); } ActivityManager activityManager
=(ActivityManager)this.getSystemService( ACTIVITY_SERVICE); ActivityManager.MemoryInfo mInfo =new ActivityManager.MemoryInfo(); activityManager.getMemoryInfo( mInfo ); values.add("Memoire disponible = "+mInfo.availMem+" octets"); List<ActivityManager.RunningServiceInfo> servicelist =
activityManager.getRunningServices(100); for(ActivityManager.RunningServiceInfo serviceinfo : servicelist){ values.add("Service : "+serviceinfo.process); } } /** * Création de l'adapter */ protected ListAdapter createAdapter(ArrayList<String> list) { ListAdapter adapter =new ArrayAdapter<String>(this,
android.R.layout.simple_list_item_1, list); return adapter; } }
38 | P a g e
11.2. Annexe : Application de lecture des logs
sous Android Exemple d’application lançant un service chargé de signaler lorsqu’un processus lève
une exception de type RuntimeException.
MainActivity . java :
package com.projetinsa2; import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.view.View; import android.widget.Button; /** * Activity principale * @author Vincent Le Biannic * */ publicclass MainActivity extends Activity { Intent serviceIntent =null; /** * Lancement de l'Activity */ @Override publicvoid onCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); setContentView(R.layout.main); /** * Récupération des deux boutons du layout */ final Button startbutton =(Button) findViewById(R.id.startbutton); final Button stopbutton =(Button) findViewById(R.id.stopbutton); serviceIntent =new Intent(); serviceIntent.setAction("com.projetinsa2.WATCHER_SERVICE"); /** * Listener du bouton "Start" * On y lance le Service chargée de la lecture des logs */ startbutton.setOnClickListener(new View.OnClickListener(){ publicvoid onClick(View v){ startService(serviceIntent); } }); /** * Listener du bouton "Stop" * Arrêt du service de lecture des logs */ stopbutton.setOnClickListener(new View.OnClickListener(){ publicvoid onClick(View v){ stopService(serviceIntent); } });
39 | P a g e
} }
WatcherService.java :
package com.projetinsa2; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.util.List; import java.util.regex.Matcher; import java.util.regex.Pattern; import android.app.ActivityManager; import android.app.Notification; import android.app.NotificationManager; import android.app.PendingIntent; import android.app.Service; import android.app.ActivityManager.RunningAppProcessInfo; import android.content.Intent; import android.os.AsyncTask; import android.os.IBinder; import android.util.Log; import android.widget.Toast; /** * Service de monitoring * @author Vincent Le Biannic * */ publicclass WatcherService extends Service { private WatcherTask watcher =null; private NotificationManager mNM; @Override public IBinder onBind(Intent arg0){ returnnull; } /** * Lancement du Service */ @Override publicvoid onCreate(){ super.onCreate(); mNM
=(NotificationManager)getSystemService(NOTIFICATION_SERVICE); // Affichage d'une notification durant toute l'execution du
service CharSequence text ="Service en cours d'execution"; Notification notification =new Notification(R.drawable.icon,
text, System.currentTimeMillis()); PendingIntent contentIntent = PendingIntent.getActivity(this,0, new Intent(this, MainActivity.class),0); notification.setLatestEventInfo(this,"Log Watcher", text, contentIntent); this.startForeground(R.drawable.icon, notification);
Toast.makeText(this,"Lancement du monitoring", Toast.LENGTH_LONG).show();
if(watcher ==null){ watcher =new WatcherTask();
40 | P a g e
if(watcher.getStatus()!= AsyncTask.Status.RUNNING){ watcher.execute((Void)null); } } } /** * Arret du Service */ @Override publicvoid onDestroy(){ super.onDestroy(); Toast.makeText(this,"Arret du monitoring",
Toast.LENGTH_LONG).show(); if(watcher !=null){ if(watcher.getStatus()== AsyncTask.Status.RUNNING){ watcher.cancel(true); } } } /** * Affiche une notification avec le numero de l'erreur ainsi que le * nom et pid du processus ayant provoqué l'erreur. * ! * @param processName Chaine content le nom et le pid du processus */ publicvoid showNotif(int nb, String processName){ CharSequence text ="RuntimeError n°"+nb+" : "+processName; Notification notification =new Notification(R.drawable.icon,
text, System.currentTimeMillis()); PendingIntent contentIntent = PendingIntent.getActivity(this,0, new Intent(this, MainActivity.class),0); notification.setLatestEventInfo(this,"Log Watcher", text, contentIntent); // Envoi de la notification mNM.notify(R.layout.main, notification); } /** * Tâche qui sera exécutée dans un autre thread * @author Vincent Le Biannic * */ privateclass WatcherTask extends AsyncTask<Void, Void, Void>{ Process process =null; @Override protectedvoid onPreExecute(){ Log.d("LOGTEST","Starting monitoring"); } @Override protected Void doInBackground(Void... params){ int i =1; try{ // Efface le cache
41 | P a g e
process = Runtime.getRuntime().exec("logcat -c"); process.waitFor(); // Lance logcat en filtrant les erreurs process = Runtime.getRuntime().exec("logcat");//
*:E"); BufferedReader bufferedReader =new
BufferedReader(new InputStreamReader(process.getInputStream())); String line; while((line = bufferedReader.readLine())!=null){
// Regex : "E/AndroidRuntime ( <PID>): java.lang.RuntimeException..."
// Le PID sera dans le groupe n°1 Pattern pattern = Pattern.compile("E/AndroidRuntime\\(\\s*(\\d+?)\\): java\\.lang\\.RuntimeException.*");
Matcher matcher = pattern.matcher(line); if(matcher.matches()&&
matcher.groupCount()==1){ Log.d("LOGTEST", line); String processName ="Undefined"; int pid =
Integer.valueOf(matcher.group(1)); // Parcours de la liste des processus
en // cours pour trouver celui
// qui correspond au PID ayant provoqué
// l'erreur. ActivityManager activityManager
=(ActivityManager)WatcherService.this.getBaseContext().getSystemService(ACTIVITY_SERVICE);
List<RunningAppProcessInfo> pInfo = activityManager.getRunningAppProcesses();
for(RunningAppProcessInfo current : pInfo){
if(current.pid == pid) processName =
current.processName; } // Affichage de la notification showNotif(i, processName+"
("+pid+")"); i++; } } Log.d("LOGTEST","End of monitoring"); }catch(IOException e){ Log.e("LOGTEST","Erreur de lecture des logs !"); }catch(SecurityException e){ Log.e("LOGTEST","Monitoring non autorisé!"); }catch(InterruptedException e){ e.printStackTrace(); } returnnull; } @Override protectedvoid onPostExecute(Void v){
42 | P a g e
watcher =null; process =null; } @Override protectedvoid onCancelled(){ if(process !=null){ // Fin du processus process.destroy(); process =null; } watcher =null; } } }
43 | P a g e
11.3. Annexe : Application de lecture des
informations système réalisée sous
Titanium // this sets the background color of the master UIView (when there are no
windows/tab groups on it) Titanium.UI.setBackgroundColor('#000'); // create tab group var tabGroup = Titanium.UI.createTabGroup(); // System Informations var osName = Titanium.Platform.osname; var osType = Titanium.Platform.ostype; var avMem = Titanium.Platform.availableMemory; var batLvl = Titanium.Platform.batteryLevel; var macAdr = Titanium.Platform.macaddress; var model = Titanium.Platform.model; var nbUc = Titanium.Platform.processorCount; // // create base UI tab and root window // var win1 = Titanium.UI.createWindow({ title:'Tab 1', backgroundColor:'#fff' }); var tab1 = Titanium.UI.createTab({ icon:'ROG_Blanc.png', title:'System Informations', window:win1 }); var label1 = Titanium.UI.createLabel({ color:'#000', text:'OS : '+osName +'\n' +'Type : '+osType+'\n' +'Memoire : '+avMem+' Bits\n' +'Batterie : '+batLvl+'% \n' +'Mac : '+macAdr+'\n' +'Modele : '+model+'\n' +'Nombre de CPU : '+nbUc, font:{fontSize:14,fontFamily:'Helvetica Neue'}, textAlign:'left', width:'auto' }); win1.add(label1); // // add tabs // tabGroup.addTab(tab1); tabGroup.open();
44 | P a g e
11.4. Annexe : Premier Programme sur iPhone
// // HelloWorldViewController.h // HelloWorld // // Created by ManageYourself on 18/10/10. // Copyright __MyCompanyName__ 2010. All rights reserved. // #import <UIKit/UIKit.h> //#import <UIDevice.h> @interface HelloWorldViewController : UIViewController { UILabel *monLabel; UILabel *myLabelName; //Label pour afficher le nom de l'OS UILabel *myLabelVersion; //Label pour afficher la version de l'OS UILabel *myLabelModel; UILabel *myLabelAMem; UILabel *myLabelTMem; UILabel *myLabelAvailableMem; UILabel *myLabelTotalMem; NSString *systemName; //String qui va contenir le nom de l'OS NSString *systemVersion; //String qui va contenir la version de l'OS NSString *phoneModel; NSString *aMem; NSString *tMem; } @property (nonatomic, retain) UILabel *monLabel; @property (nonatomic, retain) UILabel *myLabelName; @property (nonatomic, retain) UILabel *myLabelVersion; @property (nonatomic, retain) UILabel *myLabelModel; @property (nonatomic, retain) UILabel *myLabelAMem; @property (nonatomic, retain) UILabel *myLabelTMem; @property (nonatomic, retain) UILabel *myLabelTotalMem; @property (nonatomic, retain) UILabel *myLabelAvailableMem; @property(nonatomic,retain) NSString *aMem; @property(nonatomic,retain) NSString *tMem; @property (nonatomic, readonly, retain) NSString *systemName; @property (nonatomic, readonly, retain) NSString *systemVersion; @property (nonatomic, readonly, retain) NSString *phoneModel; @end
45 | P a g e
// // HelloWorldViewController.m // HelloWorld // // Created by ManageYourself on 18/10/10. // Copyright __MyCompanyName__ 2010. All rights reserved. // #import "HelloWorldViewController.h" #import <mach/mach.h> #import <mach/mach_host.h> @implementation HelloWorldViewController @synthesize monLabel; @synthesize myLabelName; @synthesize myLabelVersion; @synthesize myLabelModel; @synthesize myLabelAMem; @synthesize myLabelTMem; @synthesize myLabelAvailableMem; @synthesize myLabelTotalMem; @synthesize aMem; @synthesize tMem; @synthesize systemName; @synthesize systemVersion; @synthesize phoneModel; /* // The designated initializer. Override to perform setup that is required before the view is loaded. -‐ (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil { if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) { // Custom initialization } return self; } */ natural_t freeMemory(void) { mach_port_t host_port = mach_host_self(); mach_msg_type_number_t host_size = sizeof(vm_statistics_data_t) / sizeof(integer_t); vm_size_t pagesize; vm_statistics_data_t vm_stat; host_page_size(host_port, &pagesize);
46 | P a g e
if (host_statistics(host_port, HOST_VM_INFO, (host_info_t)&vm_stat, &host_size) != KERN_SUCCESS) NSLog(@"Failed to fetch vm statistics"); //natural_t mem_used = (vm_stat.active_count + vm_stat.inactive_count + vm_stat.wire_count) * pagesize; natural_t mem_free = vm_stat.free_count * pagesize; //natural_t mem_total = mem_used + mem_free; return mem_free; } natural_t totalMemory(void) { mach_port_t host_port = mach_host_self(); mach_msg_type_number_t host_size = sizeof(vm_statistics_data_t) / sizeof(integer_t); vm_size_t pagesize; vm_statistics_data_t vm_stat; host_page_size(host_port, &pagesize); if (host_statistics(host_port, HOST_VM_INFO, (host_info_t)&vm_stat, &host_size) != KERN_SUCCESS) NSLog(@"Failed to fetch vm statistics"); natural_t mem_used = (vm_stat.active_count + vm_stat.inactive_count + vm_stat.wire_count) * pagesize; natural_t mem_free = vm_stat.free_count * pagesize; natural_t mem_total = mem_used + mem_free; return mem_total; } // Implement loadView to create a view hierarchy programmatically, without using a nib. -‐ (void)loadView { //Creation de notre vue principale qui occupera la taille de l'écran CGRect mainFrame = [[UIScreen mainScreen] applicationFrame]; UIView *contentView = [[UIView alloc] initWithFrame:mainFrame]; contentView.backgroundColor = [UIColor groupTableViewBackgroundColor]; self.view = contentView; [contentView release]; //Positionnement et initialisation des Labels sur l'écran monLabel = [[UILabel alloc] initWithFrame:CGRectMake(10,10,mainFrame.size.width -‐ 20, 40)]; monLabel.backgroundColor = [UIColor clearColor]; monLabel.textColor = [UIColor blackColor]; [monLabel setTextAlignment:UITextAlignmentCenter]; monLabel.text = @"OS :"; myLabelName = [[UILabel alloc] initWithFrame:CGRectMake(10,30,mainFrame.size.width -‐20,40)]; myLabelName.backgroundColor = [UIColor clearColor]; myLabelName.textColor = [UIColor blackColor]; [myLabelName setTextAlignment:UITextAlignmentCenter];
47 | P a g e
myLabelVersion = [[UILabel alloc] initWithFrame:CGRectMake(10,50,mainFrame.size.width -‐20,40)]; myLabelVersion.backgroundColor = [UIColor clearColor]; myLabelVersion.textColor = [UIColor blackColor]; [myLabelVersion setTextAlignment:UITextAlignmentCenter]; myLabelModel = [[UILabel alloc] initWithFrame:CGRectMake(10,70,mainFrame.size.width -‐20,40)]; myLabelModel.backgroundColor = [UIColor clearColor]; myLabelModel.textColor = [UIColor blackColor]; [myLabelModel setTextAlignment:UITextAlignmentCenter]; myLabelTotalMem = [[UILabel alloc] initWithFrame:CGRectMake(10,90,mainFrame.size.width -‐20,40)]; myLabelTotalMem.backgroundColor = [UIColor clearColor]; myLabelTotalMem.textColor = [UIColor blackColor]; [myLabelTotalMem setTextAlignment:UITextAlignmentCenter]; myLabelTotalMem.text = @"Memoire totale :"; myLabelTMem = [[UILabel alloc] initWithFrame:CGRectMake(10,110,mainFrame.size.width -‐20,40)]; myLabelTMem.backgroundColor = [UIColor clearColor]; myLabelTMem.textColor = [UIColor blackColor]; [myLabelTMem setTextAlignment:UITextAlignmentCenter]; myLabelAvailableMem = [[UILabel alloc] initWithFrame:CGRectMake(10,130,mainFrame.size.width -‐20,40)]; myLabelAvailableMem.backgroundColor = [UIColor clearColor]; myLabelAvailableMem.textColor = [UIColor blackColor]; [myLabelAvailableMem setTextAlignment:UITextAlignmentCenter]; myLabelAvailableMem.text = @"Memoire libre :"; myLabelAMem = [[UILabel alloc] initWithFrame:CGRectMake(10,150,mainFrame.size.width -‐20,40)]; myLabelAMem.backgroundColor = [UIColor clearColor]; myLabelAMem.textColor = [UIColor blackColor]; [myLabelAMem setTextAlignment:UITextAlignmentCenter]; // récupération des informations de l'appareil UIDevice *myDevice = [UIDevice currentDevice]; //***** NOM DU SYSTEME ***** systemName = [myDevice systemName]; myLabelName.text = systemName; //***** VERSION DU SYSTEM ***** systemVersion = [myDevice systemVersion]; myLabelVersion.text = systemVersion; //***** MODELE DU TELEPHONE ***** phoneModel = [myDevice model]; myLabelModel.text = phoneModel;
48 | P a g e
//**** Memoire total et memoire libre ***** natural_t availableMemory = freeMemory(); natural_t totMemory = totalMemory(); aMem = [NSString stringWithFormat:@"%d", availableMemory]; // uniqueIdentifier = [myDevice uniqueIdentifier]; myLabelAMem.text = aMem; tMem = [NSString stringWithFormat:@"%d", totMemory]; myLabelTMem.text = tMem; //affichage des différents Labels [self.view addSubview:monLabel]; [self.view addSubview:myLabelName]; [self.view addSubview:myLabelVersion]; [self.view addSubview:myLabelModel]; [self.view addSubview:myLabelAvailableMem]; [self.view addSubview:myLabelAMem]; [self.view addSubview:myLabelTotalMem]; [self.view addSubview:myLabelTMem]; } /* // Implement viewDidLoad to do additional setup after loading the view, typically from a nib. -‐ (void)viewDidLoad { [super viewDidLoad]; } */ /* // Override to allow orientations other than the default portrait orientation. -‐ (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation { // Return YES for supported orientations return (interfaceOrientation == UIInterfaceOrientationPortrait); } */ -‐ (void)didReceiveMemoryWarning { // Releases the view if it doesn't have a superview. [super didReceiveMemoryWarning]; // Release any cached data, images, etc that aren't in use. } -‐ (void)viewDidUnload { // Release any retained subviews of the main view. // e.g. self.myOutlet = nil; } -‐ (void)dealloc { [super dealloc]; } @end
