Dans l’univers d’Android
Nous vous partageons notre top 3 des conférences à retenir d’Android Makers 2019.
Android Makers 2019 : Top 3 des des conférences à retenir
C’est par un mardi ensoleillé que se déroule la 3ème édition d’Android Makers.
Le Beffroi de Montrouge voit ainsi affluer pour la seconde année consécutive 871 développeur·euse·s, designer·euse·s, product manager·euse·s et autres enthousiastes du petit robot vert. Record battu donc, puisque l’édition de l’année dernière avait réuni 816 visiteurs.
Habituée du rendez-vous depuis les défuntes DroidCon, la #teamLinkvalue composée d’Hugo, Julien et Thibault, décrypte pour vous l’évènement Android de l’année en France à travers ses talks les plus marquants.
Canary Leak 2.0 [in English]
Pour les fans des fuites mémoire (parce que les fuites on en a à tout âge), c’est un des must do de cette conférence.
Pour une restitution plus fidèle, on vous résume ce talk en anglais.
To sum up, more clarity and less interruption at runtime.
And more, a new Icon !
Clarity
If you knew the earlier version of Canary Leak, you probably remember these long dump stack trace painful to read.
A first step was done in 1.6.* version, which was helping us to Target the potential nodes (with red dashed.arrow) where the leaks does come from.
But even more now, it even raises some interesting state elements of the object like, is a fragment still attached and potentially tells you if it’s leaking, using the help of leakSentry
Further more, now leak are grouped, and counted which also can help you to know the number of occurence and give you a better visibility in the UI and allow you to evaluate the ‘gravity’ of a leak.
It nearly does all the jobs now! No more time consuming excuses =)
Dumping management
“Brrr, your apps is freezing.”
Well how much time did you saw that rounded grey square popping on your screen, to remind you how bad was your code?
It was a good thing, but annoying when you were busy, working on other issues and features. And as a result you were commenting the init line of leak canary or even removing it.
So what now?
Dumping and analysing start when the app goes background, or when 5 leaks has been set in stack.
And for those who still want to be able to enable or disable it, well now there is a dedicated method.
And more awesome stuff
But it doesn’t stop there! It’s now more that 99% in Kotlin ! So no more initialization code.
And a production leak trace (still experimental) and a new heap parser / perflib made for AS.
When can I use it
Go check on github, alpha is open since 23th april.
What’s inside my app?
Un retour à nouveau partagé en anglais, pour une meilleure restitution.
Do you really know your app ? Can you precisely say what your code does and doesn’t? You might think: yes of course, I wrote it.
Well, I’m pretty sure that you could be surprised, and for several reasons.
You might have not been in the project since the beginning of it
Even if most of the apps doesn’t have a really long life, their life can be long enough to have some old and forgotten code, written by some unknown developer from which remain only a weird name in git logs.
Maybe digging in these old lines can help you, and if you don’t want to do it, one day or another some bug, will force you to understand what’s going on.
You might not be alone on your project
Well, you all probably have worked in a team. And even if you know what every member do, you can miss some changes. And be surprised one day front of a bug, to find some guilty code lines.
In order maybe to reduce the risk in this case, Pull request are a good way to keep a track of what is going on in an app.
And if you don’t use PR, I recommend you to start as soon as you can. It’ll save you some trouble.
Also unit and functional test can help you to ensure some behavior.
Okay and?
Yes okay, but there is nothing really new here, and you might have been there from the beginning and/or have a complete knowledge of the code written, using pull request, and have a strong test coverage.
But still, you probably miss something!
Dependencies
There are everywhere, and after all, we won’t reinvent the wheel. There is a lot of them out there, working fine and well. And probably even better than what I could do ever alone.
But, here it becomes tricky: do you really know what is inside theses libs you include in your production apps in your client devices?
You’re probably less confident now.
But well, you’re smart and you took only well known trusted library, with a lot of stars on github, from popular repository like maven or jcenter.
Well then you probably know those next code lines:
repositories {jcenter()mavenCentral()maven { url ‘…’ }google()}
If not check here.
If yes, wonderful you are ready to have problems!
Did you know that the order of theses lines has as a meaning?
Well let’s say that you want to include a lib from a given repository:
repositories {jcenter()mavenCentral()maven { url ‘https://given.repo’ }google()}
and
dependencies {implementation ‘com.github.myGivenDependency:1.2.+’}
First if you still use + at the and of version name of your dependencies, please stop!
This can give you non-replicable bugs, unexpected crash from one day to another, dependency conflict, etc.
Well okay
dependencies {implementation ‘com.github.myGivenDependency:1.2.3’}
Fine, now guess what? There is no guarantee that you’ll get the givenDependency from the given.repo.
If jcenter() can provide you the dependency first it’ll do it. And if the version from there is malicious, then congrats you did inject the evil inside your app.
Do not think that’s over thinking, it is a common risk.
It used to happen for npm dependencies : postmortem, and well…. for Android : Confusing dependency.
Just that?
Yeah, in addition of handling perfectly your code behavior, you probably manage your gradle pretty well! Carefully, excluding version, dependencies, checking the last changes. And in that case congrats you’re very professional!
But is it enough?
Dependencies again!
Hell, these again, yeah, because they can be original one, from the good repository, used by thousands of people, made by big company and still!
Let’s randomly pick one, Firebase Performance Monitoring.
Google job, used by god knows how much, google() repo. Sound good and safe.
Well guess what, using tools like Transform Api plugin and Asm.ow2.io they took your code, modify it, wrap it, and inject some other. Giving them access to sensible data, and we’re fine with it!
Here is the full talk about it
I could continue further with other kind of dependency, for example screen registering sdk, like bugsee, appsee, which are fine but that should be handled carefully. And all of remote storing solution, etc…
And finally if you still are pretty sure of yourself, check about the Langton’s Ant, and guess if you can really predict your code behavior anyway =)
Le sandboxing applicatif d’Android
À noter que le job d’Adrien Grassein, le speaker de cette conf, est de porter Android sur plusieurs types de plateformes (ex : raspberry pi).
Mais qu’est-ce que le sandboxing déjà ?
Il s’agit d’isoler les apps les unes des autres.
Il faut dire que plusieurs raisons l’imposent :
- Éviter qu’un problème d’une app affecte les autres,
Une app qui crash ne doit pas faire crasher le système. - Éviter qu’une app puisse voir ce que font les autres,
C’est d’autant plus vrai aujourd’hui que nous avons de plus en plus d’apps comportant des données sensibles (ex : banque, données médicales). - Éviter qu’une application créée un déni de service (ex : reboot systématique).
Android est basé sur linux, qui utilise déjà beaucoup ces mécanismes.
Le postulat de base d’une app est que son code a besoin de mémoire RAM pour s’exécuter. Cette exécution peut s’arrêter pour diverses raisons (ex : mauvaise instruction).
Et bien que le contenu de cette mémoire peut-être privé, si le code a accès à toute la mémoire, il peut alors accéder à des informations privées et les altérer.
La solution proposée par Android est de séparer chaque programme dans son propre contexte d’exécution avec son propre espace mémoire (mémoire virtuelle).
Des mécanismes permettent ensuite de vérifier qu’une app ne sorte pas de son espace mémoire et de traduire les adresses virtuelles en adresses physiques.
Un des autres problèmes mentionné est la gestion des ressources du File System pour isoler les fichiers d’une app de ceux des autres. En effet, certains doivent se partager, tandis que d’autres doivent rester privés.
Android se base donc sur les mécanismes de linux pour la gestion des droits. Linux permet en effet de désigner un propriétaire et un groupe pour une ressource et de définir une politique d’accès à cette ressource.
Pour cela, chaque app se voit attribuer un uuid et gid afin d’identifier chaque utilisateur de ressources.
Chaque ressource dispose alors d’un propriétaire et d’un groupe.
Android se protège davantage en limitant les groupes des apps par rapport à une connexion shell, moins permissive qu’une distribution linux.
Multi process, Android passe par le biais de zygote forke pour regrouper les process qui font tourner les apps.
Mais comment communiquer entre process ?
La réponse est : Binder, qui va sérialiser pour le driver /dev/binder les informations à transmettre entre process.
Stockage et partage de fichiers volumineux
Jonathan Salamon, développeur Android chez Dashlane, est amené à travailler sur des fonctionnalités innovantes devant mêler performance et sécurité absolue. Une des problématiques sur laquelle il a eu l’occasion de travailler est le stockage et partage de fichiers. Et c’est donc sur cette problématique que celui-ci a basé son talk cette année.
Tout d’abord, il évoque que lors du développement d’une fonctionnalité telle que le stockage et partage de fichier, il est important de viser certains points importants :
- Les utilisateurs doivent pouvoir stocker leurs fichiers (Merci captain obvious 💪 !) quelles que soient leurs tailles et types, dans un espace sécurisé,
- Le stockage doit pouvoir se faire en local, mais également potentiellement dans le cloud,
- Tous les fichiers doivent être une boîte noire côté serveur, et peuvent seulement être lus une fois déchiffré par le propriétaire,
- En cas d’interception du/des fichiers, il faut qu’il devienne inutilisable.
Une fois ces objectifs posés sur papier, la phase de réflexion et de développement d’un système de stockage et de partage peut commencer.
Architecture Zero-Knowledge
Le choix le plus approprié d’architecture pour notre projet se tourne vers une architecture Zero-Knowledge.
Cette architecture consiste à chiffrer toutes les données avec un mot de passe dit ‘mot de passe maître’. Celui-ci sera seulement connu par l’utilisateur, non stocké et ne sera jamais échangé. Ainsi, toutes les opérations seront chiffrées (et déchiffrées) en local seulement. En cas de tracking, celui-ci se fait via des identifiants anonymes.
Chiffrement et déchiffrement
Pour chiffrer/déchiffrer de la donnée en Android, nous utiliserons une clé générée via SecretKeySpec. Un objet Chiper nous aidera à chiffrer/déchiffrer la donnée.
Pour donner une idée simplifiée de comment faire via quelques lignes de code :
kotlinval md = MessageDigest.getInstance(“SHA-256”)val masterPasswordHash = md.digest(“MasterPassword”.toByteArray())val key = SecretKeySpec(masterPasswordHash, “AES”)val cipher = Cipher.getInstance(“AES”)
Pour du chiffrement/déchiffrement classique, je me sers du chiper et de la clé chiffrée via le mot de passe maître. Cependant, lorsqu’un fichier pèse plusieurs Go, il n’est pas possible d’utiliser n’importe quel algorithme de chiffrement (du fait de la limite de taille).
Le chiffrement de fichier lourd a également un impact sur la mémoire et sur les performances. Enfin, il serait intéressant de ne pas dépendre des versions d’Android pour les algorithmes de chiffrement, et avoir la possibilité de chiffrer tous nos fichiers avec le même algo.
Le chiffrement par bloc va alors être une solution envisageable. En effet, celui-ci va permettre d’alléger la mémoire, d’alléger le CPU et de rendre les performances constantes.
Il faut alors mettre en place une fonction gérant les fichiers volumineux. Celle-ci se servira de bufferpour les inputs et outputs, avec une taille définie par l’utilisateur (par exemple, on chiffrera par bloc de 1024 bytes).
Pour faciliter l’utilisation des buffers, il est possible d’utiliser la bibliothèque okio, facilitant grandement l’utilisation des Input et OutputStream.
La fonction update du chiper nous servira à mettre à jour peu à peu le chiffrement de notre fichier à chaque fois qu’un bloc est chiffré.
kotlinfun writeBigFile(cipher: Cipher, input: Source, output: Sink, chunkSize: Long) {input.buffer().use { source ->output.buffer().use { out ->while (source.request(chunkSize)) {out.write(cipher.update(source.readByteArray(chunkSize)))}out.write(cipher.update(source.readByteArray()))out.write(cipher.doFinal())}}}val cipher = Cipher.getInstance(“AES/ECB/PKCS5Padding”)cipher.init(Cipher.DECRYPT_MODE, key)writeBigFile(cipher, inputStream.source(), outputFile.sink(), 1024L)
Enfin, il serait intéressant de pouvoir gérer les évolutions de nos algorithmes de chiffrement. Pour cela, on peut par exemple mettre en place un système d’en-tête sur nos fichiers chiffrés, afin de pouvoir garder une trace de l’algorithme de chiffrement utilisé (il n’est pas dangereux d’insérer ce genre de données chiffrées en en-tête de notre fichier).
Synchronisation
Pour la synchronisation de nos fichiers, il est important de mettre en place un système de droit de visibilité sur notre serveur. Pour le stockage en revanche, il ne s’agit pas de notre travail.
Une solution envisageable est de passer par les buckets proposés par AmazonS3.
On met alors en place un certain workflow :
- Envoi de l’id + la taille de contenu à notre serveur, qui lui-même questionnera Amazon afin d’allouer de la place pour notre fichier.
- Amazon va nous renvoyer un URL et des identifiants temporaires afin de pouvoir télécharger notre fichier.
- On peut alors envoyer directement notre fichier sur Amazon via le lien unique et temporaire reçu précédemment. Le fichier que l’on envoie est chiffré localement et il est possible de l’envoyer en multipart.
- Une fois notre transfert terminé sur Amazon, on en informe notre serveur.
Conclusion
En conclusion, ce système présenté plus haut (en version simplifiée certes) permet de facilement stocker et partager des fichiers, avec un faible impact sur la mémoire et les performances de notre application. De plus, ce système est facilement évolutif et localement, et dans le cloud.
Pirater un fichier devient complexe, car il va falloir obtenir une clé de téléchargement, usurper des droits temporaires et déchiffrer les fichiers sans avoir la clé.
Bien sûr, il reste toujours des failles et inconvénients à ce genre de système, le principal étant que le simple devient complexe. Par exemple, l’affichage d’un aperçu d’une image devient très complexe à implémenter alors qu’a priori ce n’est pas compliqué à réaliser.
Enfin, l’utilisateur peut toujours sortir de ce mode ‘sécurisé’ en téléchargeant des applications tierces non sécurisées et en leur donnant des accès multiples, mais il n’est pas possible de gérer ces cas.
Bravo à Jonathan pour sa simplification et sa manière d’aborder des sujets a priori complexes tel que le chiffrement/déchiffrement de données.
À l’année prochaine
Et pour les développeurs mobiles IOS ou simples curieux, nous vous invitons également à retrouver nos retours sur les talks de la conférence Dot Swift 2019.
De plus, nos collaborateurs participent régulièrement à des événements phares du monde de la Tech. N’hésitez donc pas à vous abonner à notre compte Medium pour suivre nos prochains retours de conférences et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
