Rapport Android

Dédicaces
Je dédie ce travail à
Mes chers parents pour tous leurs sacrifices, leurs amours, leur soutien et leurs
prières tout au long de mes études. Trouvez en ce travail le fruit de vos
sacrifices et dévouement, et l’expression de ma gratitude et mon profond amour.
Que Dieu vous accordait santé, bonheur et longue vie.
Ma chère sœur Malek et mon cher frère Mohamed, en témoignage de
l’attachement, de l’amour et de l’affection que je porte pour vous. Je vous
remercie pour votre affection si sincère et vos encouragements. Je vous souhaite
une vie pleine de succès et de bonheur.
La mémoire de ma grand-mère, J’aurais tant aimé que vous soyez présente. Que
Dieu ait votre âme dans sa sainte miséricorde.
A ma chère cousine Rim, ma fidèle accompagnante dans les moments les plus
délicats de ma vie. Je vous dédie ce travail avec tous mes vœux de bonheur, de
santé et de réussite.
Mes plus proches amis Safa, Khouloud, Aymen et Firas je vous remercie pour
votre présence tout le temps que j’avais besoin de vous, de votre aide et de votre
soutien. Je vous souhaite tout le succès et le bonheur du monde.
Toute ma grande famille, qui a cru en moi et qui est toujours à côté de moi pour
féliciter mes succès.
i
REMERCIEMENTS
Je tiens à exprimer ma sincère gratitude et ma profonde reconnaissance à toutes les
personnes qui ont contribué au succès de mon projet de fin d’étude et qui m’ont aidé lors de la
rédaction de ce rapport.
Tout d’abord, j’adresse mes vifs remerciements à mon encadrant, Monsieur Mohamed Aymen
Saied pour le temps passé ensemble et le partage de son expertise. Grâce aussi à sa confiance
et ses conseils j’ai pu m’accomplir totalement dans mes missions. Il fut d’une aide précieuse
dans les moments les plus délicats.
Ensuite, j’exprime mes sincères remerciements également à Monsieur Chokri Abdelmoula,
mon encadrant académique à l’Ecole Nationale d'Electronique et des Télécommunications de
Sfax (ENET'Com), pour son suivi, sa disponibilité et ses directives tout au long de ce travail.
Je souhaite, aussi, adresser mes remerciements aux membres du jury, pour l’honneur qu’ils
m’ont fait en examinant ce projet de fin d’études, en espérant qu’ils trouvent dans ce rapport
les qualités de clarté et de motivation qu’ils attendent.
De même, je présente mes remerciements à tous les enseignants qui ont participé à notre
évolution scientifique durant les années écoulées de formation à l’ENET’Com.
Enfin, je tiens à remercier toute ma famille, tous mes proches et amis qui m’ont toujours
soutenu et encouragé au cours de la réalisation de ce projet.
ii
Table des matières
CHAPITRE 1 : INTRODUCTION...................................................................................................... 1
1.1
Introduction ........................................................................................................................... 1
1.2
Contexte.................................................................................................................................. 1
1.3
Problématique........................................................................................................................ 2
1.4
Contribution........................................................................................................................... 3
1.5
Conclusion .............................................................................................................................. 4
CHAPITRE 2 : ÉTAT DE L’ART ....................................................................................................... 5
2.1
Introduction ........................................................................................................................... 5
2.2
Généralités ............................................................................................................................. 5
2.2.1
Architecture du système d'exploitation Android ........................................................ 5
2.2.2
Applications Android .................................................................................................... 6
2.2.3
Modèle de permission Android .................................................................................. 10
2.3
Travaux reliés ...................................................................................................................... 15
2.4
Conclusion ............................................................................................................................ 17
CHAPITRE 3 : ESTIMATION DE LA CONSOMMATION ÉNERGÉTIQUE DES
APPLICATIONS ANDROID ............................................................................................................. 18
3.1
Introduction ......................................................................................................................... 18
3.2
Outils utilisés pour l’estimation de la consommation d’énergie ...................................... 18
3.3
PETrA: Power Estimation Tool for Android Applications ............................................. 19
3.3.1
Environnement ............................................................................................................ 20
3.3.2
Principe de fonctionnement ........................................................................................ 21
3.4
Résultats ............................................................................................................................... 25
3.5
Conclusion ............................................................................................................................ 27
CHAPITRE 4 : ÉTUDE DE DÉPENDANCE ENTRE PERMISSIONS ....................................... 28
4.1
Introduction ......................................................................................................................... 28
4.2
Généralités ........................................................................................................................... 28
4.2.1
Clustering ..................................................................................................................... 28
iii
4.2.2
Les clusters ................................................................................................................... 29
4.2.3
Méthodes de Clustering .............................................................................................. 30
4.2.4
Notion de Cluster basé sur la densité ......................................................................... 30
4.3
Extraction de patrons de permissions................................................................................ 32
4.4
Étude de cas ......................................................................................................................... 34
4.4.1
Ensemble de données................................................................................................... 35
4.4.2
Application du Clustering........................................................................................... 35
4.4.3
Métriques ..................................................................................................................... 37
4.4.4
Recommandation des permissions ............................................................................. 41
4.5
Conclusion ............................................................................................................................ 44
CHAPITRE 5 : CONCLUSION ET PRESPECTIVES ................................................................... 45
Bibliographie........................................................................................................................................ 47
iv
Table des figures
Figure 1: Logo de Mitacs Figure 2: Université Laval ........................................................................... 3
Figure 3: Architecture du système d'exploitation Android [8] ................................................................ 6
Figure 4: Fichier AndroidManifest.xml d'Angry Birds Space [9] ......................................................... 10
Figure 5: Un exemple de balise XML <use-permission> [11] .............................................................. 11
Figure 6: Affichage des permissions Android requises pour 'Maps' [12].............................................. 12
Figure 7: Paramètres de permission d'une application [14]................................................................... 14
Figure 8: Scénario représentatif ............................................................................................................ 20
Figure 9: Interface de MonkeyRecorder................................................................................................ 21
Figure 10: Interface de PETrA .............................................................................................................. 22
Figure 11: Workflow de PETrA ............................................................................................................ 23
Figure 12: Résultat de PETrA ............................................................................................................... 25
Figure 13: Statistiques de PETrA .......................................................................................................... 26
Figure 14: Consommation d'énergie totale pour chaque application .................................................... 26
Figure 15: Relation entre le nombre de permissions et la consommation énergétique ......................... 27
Figure 16: Différence entre Clustering par DBSCAN et Clustering par k-means ................................ 30
Figure 17: Clustering par DBSCAN...................................................................................................... 31
Figure 18: Ligne de commande pour exécuter DBSCAN ..................................................................... 34
Figure 19: Entrée de l'algorithme DBSCAN ......................................................................................... 36
Figure 20: Sortie de l'algorithme DBSCAN .......................................................................................... 36
Figure 21: Dépendance du nombre de Clusters à la valeur d'Epsilon ................................................... 37
Figure 22: Exemple de calcul de PUC .................................................................................................. 38
Figure 23: Exemple de calcul de la valeur ACP.................................................................................... 39
Figure 24: Calcul de la valeur PUC pour Base1.................................................................................... 40
Figure 25: Calcul de la valeur PUC pour Base2.................................................................................... 40
Figure 26: Calcul de la valeur PUC pour Base3.................................................................................... 41
Figure 27: Exemple de résultat de recommandation ............................................................................. 42
Figure 28: Recommandation en se basant sur Base1 ............................................................................ 43
Figure 29: Recommandation en se basant sur Base2 ............................................................................ 43
Figure 30: Recommandation en se basant sur Base3 ............................................................................ 43
v
Table des tableaux
Tableau 1: Groupe de permissions dangereuses .................................................................................... 14
Tableau 2: Matrice d'utilisation de cinq applications avec sept permissions ........................................ 33
vi
Liste des abréviations
GPS Global Positioning System
Mitacs The Mathematics of Information Technology and Complex Systems
SDK Software Development Kit
APK Android application Package
API Application Programming Interface
CPU Central processing unit
SD Secure Digital
LCD Liquid Crystal Display
HTML HyperText Markup Language
CSV Comma Separated Values
JSON JavaScript Object Notation
vii
CHAPITRE 1 : INTRODUCTION
1.1
Introduction
Ce projet s’inscrit dans le cadre de mon projet de fin d’études pour l’obtention du
diplôme national d’ingénieur en télécommunications. Nous commençons par un chapitre
introductif consacré principalement à la présentation du contexte général du projet. Nous y
exposons par la suite la problématique de notre sujet ainsi que ses objectifs.
1.2
Contexte
Ces dernières décennies, nous assistons à une évolution technologique considérable
notamment pour les téléphones mobiles. Ces derniers existent sous différents systèmes
d'exploitation et sont commercialisés par plusieurs constructeurs.
Les périphériques présents aujourd’hui sur le marché sont d’un point de vue technologique, de
plus en plus comparables à des micro-ordinateurs puisqu’ils offrent une vaste gamme de
services tels que gestion de courriels, navigation Internet, achat en ligne, accès au compte
bancaire, etc.
Cette gamme de services augmente jour après jour en raison de la croissance du nombre
d'applications innovantes disponibles sur le marché mobile.
Néanmoins, les développeurs sont souvent confrontés à des contraintes de temps lors du
développement de leurs applications. Ils sont donc forcés de développer rapidement les
applications afin de respecter les délais de livraison et faire face à la concurrence. Par
conséquent, les développeurs se focalisent plus sur les fonctionnalités attendues de l'application
et négligent souvent des critères primordiaux tels que la performance, la consommation
d'énergie et l'expérience utilisateur. Cependant, la question souvent posé par un utilisateur
lorsqu'il exécute une application mobile est « combien de temps puis-je utiliser mon téléphone
en exécutant cette application ? ». Savoir mesurer la consommation de l'énergie des
applications mobiles devient donc d'une importance cruciale pour avoir la quantité d'énergie
utilisée afin de faire fonctionner les services proposés.
1
Actuellement, Android est le système d’exploitation mobile le plus utilisé dans le monde avec
82.8% de parts de marché dans les smartphones. Son concurrent le plus proche est Apple, avec
13,9% du marché [1].
Android fournit aux développeurs d'applications un modèle de sécurité basé sur les permissions,
qui contrôlent l'accès aux ressources système, incluant le matériel, les paramètres et les données
utilisateur.
Nous intéressons donc à savoir si ce système de permissions peut avoir un impact direct sur la
consommation énergétique des appareils mobiles.
1.3
Problématique
Malgré l’avancée technologique des systèmes mobiles, ils se trouvent toujours face à la
problématique de la consommation d’énergie. L’utilisation intensive des appareils mobiles
alimentés par des sources d'énergie limitée représente donc un défi sur lequel les chercheurs
travaillent afin de faire augmenter au maximum la durée de fonctionnement du mobile par :
•
L’augmentation de l'autonomie des batteries
•
La minimisation de la consommation d'énergie disponible tout en assurant les bonnes
fonctionnalités du mobile.
Puisque les améliorations dans la technologie de la batterie n'ont pas pu suivre l'évolution de la
demande d'énergie imposée par les nouvelles fonctionnalités d’un smartphone, on a opté à
améliorer l'efficacité énergétique par la deuxième méthode. Parmi les sources de consommation
d'énergie dans le mobile on peut citer :
•
La transmission sans-fil (2G/3G/4G), WiFi, bluetooth ou autres
•
Les applications qui s'exécutent dans le mobile
Certaines applications sont susceptibles d'être gourmandes en énergie, par exemple les jeux
vidéo ou les applications utilisant des appareils tels que le GPS, ces applications causent le
déchargement rapide de la batterie sans aucune raison apparente. Plusieurs études ont identifié
comme causes d'une consommation d'énergie élevée dans les appareils mobiles, des utilisations
abusives des wakelocks qui maintiennent inutilement les composants matériels en éveil [2,3].
2
Android utilise un système de permission pour contrôler les privilèges d’accès et limiter l’accès
de l’application durant l'exécution seulement aux ressources autorisées [4]. Ce mécanisme
exige que les développeurs déclarent quelles ressources leurs applications utilisent.
Malheureusement, plusieurs recherches d'utilisateurs ont montré que la plupart des utilisateurs
ne prêtaient pas attention ou ne comprenaient pas les avertissements de permission [5].
D'autre part, les développeurs ne respectent pas toujours les règles de bonnes pratiques fournies
par Android ce qui rendent les applications plus sensibles au problème de haute consommation
énergétique.
Dans le cadre de notre étude, nous nous concentrons sur les permissions utilisées et leur impact
au niveau de la consommation d'énergie d'une application Android.
1.4
Contribution
Dans le cadre d’un stage de recherche financé par Mitacs, un organisme à but non
lucratif qui se consacre à encourager les réseaux de recherche internationaux entre les
universités canadiennes et le monde [6], et sous la supervision d’un professeur, M. Mohamed
Aymen Saied, de l’établissement d’enseignement d’accueil Université Laval, qui se classe
parmi les plus prestigieuses universités canadiennes avec 404 M$ en fonds de recherche et plus
de 1600 professeurs répartis dans 17 facultés [7], j’ai réalisé un travail de recherche en partant
d’une revue de littérature effectué dans le même domaine.
Figure 1: Logo de Mitacs
Figure 2: Université Laval
Nos objectifs principaux sont les suivants :
o Trouver une solution simple et précise pour mesurer la consommation énergétique des
applications Android.
o Identifier les applications les plus gourmandes en énergie par le calcul de la
consommation d’énergie moyenne en se basant sur des scénarios représentatifs.
3
o Chercher des liens entre les permissions et la consommation énergétique d’une
application en identifiant des patrons d’utilisation des permissions par la méthode de
clustering et en appliquant quelques métriques pour l’analyse de ces patrons.
o Trouver une méthode pour recommander à un développeur des permissions pour son
application.
Pour la réalisation de ces études nous avons utilisé des données qui ont été collectées en 2014
et nous avons effectué une vérification sur l’ensemble des applications en juin 2021 afin de
valider la disponibilité de l’application dans le marché Google Play.
Le présent rapport synthétise notre projet et contient cinq chapitres : ce premier chapitre
introductif, un deuxième chapitre intitulé « Etat de l’art » dédié pour la présentation du système
d’exploitation Android et quelques solutions existantes, le troisième chapitre constitue la partie
de l’estimation de la consommation énergétique en présentant les techniques possibles et la
méthode adopté, dans le quatrième chapitre nous décrivons en détail l’algorithme de Clustering
utilisé et nous présentons une étude de cas concernant les patrons d’utilisations de permissions
et leur impact sur la consommation d’énergie, Enfin, le cinquième et dernier chapitre conclut
le présent mémoire en identifiant notamment certains axes d’amélioration et travaux futurs.
1.5
Conclusion
Dans ce chapitre nous avons élaboré le cadre du stage en déterminant les
problématiques. De plus nous avons présenté brièvement l’organisme d’accueil. Enfin nous
avons cité les objectifs du notre projet. En vue d’avoir une idée plus claire sur le projet, le
prochain chapitre sera consacré à une étude préalable afin de comprendre le système
d’exploitation Android et d’étudier les solutions existantes.
4
CHAPITRE 2 : ÉTAT DE L’ART
2.1
Introduction
La totalité de nos travaux est effectuée avec le système d'exploitation Android vu sa
distribution open source et sa dominance sur la grande part du marché des smartphones.
Dans la première partie de ce chapitre, nous introduisons des généralités du système
d’exploitation mobile Android et nous explorons dans la deuxième partie les travaux reliés aux
permissions dans les applications mobiles et à la consommation énergétique de applications
Android.
2.2
Généralités
Android est distribué en Open Source sous licence Apache. Il est conçu spécialement pour
les smartphones et les tablettes tactiles. Avec le concept central d'une communauté open source,
Android offre ses outils, ses suites et son code source gratuitement au public. Pour les
développeurs, cela permet l'innovation dans la construction d'applications.
2.2.1
Architecture du système d'exploitation Android
Android est un système d'exploitation mobile basé sur le noyau Linux, développé par
Google et lancé en juin 2007.
L'architecture des systèmes Android peut être divisée en quatre couches comme illustré dans la
figure 3. La couche supérieure, Applications, contient les applications Android. Les
applications développées sont installées au niveau de cette couche. Application Framework, est
la couche qui regroupe les services proposés aux développeurs, sous forme de classes Java, lors
du développement de leur application. La couche inférieure regroupe les librairies offertes par
le système Android en plus des librairies standards, équivalentes au Java SE, qui sont localisées
dans le Core Libraries. Au niveau de cette couche, plus précisément dans le Android Runtime,
on retrouve aussi le cadre d'exécution de nos applications, Dalvik Virtual Machine. Dalvik est
une implémentation de la machine virtuelle Java spécialement optimisée et conçue pour
Android. Dans la dernière couche, Linux Kernel, on retrouve le noyau Linux sur lequel le
système Android est basé.
5
Figure 3: Architecture du système d'exploitation Android [8]
2.2.2
Applications Android
Une application Android est développée en Java et compilée dans un seul fichier
d'archive à l'aide de la trousse d'outils SDK d’Android. Cela prend le code Java et le compile
dans un fichier de package Android, appelé APK (.apk). Ce fichier APK contient toutes les
ressources et les données pertinentes requises pour installer et exécuter une application sur un
appareil Android.
Le principe de Android s'appuie sur des classes qui sont en fait les bases élémentaires sur
lesquelles les futures applications reposent, Elles sont indispensables pour la construction de
toute application.
6
2.2.2.1 Composants principaux d’Android
Dans cette partie on va décrire les principales classes du système Android
•
Activity : Les applications Android sont composées d'activités, qui sont des tâches
autonomes conçues pour fournir des informations à l'utilisateur. Les activités
représentent habituellement un seul écran d'information, comme la composition d'un
message instantané ou d'un courrier électronique. Les activités sont proactives, elles
commencent et s'annulent mutuellement, créant un flux d'informations clair sur
l'interface utilisateur, y compris les activités d'appel d'autres applications installées sur
l'appareil.
•
Content Provider : Un Content Provider est un composant qui sert à gérer les données
associées à une application Android, partagée ou privée. Ces données peuvent être
stockées dans un système de fichiers tel qu’une base de données SQLite, sur le Web ou
tout autre emplacement de 9 stockage persistant. Les applications font appel au content
provider pour consulter ou modifier les données stockées (uniquement avec
l'autorisation du content provider des applications). Par exemple, les informations de
contact comme les noms et les numéros peuvent être utilisés de manière dynamique sur
une grande variété d'applications Android, un Content Provider est mis en place pour
distribuer et contrôler les modifications et le flux de ces données.
•
Service : Le composant Service des applications Android n'a pas d'interface utilisateur
et est responsable de l'exécution de tous les processus d'arrière-plan des applications, y
compris l'extraction de données à distance sur un réseau alors qu'un utilisateur interagit
avec d'autres applications sur son appareil. Les services sont généralement appelés via
une activité pour fournir d'autres fonctionnalités à une application.
•
Broadcast Receiver : Un Broadcast Receiver est responsable d'annoncer des
notifications à l'échelle du système. Ce composant n’est pas associé à une interface
graphique utilisateur, cependant, il peut toujours annoncer des notifications telles que la
batterie faible et d'autres messages système à l'utilisateur. Pour les applications Android,
Broadcast Receiver permettra à une application de diffuser des notifications à d'autres
applications, y compris les nouvelles initiations de données, activités ou services. Référé
en tant que passerelle à d'autres composants, le Broadcast Receiver est destiné à
effectuer moins de travail que les autres composants de l'application.
7
•
Intent : Intent est un objet de messagerie asynchrone pour activer ces composants
individuels et leur permettre d'envoyer des messages et des commandes les uns aux
autres. Intent peut être considérer comme un messager qui demande une action à partir
d'un autre composant
2.2.2.2 Android package
Android Package est la forme sous laquelle une application Android est proposée pour les
utilisateurs. Il s’agit d’une archive, communément appelée apk, contenant le code de
l’application et les ressources qu’elle utilise. Nous présentons dans ce qui suit le contenu
principal d’un apk :
•
AndroidManifest.xml : AndroidManifest.xml est un fichier XML créé par le
développeur de l’application. Il contient les informations liées à l’application qui
sont nécessaires au système. Parmi Ces informations, nous pouvons citer :
o Le nom du package de l’application
o Le nom de l'activité principale (Main Activity), qui représente le point
d'entrée de l’application
o La liste des composants de l'application, les activités, les services, etc
o La liste des permissions qui permettent à l'application d'avoir accès à des
parties protégées de l'API, comme par exemple permettre à l'application
d'avoir accès à Internet
o La liste des librairies requises
o Le niveau minimal du SDK Android pour que l’application puisse
fonctionner
La figure 4 présente le fichier AndroidManifest.xml d’une version d’Angry Birds Space. À la
deuxième ligne sont définis l’endroit où l’application sera installée (ici on a laissé au choix du
système) et le nom du package de l’application. Ensuite, de la ligne 5 à la ligne 20 sont listées
les permissions demandées par l’application. Dans cet exemple, l’application demande par
exemple l’accès à la mémoire externe, au réseau, aux informations liées au téléphone, aux
données de géolocalisation et au système de payement proposé par Google [8].
Les ligne 22 et 23 décrivent comment l’application sera présentée dans le menu des applications
une fois installée : l’icône à utiliser et le nom à afficher. Dans le reste du fichier, on trouve les
composants de l’application et les informations qui y sont liées. L’application a ainsi quatre
8
composants : deux de type Activity, un de type Service et un de type Broadcast Receiver. Il faut
savoir qu’il est possible de filtrer les messages Intent à destination des composants de
l’application. Dans AndroidManifest.xml, on peut faire ça via les entrées intent-filter. Ainsi le
premier Activity ne recevra que les Intents dont l’attribut action a la valeur
android.intent.action.MAIN et la catégorie est android.intent.category.LAUNCHER. Cela
signifie que lorsque l’utilisateur cliquera sur l’icône de l’application dans le menu de son
téléphone c’est ce composant qui sera lancé. Quant au Broadcast Receiver, il ne réagira qu’aux
intents dont l’attribut action vaut com.android.vending.billing.RESPONSE_CODE.
•
Classes.dex : Le code de chaque classe d’une application Java standard est stocké
dans des fichiers .class différents. Mais sous Android, ce n’est pas le cas. Tout est
stocké dans un seul et unique fichier « Classes.dex ». De plus, le code des
applications Java est lui compilé en byte code Java, alors que, celui des applications
Android est lui compilé dans un autre format qui est le byte code Dalvik. C’est le
contenu de ce fichier, ou plus précisément une version optimisée de celui-ci, qui
sera interprété par la machine virtuelle Dalvik afin d’exécuter l’application.
•
Autres : Un apk contient aussi d’autres entrées telles que les répertoires METAINF,
res, jni et lib. Le répertoire META-INF contient ainsi des fichiers liés à
l’identification de son développeur et au contrôle d’intégrité de l’application. Le
répertoire res contient toutes les ressources utilisées par l’application telle que des
images, sons, etc. Les répertoires jni et lib contiennent les bibliothèques utilisées par
l’application.
9
Figure 4: Fichier AndroidManifest.xml d'Angry Birds Space [9]
2.2.3
Modèle de permission Android
Le système d'exploitation Android, sur lequel nous avons fait nos études, est un système
Linux multi-utilisateurs dans lequel chaque application est associée à un compte utilisateur
10
(user) diffèrent. C’est pour cela que le système attribue par défaut, à chaque application un
User-ID (UID) unique et non connu de l'application. En fait, chaque application s'exécute avec
une identité de système distincte et est isolée dans un sandbox virtuel par le noyau Linux, en
les séparant d'autres applications pour protéger l'intégrité du système et la confidentialité de
l'utilisateur. Par défaut, chaque application accède uniquement aux composants nécessaires à
son exécution. En fait, si une application nécessite d’utiliser des ressources ou des informations
en dehors de son sandbox, elle doit demander explicitement l'autorisation. En fonction du type
de permission demandée par l'application, le système peut l’accorder directement, ou le système
peut demander à l'utilisateur d'accorder la permission [10]. Une application Android de base ne
possède aucune permission associée par défaut, le développeur de l’application est le
responsable du la remplir avec des permissions, adaptées à ses fonctionnalités. Précédemment
discutées dans la section 2.2.2.2, les permissions d'applications sont stockées dans un fichier
appelé « AndroidManifest.xml » situé dans le fichier « Android Package (.apk) » de
l'application. La balise est un élément du fichier AndroidManifest.xml qui permet aux
développeurs de déclarer quelles permissions doivent être accordées pour avoir le bon
fonctionnement de l'application. Ces permissions sont par la suite accordées par l'utilisateur
lorsque l'application est installée sur des appareils fonctionnant sous la version Android 5.1 ou
lorsque l'application est exécutée sur des appareils exécutant la version Android 6.0 ou
supérieurs. La figure ci-dessous présente un exemple de la balise demandant la permission
d'écrire sur le stockage externe.
Figure 5: Un exemple de balise XML <use-permission> [11]
2.2.3.1 Les permissions d'application avant la mise à jour Android 6.0
Marshmallow
Les permissions sont un aspect du modèle de sécurité d'Android, qui permet aux utilisateurs
d'avoir un pouvoir sur ce qu'ils peuvent et ne peuvent pas accepter sur leurs périphériques
mobiles. Comme mentionné précédemment une application Android est exécutée dans un
sandbox avec une gamme limitée de ressources système. Lorsqu'une application est installée
11
sur un périphérique exécutant Android 5.1 ou inférieur, Android restreint automatiquement la
capacité de l'application jusqu'à ce que l'utilisateur accepte explicitement l'installation de cette
application sur son appareil et l'accès au système d'exploitation ou aux fonctionnalités requises
pour fonctionner correctement. La figure 6 décrit l'affichage habituel des permissions
demandées par une application à l’utilisateur au moment de l'installation.
Figure 6: Affichage des permissions Android requises pour 'Maps' [12]
Sur les périphériques exécutant Android 5.1 ou moins, les permissions d'une application sont
toutes requises ou rien, c'est-à-dire que les utilisateurs n’ont pas le choix, ils doivent accepter
toutes les permissions d'une application ou refuser l'application complètement et dans ce cas, il
ne peut pas utiliser l’application parce qu’il n’est pas d’accord avec certaines permissions
demandées.
12
2.2.3.2 Android 6.0 Marshmallow : Les modifications apportées au
modèle de permission
Android 6.0 Marshmallow a été publié en octobre 2015. Le but de chaque mise à jour
Android conçue est de donner à l'utilisateur un environnement mobile plus convivial, plus
interactif et plus sûr. La mise à jour 6.0 s'est vantée de fournir aux utilisateurs une assistance
contextuelle, une meilleure durée de vie de la batterie et des niveaux de productivité, de
connectivité et d'internationalisation plus élevés, mais ses plus grandes améliorations ont été
les changements dynamiques apportés à la fonctionnalité de sécurité et à la réorganisation du
gestionnaire des permissions [13].
À partir de la version d'Android 6.0, on ne demande plus la permission d'être accordée lors de
l'installation initiale d'une application, les utilisateurs deviennent capables d’accorder des
permissions pendant l'exécution des applications.
Cette approche est conçue pour donner à l’utilisateur plus de contrôle et simplifier le processus
d'installation de l'application. En fait, la mise à jour 6.0 a fourni aux utilisateurs une
fonctionnalité avancée et un contrôle sur leurs applications, en leur permettant de révoquer les
autorisations individuelles d'une application via l'interface des paramètres de l'application [14].
Par exemple, l’utilisateur pourrait choisir de donner à une application de transport un accès à
l'emplacement de son appareil mais rejeter l'accès pour afficher sa liste de contacts ou ses
services SMS. La figure 7 montre la nouvelle interface utilisateur pour ce contrôle avancé [14].
13
Figure 7: Paramètres de permission d'une application [14]
Une appareil mobile exécutant Android 6.0 ou supérieur définit maintenant les permissions
dangereuses dans ce qu’Android appelle « groupes de permission ». Le tableau 2 décrit les 9
groupes de permissions et leurs permissions dangereuses associées.
Tableau 1: Groupe de permissions dangereuses
Groupe de permission
Permission dangereuse
Lire_Calendrier
Calendrier
Ecrire_Calendrier
Camera
Camera
Lire_Contact
Contacts
Ecrire_Contact
Obtenir_Compte
Location
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
14
Microphone
Enregistrement_Audio
Lire_L’état_de_téléphone
Appel_Téléphonique
Lire_Journal_D’appels
Phone
Ecrire_ Journal_D’appels
Ajouter_des messages vocaux
Utilisation_SIP
Processus_Appels_Sortants
Capteurs
Capteurs_Du_Corps
Envoyer_SMS
Recevoir_SMS
SMS
Ecrire_SMS
Recevoir_MMS
Lire_Stockage_Externe
Stockage
Ecrire_ Stockage_Externe
2.3
Travaux reliés
Les travaux relatifs à cette recherche se divisent en deux catégories soit la consommation
énergétique des applications mobiles et l’analyse du modèle de permission Android.
L'aspect énergétique est devenu un facteur clef dans le développement d'applications en tout
genre et spécifiquement les applications mobiles, en raison de la faible capacité des batteries
présentes sur ces périphériques.
Une première technique pour mesurer la consommation d'énergie des appareils est basée sur le
matériel, car des kits d'outils matériels spécifiques sont nécessaires pour effectuer les mesures.
Flinn et Satyanarayanan [15] ont proposé un outil nommé POWERSCOPE. Il repose sur
l'adoption d'un multimètre numérique connecté à un ordinateur, qui permet de suivre les
15
variations d'énergie, enregistrées par le multimètre, des processus qui s'exécutent sur un
ordinateur portable.
D'autres chercheurs ont exploité le moniteur de puissance MONSOON [16] pour mesurer la
consommation d'énergie des API d'applications Android [17].
Les exigences matérielles coûteuses nécessaires pour le profilage énergétique basé sur le
matériel ont encouragé les chercheurs à trouver des moyens alternatifs pour approximer la
consommation d'énergie.
Les approches logicielles utilisent exclusivement les fonctionnalités du système pour estimer la
consommation électrique, sans nécessiter de matériel supplémentaire, Do et al. [18] ont
développé PTOP, une approche proposée qui prend en compte la fréquence CPU, la
consommation de disque dur et de mémoire comme sources d'information pour estimer les
joules consommés par un processus.
ELENS [19] fournit une estimation plus fine de la consommation d'énergie au niveau de la
méthode, du chemin ou de la ligne de source. Il repose sur une combinaison d'analyse de
programme et de modélisation énergétique et produit un retour (feedback) pour aider les
développeurs à mieux comprendre le comportement de l'application.
A la différence des techniques/outils évoqués ci-dessus, PETrA [20], l’outil auquel nous allons
apporter des modifications pour l’utiliser dans notre approche, ne nécessite aucun équipement
matériel supplémentaire et donc aucune solide expérience dans la mise en place du banc d'essai.
Il utilise des outils fiables issus de l'Android Toolkit. Enfin, contrairement aux outils mesurant
la consommation d'énergie au niveau du processus, PETrA fonctionne à une granularité au
niveau de la méthode. En plus de cela, la plupart des approches proposées dans la littérature (y
compris PTOP et ELENS) ne sont pas accessibles au public.
Dans [21], les auteurs ont étudié l'hypothèse largement répandue selon laquelle les profils de
consommation d'énergie calculés à l'aide d'outils logiciels sont moins précis que les valeurs
réelles mesurées à l'aide d'outils matériels, ils ont comparé les résultats obtenus par PETrA par
les résultats de [16] pour montrer que les estimations produites par PETrA sont très proches des
valeurs réelles calculé par l’approche de MONSOON.
De nombreux chercheurs ont proposé des approches pour aider les utilisateurs et même les
développeurs à comprendre les autorisations utilisées dans les applications Android.
16
Frank et al. ont sélectionné 188 389 applications à partir du marché officiel d’Android et ont
analysé les combinaisons de demandes de permissions par ces applications [22]. Une méthode
probabiliste a été proposée pour déduire les patrons d’utilisation de permissions les plus
répandus en fonction de la popularité des applications (notes et nombre de revues). Les auteurs
ont identifié plus de 30 modèles communs de demandes de permissions. Leur objectif principal
était d’étudier l'écart des demandes de permissions pour les applications à rang élevé et celles
à faible rang, les résultats ont montré que les applications à faible réputation s'écartent très
souvent des modèles de demande de permissions identifiés pour les applications à haute
réputation.
2.4
Conclusion
Dans ce chapitre, nous avons présenté le système d’exploitation Android et ces applications
et nous avons fourni un aperçu sur les travaux reliés aux techniques de mesure de la
consommation énergétique et aux permissions dans les applications mobiles. Nous présentons
dans le prochain chapitre notre proposition pour l’estimation de la consommation d’énergie des
applications Android.
17
CHAPITRE 3 : ESTIMATION DE LA
CONSOMMATION ÉNERGÉTIQUE DES
APPLICATIONS ANDROID
3.1
Introduction
Dans le chapitre précédent, nous avons décrit les deux techniques de mesure de la
consommation énergétique, la technique basée sur le matériel et la technique basé sur un
logiciel, dans notre approche nous avons opté pour la deuxième technique. La solution que nous
allons présenter par la suite, adopte aussi la méthode d’analyse dynamique. Nous allons donc
décrire dans ce chapitre les outils utilisés par cette solution, l’environnement nécessaire pour le
bon fonctionnement, et le principe suivis par cette solution.
Outils utilisés pour l’estimation de la consommation d’énergie
3.2
Les appareils mobiles modernes sont équipés de plusieurs composants matériels intégrés
entre eux. Les composants typiques incluent Le CPU, wifi, mémoire, Carte SD, téléphone,
Bluetooth, GPS, appareil photo, accéléromètre, Écran LCD, écran tactile…
Il est courant pour les applications Android d'utiliser plusieurs composants simultanément afin
d'offrir une meilleure expérience à l'utilisateur. Les états d'alimentation de chaque composant
consomment chacun une quantité d'énergie différente. Pour bien connaître où l'énergie est
dissipée et la valeur de la quantité d'énergie consommée on a employé plusieurs outils,
principalement :
•
BatteryStats [23] est un outil open source du framework Android capable de collecter
les données de batterie de l'appareil en cours d'évaluation. En particulier, il est capable
de montrer quels processus consomment de l'énergie de la batterie et quelles tâches
doivent être modifiées afin d'améliorer la durée de vie de la batterie. Il est exécutable
via la ligne de commande. Les données collectées peuvent être analysées sous forme de
fichier journal ou peuvent être converties en une visualisation HTML pouvant être
visualisée dans un navigateur à l'aide de Battery Historian.
•
Systrace [24] est un outil qui peut être utilisé pour analyser les performances des
applications. Il capture et affiche les temps d'exécution des processus actifs d'un
18
smartphone, en combinant les données du noyau Android, c'est-à-dire le planificateur
du processeur, l'activité du disque et les threads d'application. Les données peuvent être
visualisées sous la forme d'un rapport HTML qui montre la vue d'ensemble des
processus dans une fenêtre de temps donnée.
•
Dmtracedump [25] fournit un moyen d'afficher les fichiers journaux de suivi (trace log
files). Les fichiers générés par dmtracedump sont faciles à analyser et permettent aux
développeurs d'établir avec précision, à une granularité de la microseconde, quand un
appel de méthode a été invoqué et quand il est retourné.
3.3
PETrA: Power Estimation Tool for Android Applications
PETrA [21] est un logiciel open source écrit en Java, depuis l’année 2016, capable d'estimer
la consommation d'énergie des appels de méthode dans les applications Android. Il est basé sur
certains outils Android tels que Monkey, Batterystats, Systrace et dmtracedump.
PETrA utilise la méthode d’analyse dynamique, Ce genre de méthodes calculent les métriques
nécessaires à l'exécution de l'application via du profilage. Cet outil utilise Monkey [26] et
Monkeyrunner[27] pour exercer l’application à analyser.
Les outils Systrace et dmtracedump sont fournis dans le package Android SDK Tools, plus
précisément, dans android-sdk/platform-tools/. PETrA utilise la version 25 de SDK alors
qu’on est arrivé aujourd’hui à la version 31, par suite de cette évolution, le logiciel n’est plus
capable à analyser les fichiers générés par ces deux outils à cause des changements effectués
au niveau de la structure de ses fichiers. Nous avons donc contribué en apportant des
modifications au code PETrA pour qu’il puisse supporter les nouveaux formats de fichiers
résultants de Systrace et dmtracedump.
Nous avons pu aussi élargir le champ d’intervention de cette solution, pour qu’elle soit capable
d’estimer la consommation énergétique de tout type de méthode même les appels au Java APIs.
De cette manière, nous pouvons avoir une estimation de la quantité d’énergie consommée par
l’application plus précises.
Pour le fonctionnement, PETrA nécessite plusieurs entrées et paramètres en plus d’un
environnement bien déterminé.
19
3.3.1
Environnement
Pour l’exécution de PETrA, nous avons utilisé le système d’exploitation Linux, en plus
nous avons utilisé pour cette expérience un Samsung Galaxy Grand Prime puisqu’il est très
proche dans ses caractéristiques à LG Nexus 4 utilisé dans [21], ces deux smartphones sont
composés de 4 cores CPU. Pour exécuter une application sur le smartphone elle doit tout
d’abord être debuggable, pour cela nous avons eu besoin dans certain cas de décompiler l’APK,
ajouter dans la balise « application » du fichier manifeste android : debuggable=true et
générer à un nouveau APK signé.
Pour l’utilisation de MonkeyRunner, on a besoin d’un scénario de test, ce scénario doit être
représentatif, c'est-à-dire un scénario d’utilisation typique pour avoir une meilleure estimation
de la consommation. Pour ce faire, nous avons exploité la base de données de l’approche de
MONSOON, la figure 8 montre un exemple des scénarios de la base de données de
MONSOON.
Figure 8: Scénario représentatif
En fait, parmi les 55 applications analyser par MONSOON, nous avons pu télécharger 10
applications en utilisant un outil de téléchargement appelé APK-Downloader[28], les autres ne
sont plus disponibles, et nous avons créé des script pour les scénario en utilisant
MonkeyRecorder[27] qui existe dans les outils de SDK.
En exécutant la commande monkeyrunner monkey-recorder.py nous obtenons une
interface qui représente l’écran de notre smartphone, toute action faite sur l’écran va être
enregistrer comme une ligne de script de test. La figure 9 montre l’interface de
MonkeyRecorder et la création du script pour le scénario de la figure 8.
20
Figure 9: Interface de MonkeyRecorder
3.3.2
Principe de fonctionnement
PETrA prend plusieurs entrées comme indique son interface graphique dans la figure
10, principalement, l’emplacement de l’APK à analyser. Elle peut aussi prendre l’emplacement
du fichier Power Profile qui est un fichier caractérisant le smartphone ou bien elle peut l’obtenir
directement du smartphone lors du profilage puisque ce fichier est fourni par le fabricant de
l’appareil.
En plus, PETrA prend comme paramètre le nombre d’exécution de l’application pour le calcul
de la consommation, il est représenté par ‘Runs’ dans l’interface, si Runs=n>1, on doit refaire
l’estimation n fois et on obtient à la fin la valeur moyenne de la consommation de chaque appel
de méthode, en augmentant la valeur de ‘Runs’, on augmente la précision de PETrA.
L’utilisateur doit aussi choisir entre Monkey et MonkeyRunner. Puisque nous avons besoin des
scénarios représentatif et non pas des actions arbitraires, nous avons choisi MonkeyRunner, de
cette façon on peut avoir une estimation d’une utilisation typique et efficace de l’application.
Suite à notre choix, nous devons fournir l’emplacement du script de test et la durée nécessaire
pour exécuter un tel test.
21
Figure 10: Interface de PETrA
En branchant le smartphone et exécutant PETrA on passe aux étapes suivantes comme indiqué
dans la figure 11 :
•
Installation de l’APK en utilisant Android Debug Bridge (adb), un outil qui permet de
communiquer avec un appareil,
•
Au début de chaque exécution, le cache de l'application est nettoyé et Batterystats est
réinitialisé pour éviter tout processus inutile sur l'appareil,
•
Exécution de scénario de test,
•
Collection des résultats des outils BatteryStats, Systrace et Dmtracedump en plus de
l’obtention du fichier power profile,
•
Calcul de la consommation énergétique de chaque appel de méthode en utilisant les
données obtenues,
•
Sauvegarde des résultats,
•
Si on n’a pas encore atteint le nombre d’exécution demandé, on reprend la démarche à
partir de la deuxième étape, sinon on désinstalle l’application.
22
Figure 11: Workflow de PETrA
Pour la collection des données et le calcul de la consommation énergétique, PETRA s'appuie
sur dmtracedump pour stocker les traces d'exécution de l'application en cours d'analyse. Pour
chaque appel de méthode, cet outil fournit l'heure d'entrée et de sortie. La sortie finale est une
liste des appels de méthode exécutés pendant l'exécution. Elle utilise aussi l’outil Batterystats
pour récupérer les composants actifs du smartphone et leur état dans une fenêtre de temps
spécifique. En outre, il peut fournir des informations sur la tension de l'appareil. A partir de ces
informations, il est alors possible de calculer l'énergie consommée par le smartphone pendant
une fenêtre temporelle. Et les informations fournies par Systrace, mentionnées dans la section
3.3, sont utilisées pour capturer la fréquence du CPU dans une fenêtre de temps donnée.
Considérant que les CPUs ont des consommations différentes car leur fréquence varie, cette
information complète celle fournie par Batterystats améliorant les estimations.
Après avoir rassemblé les informations relatives aux composants actifs avec leur statut, les
fréquences CPU et les appels de méthode, le fichier de profil de puissance est chargé. Le but de
ce fichier étant d'estimer la décharge de la batterie de manière appropriée, les valeurs du profil
de puissance sont données en courant (ampères). Le framework Android multiplie le courant
par le temps pendant lequel le sous-système était actif et calcule la valeur mAh, qui est ensuite
utilisée pour estimer la quantité de batterie déchargée par l'application / le sous-système.
23
Compte tenu des données précédentes, il est possible de calculer l'énergie consommée pour
chaque invocation d'appel de méthode. Tout d'abord, étant donné un appel de méthode et sa
terminaison, nous pouvons calculer la fenêtre temporelle globale Tw comme la différence
arithmétique entre les deux instants temporels où ces deux événements se sont produits.
Cependant, l'énergie consommée au cours d'une seule fenêtre temporelle n'est pas constante
mais peut changer en raison d'une variation de la fréquence du processeur ou d'un changement
d'état du composant. Par conséquent, nous avons divisé les fenêtres de temps en unités de temps
plus petites, c'est-à-dire des trames de données T∆. Lorsque l'entrée dans une méthode est
enregistrée, une nouvelle fenêtre temporelle Tw et une nouvelle période temporelle T∆
démarrent. A chaque fois qu'un composant change d'état, la trame temporelle existante T∆ est
terminée et une nouvelle (pour le nouvel état) est démarrée. Lorsque le point de sortie vers une
méthode est enregistré, alors la fenêtre temporelle correspondante Tw est terminée ainsi que la
dernière trame temporelle T∆. De cette manière, chaque trame de données T∆ est caractérisée
par des états de composants cohérents (par exemple, la fréquence CPU) et par un drain d'énergie
cohérent (constant). Par exemple, si le CPU travaille à la fréquence maximale et qu'aucun des
composants ne change d'état, les fenêtres temporelles Tw seront composées d'une seule trame
temporelle T∆ de même durée, c'est-à-dire la différence entre la saisie de la méthode et sortir.
Par conséquent, nous pouvons calculer l'intensité de puissance actuelle à chaque intervalle de
temps T∆ comme suit :
𝐼∆ = ∑𝑐∈𝐶 𝐼∆,𝑐,𝑠
Où C’est l'ensemble des composants matériels du smartphone, I∆,c,s est l'intensité actuelle du
composant c avec l'état s dans l'intervalle de temps actuel T∆.
Après avoir calculé l'intensité du courant, il est possible de calculer l'énergie consommée dans
un laps de temps, comme suit :
J∆ = I∆ × V∆ × T∆.
Où J∆ est l'énergie consommée en Joule, I∆ est l'intensité du courant en Ampère, V∆ est la
tension de l'appareil en Volt et T∆ est la durée de la période en secondes.
Enfin, l'énergie consommée par un appel de méthode peut être calculée en additionnant l'énergie
consommée dans chaque période pendant laquelle l'appel de méthode était actif :
𝐽 = ∑𝑇
∆ ∈𝑇𝑤
(𝐼∆ ×𝑉∆ ×𝑇∆ )
24
3.4
Résultats
La solution PETrA ne nécessite aucun équipement matériel supplémentaire mais elle a pu
démontrer son efficacité et sa précision. Elle offre comme résultat final, un fichier CSV,
contenant la signature de chaque méthode appelée, sa consommation énergétique moyenne
calculée et la durée d’exécution de cette méthode. La figure 12 représente une partie du fichier
résultant.
Figure 12: Résultat de PETrA
En plus, PETrA fourni une fonctionnalité très intéressante pour les développeurs des
applications Android, à la suite du calcul de la consommation d’énergie pour chaque méthode,
PETrA offre des statistiques pour définir les 5 méthodes les plus gourmandes en énergie.
Dans le cas de notre exemple, les résultats sont présentés dans la figure 13, les cinq méthodes
les plus consommatrice sont tous des méthodes qui exposent des classes d'interface utilisateur
de base qui gèrent la disposition de l'écran et l'interaction avec l'utilisateur.
25
Figure 13: Statistiques de PETrA
Pour continuer notre analyse et notre travail de recherche nous avons calculé la consommation
d’énergie totale pour les dix applications comme le montre la figure 14, et nous avons divisé
ces données en 5 applications plus consommatrices et 5 applications moins consommatrices.
Figure 14: Consommation d'énergie totale pour chaque application
26
Nous avons appliqué aussi sur ces 10 applications l’outil APK-Analyzer [29] qui créé un fichier
JSON pour chacune des applications dans lequel on trouve des informations sur l’APK,
notamment les permissions utilisées et nous avons répondu à une des questions les plus
courantes, « est-ce que les applications qui utilisent plus de permissions sont plus gourmande
en énergie ? ». À partir des résultats que nous avons obtenus, nous avons créé le diagramme de
la figure 15, les applications sont dans l’ordre décroissant de la consommation énergétique donc
on peut remarquer que le nombre des permissions n’a aucun impact sur la consommation
énergétique d’une application.
Figure 15: Relation entre le nombre de permissions et la consommation énergétique
3.5
Conclusion
Dans ce chapitre nous avons concentré sur la première partie du projet, qui est la solution
de l’estimation de la consommation énergétique, nous reviendrons par la suite aux résultats de
cette partie pour les utilisés dans notre analyse.
27
CHAPITRE 4 : ÉTUDE DE DÉPENDANCE ENTRE
PERMISSIONS
4.1
Introduction
Le but de ce chapitre est d’identifier des patrons de permissions communs et de vérifier
jusqu’à quel point ces patrons sont suivis par les applications Android. Ce chapitre est organisé
en quatre sections. La première section présente quelques définitions indispensables pour la
compréhension de notre approche, ainsi que l’algorithme que nous avons utilisé. Dans la
deuxième section, nous allons décrire notre approche d’extraction de patrons de permissions et
nous présentons une étude de cas dans la troisième section. Nous clôturons ce chapitre par une
conclusion.
4.2
Généralités
Dans cette section nous allons présenter en détail la méthode utilisée pour l’extraction des
patrons d’utilisation de permissions.
4.2.1
Clustering
La notion de Clustering est une technique d'apprentissage non supervisée largement
utilisée comme outil d'analyse de données. Le contexte est quand nous ne connaissons pas les
regroupements naturels des données, les algorithmes de Clustering les identifient et peuvent
produire une représentation basée sur certaines caractéristiques ou caractéristiques communes.
Le Clustering est considéré une méthode statistique d'analyse des données. Elle vise à diviser
un ensemble de données en différents « paquets » homogènes, dans le sens que les données de
chaque sous-ensemble partagent des caractéristiques communes, qui correspondent le plus
souvent à des critères de proximité :
•
Des différences intra-classe minimales pour obtenir des clusters.
•
Des différences inter-classes maximales afin d'obtenir des sous-ensembles bien
différenciés.
28
Les algorithmes de Clustering permettent de partitionner les données en sous-groupes
d'observations similaires. Ils peuvent être utilisés pour :
•
Mieux comprendre ces données ;
•
Faciliter la visualisation de ces données ;
•
Inférer des propriétés de ces données.
4.2.2
Les clusters
Un cluster est un ensemble d’éléments. Cet ensemble est distinct des autres. Donc
chaque élément d’un cluster a de fortes ressemblances avec les autres éléments de ce même
cluster, alors qu’il doit être différent des éléments des autres clusters.
Il existe deux types de clusters :
•
Les clusters durs qui sont totalement distincts les uns des autres, donc un élément d’un
cluster n’appartient à aucun autre [30].
•
Les clusters mous comportent des éléments dont l’appartenance est pondérée, donc un
élément peut appartenir à plusieurs clusters en même temps [30].
Les deux propriétés importantes définissant un cluster pertinent sont :
•
Sa cohésion interne (que les éléments appartenant à ce cluster soient les plus proches
possible)
•
Son isolation externe (que les éléments appartenant aux autres clusters soient les plus
éloignés possible).
Pour observer cela, plusieurs mesures sont associées à chaque cluster :
•
Sa densité (la masse d’objets par unité volumique),
•
Sa variance (le degré de dispersion des objets dans l’espace depuis le centre du cluster),
•
Sa dimension (typiquement son rayon ou son diamètre),
•
Sa forme (hyper sphérique/allongée/concave/convexe…)
•
Sa distance (par rapport aux autres clusters).
29
Si on regarde un cluster, il forme un ensemble, et cet ensemble occupe un espace. Ainsi, pour
pouvoir mesurer l’appartenance d’un objet à un cluster et pouvoir prendre des décisions, il nous
faut une fonction de mesure. On utilise souvent la distance euclidienne [30].
4.2.3
Méthodes de Clustering
On distingue trois grands types de méthodes de Clustering :
•
Les méthodes hiérarchiques, dont le but est de former une hiérarchie de clusters, de
telle sorte que plus on descend dans la hiérarchie, plus les clusters sont spécifiques à un
certain nombre d’objets considérés comme similaires [30].
•
Les méthodes centoïdes, La méthode centroïde la plus classique est la méthode Kmeans, dont le but est d’identifier un certain nombre (K) de points représentatifs des
clusters, auxquels sont ensuite associés l’ensemble des autres points, selon leur
proximité avec les points représentatifs considérés.
•
Les méthodes à densité, dont le but est d’identifier, dans l’espace, les régions
homogènes de fortes densités entourées par des régions de faible densité, qui formeront
les clusters. DBSCAN est un exemple d’algorithme appartenant à cette catégorie.
La figure 16 représente un exemple de données regroupées par 2 types de Clustering différents.
Figure 16: Différence entre Clustering par DBSCAN et Clustering par k-means
4.2.4
Notion de Cluster basé sur la densité
Lorsqu’on visualise les regroupements simples de points de la figure 17, il est possible
de détecter facilement et sans aucune ambigüité les points qui appartiennent à un cluster et ceux
qui n’appartiennent à aucun et qui sont donc non significatifs (on parle dans ce cas de bruit).
30
La raison principale qui nous permet de les reconnaître est qu’à l’extérieur des clusters la densité
des zones de bruit est inférieure à celle de chacun des clusters. Dans ce qui suit, nous allons
essayer de formaliser cette notion intuitive de cluster et de bruit dans une base de données D de
points d’un espace S de k dimensions. On fixe, tout d’abord, epsilon 𝜀 le rayon du voisinage à
étudier et MinPts le nombre minimum de points qui doivent être contenus dans le voisinage.
L’idée clé du Clustering basé sur la densité est que pour chaque point d’un cluster, ses environs
pour un rayon donné 𝜀 doit contenir un nombre minimum de points MinPts. Cette forme de
voisinage est déterminée par le choix d’une fonction de distance de 2 points p et q, noté
dist(p,q).
Figure 17: Clustering par DBSCAN
DBSCAN (Density-Based Spatial Clustering of Applications with Noise) est un
algorithme qui a été conçu pour découvrir les clusters et le bruit dans une base de données
spatiale [31]. Parmi ses points forts, c’est qu’il s’applique aussi bien dans un espace 2D, 3D
euclidien ou aux espaces comportant de nombreuses dimensions. Pour trouver un cluster,
DBSCAN commence par un point p choisit arbitrairement et recherche tous les points de densité
accessibles à partir de p. Si p est un point central, la procédure ajoute p au cluster. Si p est un
point de bordure alors aucun point n’est atteignable à partir de ce point et DBSCAN visitera le
prochain point de la base de données. Grâce à l’utilisation des valeurs globale 𝜀 et MinPts,
DBSCAN peut fusionner 2 clusters dans le cas où 2 clusters de densité différente se trouvent
proches l’un de l’autre. Deux ensembles de points ayant au moins la densité la plus petite seront
séparés l’un de l’autre si la distance entre les deux est plus large que 𝜀. En conséquence, un
appel récursif de DBSCAN peut se révéler nécessaire pour les clusters détectés avec la plus
haute valeur de MinPts [31]. Cela n’est pas forcément un inconvénient car l’application
31
récursive de DBSCAN reste un algorithme basique, et n’est nécessaire que sous certaines
conditions. Ainsi, pour chaque objet que l’on ajoute, on a une zone de croissance qui va
permettre d’étendre le cluster. Évidemment plus cette zone (une sphère) est grande, plus le
cluster aura de chances de s’étendre. La notion de voisinage est la clé de cette méthode. On
forme donc le cluster de proche en proche. La difficulté que nous pouvons rencontrer c’est le
choix de la taille de la zone (rayon de la sphère) d’extension.
4.3
Extraction de patrons de permissions
Dans cette section, nous détaillons notre approche pour détecter des patrons d'utilisation de
permissions. Nous fournissons en premier lieu une définition plus approfondie des patrons
d'utilisation de permissions et de leur représentation dans notre approche, ensuite nous
décrivons l’utilisation de l’algorithme DBSCAN pour nous permettre d’identifier les patrons
d’utilisation de permissions dans le contexte de notre base de données.
Nous définissons un Patron d'Utilisation de Permissions (PUP) en tant que groupe (c'est-à-dire,
un cluster) de permissions que le système Android utilise pour contrôler les privilèges d'accès
à des informations sensibles par les applications. Un Patron d'Utilisation de Permissions (PUP)
est un ensemble de permissions que le développeur doit déclarer lors de l'implémentation de
l'application. Ces permissions spécifient les ressources sensibles que l'application peut utiliser.
Cependant, il est impossible d'analyser tous les scénarios d'utilisations possibles des
permissions, en raison de leurs grands nombres et leurs utilisations variées. Nous avons besoin
ainsi d'une technique permettant d'identifier les patrons d'utilisation de permissions
indépendamment du scénario de déclaration de la permission dans le code source de
l’application. Par conséquent, notre méthode d'identification des patrons d'utilisation de
permissions doit :
•
Capturer les interférences dans les relations de co-utilisation entre les permissions des
applications
•
Isoler les bruits par rapport au degré de relations de co-utilisation dans les patrons
détectés.
Notre approche prend en entrée les applications à étudier et les permissions utilisées par
chacune des applications. Les résultats de notre approche sont un ensemble de patrons
d'utilisation de permissions. L'approche de détection des patrons d'utilisation de permission se
32
déroule comme suit. Comme première étape, le fichier manifeste.xml de l'application est
analysé de manière statique pour extraire les permissions utilisées par une application. L'analyse
statique est réalisée en utilisant l'outil APK-Analyzer. Pour la deuxième étape, nous calculons
les vecteurs d'utilisation pour l'application. Chaque application est caractérisée par un vecteur
d'utilisation qui code les informations liées aux demandes de permissions de l’application. Enfin
dans la dernière étape, nous utilisons l'analyse de Clustering pour regrouper les demandes de
permissions les plus souvent co-utilisées par les applications.
Dans notre approche, nous représentons l'ensemble de données des demandes de permissions
des applications comme une matrice binaire avec N le nombre de lignes étant le nombre
d'applications, et D le nombre de colonnes étant le nombre total de permissions possibles
x∈{0, 1}𝑁×𝐷 .
L'entrée 𝑥𝑖𝑑 = 1 signifie que l'application i demande la permission d. La ligne 𝑥𝑖∗ ∈ {0, 1}𝐷
représente toutes les permissions requises de l'application i. Par exemple, dans le tableau 2,
nous représentons une matrice d'utilisation de sept permissions par cinq applications. Le vecteur
d’utilisation de permissions montre que l’application 1 utilise les quatre permissions suivantes∶
𝑝𝑒𝑟𝑚1, 𝑝𝑒𝑟𝑚2 , 𝑝𝑒𝑟𝑚5 , et 𝑝𝑒𝑟𝑚6, on peut remarquer que ces permissions sont également
utilisées par l’application 2 et l’application 4.
Tableau 2: Matrice d'utilisation de cinq applications avec sept permissions
App/perm
𝑝𝑒𝑟𝑚1
𝑝𝑒𝑟𝑚2
𝑝𝑒𝑟𝑚3
𝑝𝑒𝑟𝑚4
𝑝𝑒𝑟𝑚5
𝑝𝑒𝑟𝑚6
𝑝𝑒𝑟𝑚7
𝑎𝑝𝑝1
1
1
0
0
1
1
0
𝑎𝑝𝑝2
1
1
1
0
1
1
0
𝑎𝑝𝑝3
0
1
1
0
1
0
0
𝑎𝑝𝑝4
1
1
1
0
1
1
0
𝑎𝑝𝑝5
0
0
0
1
0
0
1
DBSCAN construit des groupes de permissions en regroupant ceux qui sont proches les unes
des autres et forment une région dense. À cette fin, nous définissons la distance euclidienne
entre deux permissions p et q :
2
𝑑Eucl (𝑝, 𝑞)=√∑𝑁
𝑖=1(𝑝𝑖 − 𝑞𝑖 )
33
DBSCAN a besoin ainsi de deux paramètres pour effectuer le Clustering. Le premier paramètre
est le nombre minimum de permissions par un cluster. Nous l'avons fixé à deux, de sorte qu'un
patron d'utilisation doit inclure au moins deux permissions. Le deuxième paramètre, epsilon 𝜀,
est la distance maximale à l'intérieur de laquelle deux permissions peuvent être considérées
comme voisines l'une de l'autre. En d'autres termes, la valeur epsilon contrôle la densité
minimale qu'une région en cluster peut avoir. Plus la distance entre les permissions d'un cluster
est courte, plus le cluster est dense.
Dans DBSCAN, la valeur du paramètre epsilon influence énormément les clusters résultants.
En effet, dans notre approche, pour epsilon égal à 0, ça signifie que chaque cluster doit contenir
uniquement des permissions qui sont complètement similaires (c'est-à-dire que la distance entre
les permissions appartenant au même cluster doit être 0). La relaxation du paramètre epsilon va
détendre la contrainte sur la densité demandée dans les clusters cherchés. D'une part, si nous
attribuons à epsilon une petite valeur fixe, cela produira des patrons d'utilisation très denses.
Cependant, les patrons d'utilisation résultants ne captureront pas les interférences dans les
relations de co-utilisation entre les permissions de l’application : un patron d'utilisation inclura
seulement les permissions qui sont toujours co-utilisées ensemble. D'autre part, en fixant
epsilon à une valeur relativement grande, DBSCAN risque de produire des patrons d'utilisation
qui incluent certains bruits.
4.4
Étude de cas
Dans notre approche, nous avons exploité un logiciel open source, SPMF [32], qui
représente une bibliothèque d’exploration de données écrites en Java et propose des
implémentations de 224 algorithmes d’exploration des données. Nous avons utilisé SMPF à
partir des lignes de commande pour appliquer l’algorithme de DBSCAN comme illustre la
figure 18, mais avant tout, nous avons créé notre base de données.
Figure 18: Ligne de commande pour exécuter DBSCAN
34
4.4.1
Ensemble de données
Nous avons commencé à partir d'un ensemble de données existant exploré depuis le
Google Play Store en 2014 par un outil appelé PlayDrone[33]. Ce dernier est un système qui
utilise diverses techniques de piratage pour contourner la sécurité de Google afin d'explorer
avec succès Google Play. Pour l'étude de l'utilisation de la permission, nous avons nettoyé
l'ensemble de données pour conserver uniquement les applications disponibles. Pour réaliser
cette étape, nous avons utilisé APK-Downloader qui est un script écrit en Python et sert à
télécharger un nombre illimité d’APKs. Avant le téléchargement, nous avons analyser les
fichiers JSON de la base de données de PlayDrone pour avoir un lien de chaque APK appelé
(share-url) avec lequel on pourrait faire le téléchargement. À partir de ces liens nous avons
apporté quelques modifications à APK-Downloader pour qu’il puisse distinguer les APKs
disponibles et les télécharger d’un seul coup.
Notre base de données contient plus que 15000 applications utilisant plus que 200 permissions
différentes. Pour chaque application, nous extrayons les permissions utilisées par cette dernière.
Pour ce faire, nous décomposons l'APK de l'application et nous décodons les ressources en
utilisant l’outil APK-Analyzer qui est basé sur Apktool [34].
Nous avons donc créé un outil qui utilise les fichiers JSON résultant de APK-Analyzer pour
créer la matrice x ∈{0, 1}𝑁×𝐷 expliqué dans la section 4.3.
4.4.2
Application du Clustering
À partir de la matrice x ∈{0, 1}𝑁×𝐷 , notre outil écrit en Java créé un fichier texte sous
une forme bien déterminé pour qu’il soit l’entrée de l’algorithme DBSCAN. Pour simplifier,
nous avons créé une simple petite base de données composé de 11 applications et de 7
permissions et nous avons appliqué notre approche pour avoir le fichier texte montré dans la
figure 19.
Les premières lignes sont réservées pour les noms des applications de la base de données,
ensuite, chaque permission est décrite par deux lignes. La première ligne contient la chaîne
"@NAME=" suivie du nom de la permission, et la deuxième ligne fournit une liste de valeurs
séparées par des espaces simples. Ces valeurs correspondent respectivement aux applications,
si la première application utilise la permission alors on trouve comme première valeur 1.
35
Figure 19: Entrée de l'algorithme DBSCAN
En fixant MinPts=2 et 𝜀=2 nous avons appliqué le Clustering par DBSCAN et nous avons eu 2
patrons d’utilisation des permissions. Le premier patron contient {p3, p6, p1, p4, p7} et le
deuxième contient {p5, p2}. Le fichier de sortie de DBSCAN est présenté par la figure 20.
Figure 20: Sortie de l'algorithme DBSCAN
Nous avons donc appliqué la même démarche sur la grande base de données de 15000
applications et nous avons remarqué qu’à chaque fois on augmente la valeur de 𝜀 le nombre de
Clusters diminue comme illustre la figure 21, on trouve parfois des exceptions qui sont dues
aux bruits.
36
Figure 21: Dépendance du nombre de Clusters à la valeur d'Epsilon
4.4.3
Métriques
Sachant qu’un patron d’utilisation de permissions représente un groupe de permissions qui
sont toujours co-utilisées ensemble et une application associée à un patron implique que cette
application utilise une ou plusieurs permissions de ce patron, nous avons définis plusieurs
métriques pour analyser les résultats obtenus :
•
Pattern Usage Cohesion (PUC) :
PUC est inspiré de [35], les auteurs ont utilisé cette métrique pour évaluer la co-utilisation
des bibliothèques dans un patron d’utilisation. Dans notre cas nous avons besoin d’évaluer
la co-utilisation des permissions dans un patron d’utilisation de permissions, nous avons
donc définit PUC pour un patron d’utilisation p comme suit :
PUC(p) =
∑𝑎𝑝𝑝
𝑃𝑒𝑟𝑚(𝑝∩𝑎𝑝𝑝)
𝑃𝑒𝑟𝑚(𝑝)
𝐴𝑝𝑝(𝑝)
Avec app est l’une des applications associées à p, App(p) est le nombre d’application
associée à ce patron, Perm(p) est le nombre de permissions dans ce patron et Perm(p∩ 𝑎𝑝𝑝)
est le nombre de permissions de ce patron utilisées par l’application app.
Les valeurs PUC sont dans la plage [0,1]. Plus les permissions d’un même patron sont coutilisées ensemble, plus la valeur de PUC est grande. C'est-à-dire, un patron d’utilisation a
37
une cohésion d’utilisation est dite idéale (PUC=1) si tous ses permissions sont toujours
utilisés ensembles.
Figure 22: Exemple de calcul de PUC
•
Application Conformity to Patterns (ACP):
Nous nous sommes intéressés au calcul du score de conformité d’une application aux
patrons d’utilisation de permissions pour connaitre si les applications suivent des patrons
d’utilisations de permissions et jusqu’à quels points ces patrons suivis sont respectés. Pour
calculer le score de conformité d’une application aux patrons d’utilisation de permissions
auxquels elle est associée suite à l’application de notre approche, nous avons définit la
métrique suivante :
ACP (app) =
∑𝑝
𝑃𝑒𝑟𝑚(𝑝∩𝑎𝑝𝑝)
𝑃𝑒𝑟𝑚(𝑝)
𝑃(𝑎𝑝𝑝)
Avec P(app) est le nombre de patrons auxquels l’application est associée.
Une application ayant ACP=1 est une application qui utilise toutes les permissions dans les
patrons auxquels elle est associée. Elle est donc conforme aux patrons.
38
Figure 23: Exemple de calcul de la valeur ACP
Par exemple, dans la figure 23 qui présente la sortie de notre script de calcul de conformité,
{4=1} signifie que l’application org.premiumsecurity utilise une seule permissions du
Cluster numéro 4.
•
Generalizability of a Pattern (GP):
Un patron d’utilisation des permissions est dit généralisable s’il est caractérisé par une
valeur de PUC élevé dans le contexte de différentes bases de données.
Pour décider si un patron est généralisable ou non, nous avons divisé notre base de données
en 3 parties (Base1, Base2, Base3) et nous avons appliqué notre approche sur chacune de
ces bases de données pour avoir son ensemble de patrons d’utilisation des permissions. Puis,
nous avons cherché les patrons généralisables.
Nous avons commencé par calculer les valeurs de PUC des patrons de Base1, les résultats
sont illustrés dans la figure suivante :
39
Figure 24: Calcul de la valeur PUC pour Base1
Avec une valeur MinPts=2 et 𝜀=10 nous avons obtenus 3 patrons d’utilisation des
permissions, deux de ces patrons ont des valeurs de PUC élevés :
{READ_CALENDAR, WRITE_ CALENDAR} avec PUC=0.92105263
{READ_EXTERNAL_STORAGE,
WRITE_
EXTERNAL_STORAGE}
avec
PUC=0.99734247
Ensuite nous avons calculé les valeurs de PUC des trois patrons dans les autres bases de
données. Nous avons obtenu les résultats dans les figures 25 et 26 suivantes :
Figure 25: Calcul de la valeur PUC pour Base2
{READ_CALENDAR, WRITE_ CALENDAR} avec PUC=0.90957445
{READ_EXTERNAL_STORAGE,
WRITE_
EXTERNAL_STORAGE}
avec
PUC=0.99666
40
Figure 26: Calcul de la valeur PUC pour Base3
{READ_CALENDAR, WRITE_ CALENDAR} avec PUC=0.91129035
{READ_EXTERNAL_STORAGE,
WRITE_
EXTERNAL_STORAGE}
avec
PUC=0.9968355
Les résultats obtenus montrent que ces deux patrons sont généralisables, c'est-à-dire les
permissions qu’ils contiennent sont généralement utilisés ensemble. Pour l’autre patron qui
contient 228 permissions, il n’est pas généralisable puisque la co-utilisation de ses
permissions est très faible.
Toutes les figures précédentes de cette partie sont les résultats des algorithmes que nous avons
écrits pour calculer les métriques et pouvoir analyser nos données. Ces algorithmes sont écrits
en Java et ils prennent comme entrée la sortie de l’algorithme DBSCAN qui est un fichier texte
contenant les patrons d’utilisation des permissions. L’algorithme de GP nécessite aussi le
fichier CSV qui contient la matrice de la base de données dans laquelle nous testons la
généralisabilité des patrons.
4.4.4
Recommandation des permissions
À la fin de notre projet, nous avons essayé de trouver la relation entre les permissions
utilisées par une application Android et sa consommation énergétique. En plus, nous avons
cherché à aider le développeur en lui proposant des permissions probablement utiles pour son
application et à augmenter la conscience de l’utilisateur sur l’importance des permissions et
leur impact sur l’autonomie de la batterie de son mobile.
Pour cela, nous avons considéré les dix applications du troisième chapitre puisque nous avons
déjà les valeurs de la consommation énergétique de chacune d’entre elles. Pour chaque
application, nous avons pris la liste des permissions utilisées et nous l’avons divisé par deux, la
première partie présente l’entrée du système de recommandation (𝐿𝑆𝑦𝑠𝑅𝑒𝑐 ) et l’autre partie
41
présente les permissions à recommander (𝐿𝑃𝑅𝑒𝑐 ), le principe est de faire semblant qu’on ne
connaît que la première partie et on doit pouvoir faire des recommandations de permissions à
cette application qui existent réellement dans la deuxième partie.
Nous avons écrit un algorithme qui suit les étapes suivantes : à partir de la grande base de
données, on prend les patrons d’utilisation à condition que chacun de ces patrons contient au
moins une permission de 𝐿𝑆𝑦𝑠𝑅𝑒𝑐 et on calcule l’indice de recommandation de chacune des
permissions des patrons considérés.
Pour avoir l’indice de recommandation d’une permission, au début, on calcule les distances
euclidiennes entre cette permission et chacune des permissions dans la 𝐿𝑆𝑦𝑠𝑅𝑒𝑐 , puis on prend
la valeur minimale de ces distances, cette valeur présente l’indice de recommandation, elle
s’écrit donc comme suit :
IndRec(p)= min {𝑑𝑒𝑢𝑐𝑙 (𝑝, 𝑝𝑒𝑟𝑚𝑖 ) / 𝑝𝑒𝑟𝑚𝑖 ∈ 𝐿𝑆𝑦𝑠𝑅𝑒𝑐 }
Nous classons les permissions des patrons en fonction de leur indice de recommandation, plus
le IndRec est faible, plus la permission est susceptible d’être parmi la liste des permissions à
recommander.
La figure 27 présente une partie de la sortie de notre algorithme, pour une application
org.iii.romulus.meridian, avec Input représente 𝐿𝑆𝑦𝑠𝑅𝑒𝑐 et GroundTruth représente 𝐿𝑃𝑅𝑒𝑐 .
Figure 27: Exemple de résultat de recommandation
Pour évaluer le classement, nous avons défini deux métriques :
Recall rate@k =
∑𝑎𝑝𝑝 𝑖𝑠𝐶𝑜𝑟𝑟𝑒𝑐𝑡(𝑎𝑝𝑝,𝑇𝑜𝑝−𝑘)
𝑁
Avec Top-k est la liste des k permissions ayant les plus faibles valeurs de IndRec, en se basant
sur [36] on peut choisir une valeur de k= 1,3,5,7 ou 10, et on a N le nombre d’application qui
42
cherchent des recommandations. isCorrect(app,Top-k)=1 si au moins l’une des permissions
dans Top-k est utilisée dans app.
Mean reciprocal rank (MRR) =
1
𝑁
∑𝑁
𝑖=1
1
𝑟𝑎𝑛𝑘𝑖
Avec 𝑟𝑎𝑛𝑘𝑖 est le rang de la première recommandation pertinente pour l’application, c'est-àdire, le rang de la première permission qui existe réellement dans 𝐿𝑃𝑅𝑒𝑐 .
Figure 28: Recommandation en se basant sur Base1
Figure 29: Recommandation en se basant sur Base2
Figure 30: Recommandation en se basant sur Base3
Les figures 28, 29 et 30 montrent que le changement de la base de données n’a pas changé le
fait que l’algorithme a réussi à faire des recommandations pertinentes seulement pour les
applications les moins consommatrices en énergie, c'est-à-dire, les applications gourmandes en
énergie ne suivent pas les patrons d’utilisation des permissions.
Pour la valeur de Recall Rate, nous avons toujours eu la même valeur, car, sur les dix
applications, même si on change la base de données et par la suite, on change les patrons
d’utilisation trouvé, on a pu trouver que deux recommandations pertinentes qui sont parmi les
Top-k.
Exemple des recommandations pertinentes faites par notre algorithme :
•
𝐿𝑆𝑦𝑠𝑅𝑒𝑐 ={INTERNET} l’algorithme a recommandé ACCESS_NETWORK_STATE,
43
•
𝐿𝑆𝑦𝑠𝑅𝑒𝑐 ={READ_EXTERNAL_STORAGE} nous avons eu comme recommandation
pertinente WRITE_ EXTERNAL_STORAGE
•
𝐿𝑆𝑦𝑠𝑅𝑒𝑐 = {INTERNET, ACCESS_NETWORK_STATE, RESTART_PACKAGES} la
recommandation été PACKAGE_USAGE_STATS.
4.5
Conclusion
Ce chapitre présente une nouvelle technique qui identifie les patrons d’utilisations de
permissions. Nous avons appliqué quelques métriques pour analyser les patrons trouvés tels
que la co-utilisation des permissions, la généralisabilté du patron et la conformité. Nous avons
proposé en plus une méthode de recommandation des permissions qui a prouvé son efficacité
dans les cas des applications non gourmande en énergie.
44
CHAPITRE 5 : CONCLUSION ET PRESPECTIVES
Aujourd'hui, plus de 2 milliards d'utilisateurs utilisent des smartphones et des tablettes
pour effectuer leurs activités quotidiennes. De ce fait, la consommation d'énergie devient un
facteur critique de la satisfaction des utilisateurs, pour cela, nous proposons PETRA, un outil
spécifique à Android pour estimer la consommation énergétique des applications mobile, qui
s’appuie sur des outils accessibles au public. Nous avons donc utilisé des scénarios
représentatifs pour exécuter les applications et estimer la consommation d’énergie de chaque
méthode appelée, ensuite, nous avons additionné ces valeurs pour avoir la valeur d’énergie
consommée par chaque application au cours de son test.
Nous avons proposé aussi une approche qui permet d’identifier des patrons d’utilisation de
permissions. L’approche décrite est basée sur l’algorithme de Clustering DBSCAN, il s’agit
d’un algorithme basé sur la densité, c'est-à-dire les clusters sont formés en reconnaissant des
régions denses de points dans l'espace de recherche. L'idée principale est que chaque point à
regrouper doit avoir au moins un nombre minimum de points dans son voisinage. En d'autres
termes, l'algorithme regroupe uniquement les points pertinents et omet les points bruyants.
Dans notre approche, nous représentons l'ensemble de données des demandes de permissions
des applications par une matrice binaire avec N le nombre d'applications, et D le nombre total
de permissions possibles x ∈ {0, 1}𝑁×𝐷 . Les résultats de notre approche sont un ensemble de
patrons d'utilisations de permissions.
L'approche de détection des patrons d'utilisation de permission se compose de trois phases :
L’analyse du fichier manifeste.xml de chaque application pour extraire les permissions utilisées,
le calcul du vecteur d’utilisation de permissions pour chacune des applications étudiées et enfin
l’application de la méthode de Clustering pour regrouper les demandes de permissions les plus
souvent co-utilisées par les applications.
Nous avons réalisé une étude de cas sur plus de 200 permissions pour plus de 15 000
applications de Google Play Store. Notre étude de cas avait pour but d’identifier des patrons
d’utilisation de permissions et de vérifier jusqu’à quel point les patrons identifiés sont suivis
par les applications. Nous avons calculé pour chaque patron un score de co-utilisation PUC.
45
Selon les valeurs de PUC trouvées pour un patron dans différentes bases de données, nous avons
pu déterminer les patrons généralisables. Nous avons calculé aussi pour chaque application un
score de conformité aux patrons pour savoir à quel niveau ces patrons sont suivies par les
applications.
Nous avons également effectué une étude empirique des permissions dans les applications
Android. Cette étude avait pour but de trouver une méthode de recommandation des
permissions. L’étude a démontré que les recommandations faites, sont pertinentes que pour les
applications non-consommatrices en énergie.
Notre étude est bénéfique pour les utilisateurs et les développeurs puisqu’elle permet à
l’utilisateur de comprendre les permissions et de consacrer plus d’attention à ces dernières pour
protéger son périphérique et ses informations personnelles. Quant aux développeurs, elle leur
permet des recommandations pertinentes en assurant le bon fonctionnement des applications.
Malgré ces résultats très encourageants, il existe de nombreuses pistes d’amélioration qui
méritent d’être explorées. Dans de futurs travaux, nous comptons à calculer la consommation
énergétique d’autre application pour généraliser nos résultats et augmenter aussi la base de
données pour avoir plus des patrons d’utilisation de permissions généralisables.
46
Bibliographie
[1] IDC, (2015) IDC: Smartphone OS Market Share. Disponible en ligne à :
http://www.idc.com/promo/smartphone-market-share/os (Consulté : 20 Septembre 2021).
[2] A. Pathak, Y. Hu, and M. Zhang. Where is the energy spent inside my app? fine grained
energy accounting on smartphones with eprof. In EuroSys’12, pages 29–42, 2012.
[3] A. Pathak, A. Jindal, Y. Hu, and S. P. Midkiff. What is keeping my phone awake?
characterizing and detecting no-sleep energy bugs in smartphone apps. In MobiSys’12, pages
267–280, 2012.
[4] K. W. Y. Au, Y. F. Zhou, Z. Huang, and D. Lie. Pscout: analyzing the android permission
specification. In ACM Conference on Computer and Communications Security (CCS), pages
217–228.
[5] A. Porter Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagner. Android Permissions:
User Attention, Comprehension, and Behavior. In Proceedings of the 8th Symposium on Usable
Privacy and Security, 2012.
[6] Mitacs. https://www.mitacs.ca/fr/news-type/media-kit?language=fr
[7] Université Laval. https://immigrantquebec.com/fr/identifier/universite-laval
[8] Architecture du système Android. https://www.geeksforgeeks.org/android-architecture/
[9] Radoniaina ANDRIATSIMANDEFITRA RATSISAHANANA. Caractérisation et
détection de malware Android basées sur les flux d’information. Thèse de doctorat.
[10]
Android
Developpers,
Requesting
Permissions,
Disponible
en
ligne
à
:
https://developer.android.com/guide/topics/permissions/requesting.html
[11]
Android
developpers,
disponible
en
ligne
à
:
https://developer.android.com/guide/topics/manifest/uses-permission-element.html (Consulté :
20 Septembre 2021).
47
[12]
Android,
(2017)
Application
Security,
disponible
en
ligne
à
:
https://source.android.com/security/overview/app-security (Consulté: 20 Septembre 2021).
[13] Android Marshmallow, (2016) Android – Marshmallow. Disponible en ligne à :
https://www.android.com/versions/marshmallow-6-0/?gclid=CjwKEAiAgKu2BRDu1OGw3KXokwSJAB_Yy2QVhdelA0Y2awKEncwMwxQp8_wTKfH8FlO_KG2N9pWWBoCp_Pw_
wc (Consulté : 21 Septembre 2021).
[14] R. Amadeo, (2015) Android 6.0 Marshmallow, thoroughly reviewed. Disponible en ligne
à : http://arstechnica.com/gadgets/2015/10/android-6-0-marshmallow-thoroughly- (Consulté :
21 Septembre 2021).
[15] J. Flinn and M. Satyanarayanan, “Powerscope: A tool for profiling the energy usage of
mobile applications,” in WMCSA’99, 1999, pp. 1–9.
[16]
Moonsoon-solutions.
power
monitor.
[Online].
Available:
http://www.msoon.com/LabEquipment/PowerMonitor/
[17] M. Linares-Vasquez, G. Bavota, C. Bernal-C ´ ardenas, R. Oliveto, ´ M. Di Penta, and D.
Poshyvanyk, “Mining energy-greedy api usage patterns in android apps: An empirical study,”
in Proceedings of the 11th Working Conference on Mining Software Repositories, ser. MSR
2014.
New
York,
NY,
USA:
ACM,
2014,
pp.
2–11.
[Online].
Available:
http://doi.acm.org/10.1145/2597073.2597085
[18] T. Do, S. Rawshdeh, and W. Shi, “ptop: A process-level power profiling tool,” in in
Proceedings of the 2nd Workshop on Power Aware Computing and Systems (HotPower09,
2009.
[19] S. Hao, D. Li, W. G. J. Halfond, and R. Govindan, “Estimating mobile application energy
consumption using program analysis,” in Proceedings of the 2013 International Conference on
Software Engineering, ser. ICSE ’13. Piscataway, NJ, USA: IEEE Press, 2013, pp. 92–101.
[Online]. Available: http://dl.acm.org/citation.cfm?id=2486788.2486801
[20] D. Di Nucci, F. Palomba, A. Prota, A. Panichella, A. Zaidman and A. De Lucia, "PETrA:
A Software-Based Tool for Estimating the Energy Profile of Android Applications," 2017
IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C),
2017, pp. 3-6, doi: 10.1109/ICSE-C.2017.18.
48
[21] D. Di Nucci, F. Palomba, A. Prota, A. Panichella, A. Zaidman and A. De Lucia, "Softwarebased energy profiling of Android apps: Simple, efficient and reliable?," 2017 IEEE 24th
International Conference on Software Analysis, Evolution and Reengineering (SANER), 2017,
pp. 103-114, doi: 10.1109/SANER.2017.7884613.
[22] M. Frank, B. Dong, A. P. Felt, and D. Song. Mining permission request patterns from
Android and Facebook applications. In Proc. of the Data Mining (ICDM), 2012 IEEE 12th
International Conference on, 2012.
[23] BatteryStats. https://developer.android.com/studio/profile/battery-historian.html
[24] Systrace. https://developer.android.com/studio/profile/systrace-commandline.html
[25] Dmtracedump. https://developer.android.com/studio/profile/traceview.html
[26] Monkey. http://tinyurl.com/gvnxdd3
[27] MonkeyRunner. https://developer.android.com/studio/test/monkeyrunner/index.html
[28] APK-Downloader. https://github.com/HamidrezaMoradi/APK-Downloader
[29] APK-Analyzer. https://github.com/MartinStyk/ApkAnalyzer#Analyze_APKs
[30] Matthieu FOUQUIN (2004) DATAMINING C4.5 – DBSCAN. Disponible en ligne à :
http://devezeb.free.fr/downloads/ecrits/datamining.pdf (Consulté : 20 Septembre 2021)
[31] M. Ester, H. peter Kriegel, and X. Xu, “A density-based algorithm for discovering clusters
in large spatial databases with noise,” in International Conference on Knowledge Discovery
and Data Mining, 1996, pp. 226–231.
[32] SPMF. https://www.philippe-fournier-viger.com/spmf/
[33] Nicolas Viennot, Edward Garcia, and Jason Nieh. 2014. A measurement study of google
play.
SIGMETRICS
Perform.
Eval.
Rev.
42,
1
(June
2014),
221–233.
DOI:
https://doi.org/10.1145/2637364.2592003
[34] Apktool. Disponible en ligne à : https://ibotpeaches.github.io/Apktool/ (Consulté : 20
Novembre 2021)
49
[35] SAIED, Mohamed Aymen; OUNI, Ali; SAHRAOUI, Houari A.; KULA, Raula Gaikovina;
INOUE, Katsuro; and LO, David. Improving reusability of software libraries through usage
pattern mining. (2018). Journal of Systems and Software. 145, 164-179. Research Collection
School Of Information Systems.
[36] Avazpour, I., Pitakrat, T., Grunske, L., Grundy, J., 2014. In: Robillard, M.P., Maalej, W.,
Walker, R.J., Zimmermann, T. (Eds.), Recommendation Systems in Software Engineering.
Springer Berlin Heidelberg, pp. 245–273. https://doi.org/10.1007/978- 3-642-45135-5_10 .
50