Bonnes pratiques pour les applications Android

Les bonnes pratiques abordées dans cet article améliorent la compatibilité entre Citrix Endpoint Management™ et les applications mobiles pour les appareils Android.

SDK d’application MDX et encapsulage

Si votre application utilise le SDK d’application MDX, vous devez utiliser la version correspondante du MDX Toolkit pour l’encapsulage. Une incompatibilité de version entre ces deux composants pourrait entraîner un fonctionnement incorrect.

• Pour éviter une telle incompatibilité, encapsulez l’application avec un type d’application Premium ou Général. Cela vous permet de livrer une application pré-encapsulée. Ainsi, votre client n’aura pas besoin d’encapsuler l’application, évitant ainsi l’utilisation d’un MDX Toolkit incompatible. Pour plus de détails sur l’encapsulage des applications, consultez Encapsulage des applications mobiles Android.

Ne bloquez pas le thread principal

Vous ne devez pas utiliser de code bloquant lors de l’exécution sur le thread principal. Il s’agit d’une directive de Google, mais elle est encore plus cruciale avec Citrix Endpoint Management. Certaines actions peuvent prendre plus de temps dans une application gérée ou même bloquer l’exécution ultérieure du thread.

Le code bloquant inclut, sans s’y limiter, les éléments suivants :

• Opérations de fichier ou de base de données
• Opérations réseau

Pour être clair, toutes les méthodes de cycle de vie des applications, telles que onCreate, s’exécutent sur le thread principal.

Google fournit une API StrictMode qui peut aider à détecter le code bloquant. Pour plus de détails, consultez cet article de blog : https://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html.

• Écrivez un code robuste

En particulier, vous devez vérifier les valeurs de retour ou intercepter les exceptions des API du framework. Bien qu’il s’agisse d’une bonne pratique de programmation courante, elle est particulièrement importante pour les applications gérées.

Diverses API que vous vous attendez à voir toujours fonctionner échoueront si les stratégies de Citrix Endpoint Management bloquent la fonctionnalité sous-jacente. Des exemples incluraient toutes les capacités décrites précédemment :

• Les API réseau échouent comme s’il n’y avait pas de réseau disponible.
• Les API de capteurs, telles que le GPS et la caméra, renvoient null ou lèvent une exception.
• Les intentions dirigées vers une application non gérée échouent.
• L’accès aux fichiers et aux bases de données peut échouer s’il est utilisé à partir du thread principal. Pour plus de détails, consultez les sections Assurer la compatibilité du chiffrement des données et Entropie utilisateur du chiffrement, plus loin dans cet article.

Lorsque vous rencontrez un échec, votre application doit gérer le problème avec élégance au lieu de planter.

Limitations de l’interception (hooking)

MDX injecte des fonctionnalités dans une application Android binaire en modifiant le code DEX dans l’APK. Plusieurs limites sont présentes :

• Citrix Endpoint Management pourrait ne pas gérer les classes de framework dépréciées des versions pré-4.0 du SDK Android. Assurez-vous d’éviter ces classes dépréciées.
• La plupart des fonctionnalités sont injectées dans les API du framework Java/Android. Le code natif (C/C++) n’est généralement pas géré. Une exception est que même pour le code natif, le chiffrement des fichiers se produit toujours.
• Le code natif qui utilise JNI pour accéder aux fonctionnalités Java doit uniquement cibler le code de l’application utilisateur. En d’autres termes, n’utilisez pas JNI pour invoquer directement des méthodes du framework Java ou Android. Utilisez plutôt le modèle de conception de proxy pour « encapsuler » la classe de framework souhaitée dans une de vos propres classes Java. Ensuite, invoquez votre classe à partir du code natif.

Assurer la compatibilité du chiffrement des données

-  L'une des principales fonctionnalités de MDX est que toutes les données persistantes sont chiffrées de manière transparente. Vous n'avez pas besoin de modifier votre application pour bénéficier de cette fonctionnalité et, en fait, vous ne pouvez pas l'éviter directement. L'administrateur a la possibilité de désactiver le chiffrement de manière sélective ou entièrement, mais l'application ne l'a pas.

-  C'est l'un des aspects les plus lourds de MDX et il nécessite une compréhension des points suivants :

• Le chiffrement des fichiers est présent pour tout le code Java et natif qui s’exécute dans des processus gérés.

• Certaines API de framework, telles que les lecteurs multimédias et la prise en charge de l’impression, s’exécutent en fait dans des processus de système d’exploitation distincts. Si vous utilisez une telle API, vous pourriez rencontrer des problèmes.

  • Exemple : Votre application enregistre un fichier sur le disque (chiffré) puis transmet une référence au fichier à une API multimédia. L’API multimédia tente de lire le fichier mais ne comprend pas le contenu chiffré. Elle échoue ou même fait planter l’application.
  • Exemple : Vous créez un handle de fichier (qui démarre un fichier chiffré) et le donnez à l’API de la caméra. Le processus de la caméra écrit directement des données non chiffrées dans le fichier chiffré. Lorsque votre application tente de lire ces données, les données sont déchiffrées, ce qui produit des données incohérentes.

• Une méthode de gestion des processus distincts consiste à déchiffrer un fichier avant de le transmettre à l’API pertinente. Ou si l’API écrit des données, vous la laisseriez écrire d’abord, puis vous la chiffreriez une fois l’API terminée. Quelques étapes sont nécessaires :

• 1. Désignez une zone qui restera non chiffrée. Vous devez documenter cela pour votre client, car un administrateur Citrix Endpoint Management doit créer une stratégie d’exclusion de chiffrement.
• 1. Pour déchiffrer, il vous suffit de copier le fichier de l’emplacement normal (chiffré) vers l’emplacement déchiffré. Notez que vous devez effectuer une copie d’octets et non une opération de déplacement de fichier.
• 1. Pour chiffrer, inversez la direction. Copiez des emplacements non chiffrés vers les emplacements chiffrés.
• 1. Supprimez le fichier non chiffré lorsqu’il n’est plus nécessaire.

• Le mappage mémoire n’est pas pris en charge pour les fichiers chiffrés. Si vous appelez une API qui effectue un mappage mémoire, elle échouera. Vous devez gérer l’erreur. Si possible, évitez l’utilisation directe et indirecte du mappage mémoire. Un cas notable d’utilisation indirecte est la bibliothèque tierce SqlCipher.

• Si vous ne pouvez pas éviter le mappage mémoire, l’administrateur doit spécifier une stratégie d’exclusion de chiffrement qui omet les fichiers pertinents. Vous devez documenter cette stratégie pour votre client.

• Le chiffrement ajoute une surcharge mesurable. Assurez-vous d’optimiser les E/S de fichiers pour éviter la dégradation des performances. Par exemple, si vous lisez et écrivez à plusieurs reprises les mêmes informations, vous pourriez vouloir implémenter un cache au niveau de l’application.

• Les bases de données ne sont que des fichiers et sont donc également chiffrées. Les performances peuvent également être un problème ici. La taille standard du cache de la base de données est de 2000 pages ou 8 mégaoctets. Si votre base de données est volumineuse, vous pourriez augmenter cette taille.

  • Le mode WAL de SQLite n’est pas pris en charge en raison de la limitation du mappage mémoire.

• Entropie utilisateur du chiffrement

Une option de Citrix Endpoint Management pour le chiffrement exige que l’utilisateur final saisisse un code PIN avant que la clé de chiffrement ne puisse être générée. Cette option est appelée entropie utilisateur. Elle peut causer un problème particulier pour les applications.

Plus précisément, aucun accès aux fichiers ou aux bases de données ne peut être effectué tant que l’utilisateur n’a pas saisi un code PIN. Si une telle opération d’E/S est présente à un emplacement qui s’exécute avant que l’interface utilisateur du code PIN ne puisse être affichée, elle échouera toujours. Il y a quelques implications :

• Maintenez les opérations de fichier et de base de données hors du thread principal. Par exemple, une tentative de lecture d’un fichier à partir de la méthode onCreate() de l’objet d’application échouera toujours.
• Les opérations en arrière-plan, telles que les services ou les fournisseurs de contenu, peuvent s’exécuter même si aucune activité d’application n’est présente. Ces composants en arrière-plan ne peuvent pas afficher l’interface utilisateur du code PIN et ne peuvent donc pas effectuer d’accès aux fichiers ou aux bases de données. Notez qu’une fois qu’une activité s’exécute dans l’application, les opérations en arrière-plan sont autorisées à effectuer des opérations d’E/S.

Il existe plusieurs mécanismes d’échec si la clé de chiffrement n’est pas disponible en raison de l’entropie utilisateur :

-  Si le thread principal accède à une base de données avant que le code PIN ne soit disponible, l'application est arrêtée.
-  Si un thread non principal accède à une base de données avant que le code PIN ne soit disponible, ce thread est bloqué jusqu'à ce que le code PIN soit saisi.

• Pour les accès non liés à la base de données démarrés avant que le code PIN ne soit disponible, l’opération d’ouverture échouera. Au niveau C, une erreur EACCES est renvoyée. En Java, une exception est levée.

Pour vous assurer que ce problème n’est pas présent dans votre application, testez avec l’entropie utilisateur activée. La propriété client Citrix Endpoint Management, Encrypt secrets using Passcode, ajoute l’entropie utilisateur. Vous configurez cette propriété client, qui est désactivée par défaut, dans la console Citrix Endpoint Management sous Configurer > Paramètres > Plus > Propriétés du client.

Réseau et micro-VPN

    -  Plusieurs options de stratégie Citrix Endpoint Management sont disponibles pour les administrateurs en matière de mise en réseau. La stratégie d'accès réseau empêche, autorise ou redirige l'activité réseau des applications.

    -  > Important :
    -  > > La version 18.12.0 du MDX Toolkit incluait de nouvelles stratégies qui combinaient ou remplaçaient des stratégies plus anciennes. La stratégie d'accès réseau combine l'accès réseau, le mode VPN préféré et l'autorisation de basculement du mode VPN. La stratégie de liste d'exclusion remplace la liste d'exclusion du tunnel partagé. La stratégie de session micro VPN requise remplace la session en ligne requise. Pour plus de détails, consultez [Nouveautés des versions précédentes](/fr-fr/mdx-toolkit/about-mdx-toolkit/whats-new.html#whats-new-in-earlier-releases).

Les options sont les suivantes :

    -  **Utiliser les paramètres précédents** : utilise par défaut les valeurs que vous aviez définies dans les stratégies antérieures. Si vous modifiez cette option, vous ne devez pas revenir à **Utiliser les paramètres précédents**. Notez également que les modifications apportées aux nouvelles stratégies ne prennent effet qu’une fois que l’utilisateur a mis à niveau l’application vers la version 18.12.0 ou ultérieure.
    -  **Bloqué** : les API de mise en réseau utilisées par votre application échoueront. Conformément à la directive précédente, vous devez gérer cet échec avec élégance.
    -  **Non restreint** : tous les appels réseau sont directs et ne sont pas tunnellisés.

• Tunnellisé - VPN complet : tout le trafic de l’application gérée est tunnellisé via Citrix Gateway.

Limitation : Citrix Endpoint Management ne prend pas en charge les serveurs de sockets. Si un serveur de sockets est en cours d’exécution au sein de l’application encapsulée, le trafic réseau vers le serveur de sockets n’est pas tunnellisé via Citrix Gateway.

Prise en charge des frameworks de développement d’applications mobiles

Certains frameworks d’applications présentent des problèmes de compatibilité avec Citrix Endpoint Management :

• Avec PhoneGap, le service de localisation n’est pas bloqué.
• SQLCipher ne fonctionne pas avec le chiffrement car il utilise le mappage de mémoire. Une solution consiste à ne pas utiliser SQLCipher. Une deuxième solution consiste à exclure le fichier de base de données du chiffrement à l’aide d’une stratégie d’exclusion de chiffrement. Un administrateur Citrix Endpoint Management doit configurer la stratégie dans la console Citrix Endpoint Management.

Conseils de débogage

Lors du débogage d’une application encapsulée, tenez compte de ces conseils.

• Déterminez si le problème est présent dans une version non encapsulée de l’application. Si le problème se produit lorsque l’application n’est pas encapsulée, utilisez les techniques de débogage normales.
• Essayez de désactiver diverses stratégies Citrix Endpoint Management.
  • Cela peut aider à localiser toute incompatibilité. La désactivation d’une stratégie signifie que MDX n’applique plus la restriction associée, ce qui vous permet de tester ces fonctionnalités comme si l’application n’était pas encapsulée.
  • Si la désactivation d’une stratégie résout le problème, il est possible que l’application ne vérifie pas les erreurs dans les API associées.
  • Si une application non modifiée mais re-signée ne s’exécute pas :
    1. Décompressez le contenu de l’APK à l’aide de JAR :

    [[CODE_BLOCK_0]]

  1. Supprimez le dossier META-INF :

     [[CODE_BLOCK_1]]

  2. Recompressez le contenu dans un nouvel APK à l’aide de JAR :

     [[CODE_BLOCK_2]]

  3. Signez le nouvel APK à l’aide de JARSIGNER :

     [[CODE_BLOCK_3]]

  4. Si l’application ne s’exécute toujours pas, vous ne pouvez pas encapsuler l’application à l’aide d’un certificat de signature différent de celui de l’APK d’origine utilisé.
     • Si un fichier .apk décompilé ou recompilé ne s’exécute pas :

  5. Décompilez et recompiliez à l’aide d’APKTOOL :

     [[CODE_BLOCK_4]]

     [[CODE_BLOCK_5]]

  6. Signez l’APK à l’aide de JARSIGNER comme décrit ci-dessus.

  7. Si l’application ne s’exécute toujours pas, il s’agit d’un bogue APKTOOL tiers.
• Si l’encapsulation d’application ne fonctionne pas :
  1. Essayez de supprimer le framework APKTOOL et de ré-encapsuler.
     • Mac/Linux : rm -rf ~/Library/apktool/framework
     • Windows : del /q /s C:\Users\{username}\apktool\framework
  2. Comparez l’APKTOOL utilisé par l’encapsuleur avec celui que vous avez utilisé pour décompiler et recompiler avec succès à l’étape précédente.
     • S’il s’agit de la même version d’APKTOOL, il y a un bogue dans Wrapper.
     • S’il s’agit d’une version différente d’APKTOOL, il peut y avoir un bogue dans l’APKTOOL intégré à l’utilitaire MDX Toolkit.
       1. Décompressez le contenu de ManagedAppUtility.jar.
       2. Écrasez avec le contenu d’APKTOOL.jar que vous avez utilisé pour encapsuler l’application avec succès à l’étape précédente.
       3. Recompressez le contenu dans un nouveau ManagedAppUtility.jar.
       4. Encapsulez l’application pour confirmer le bogue dans l’APKTOOL intégré.
• Exécutez l’application encapsulée et capturez les informations de journal.

  1. Utilisez grep pour examiner ce qui se passe dans l’application.

     Pour suivre les activités de l’application : grep “MDX-Activity”

     Pour suivre le verrouillage MDX de l’application : grep “MDX-Locked”

     Pour voir les deux journaux ensemble : egrep “MDX-Act

     MDX-Loc”

  2. S’il y a une erreur Application Not Responding, extrayez les traces ANR à l’aide d’ADB.

• Si un problème survient lors de l’interaction avec plusieurs applications, par exemple lors de l’utilisation de l’option Ouvrir dans :
  1. Vérifiez que les stratégies de chiffrement et les paramètres du groupe de sécurité sont les mêmes entre les applications.
  2. Essayez une autre application. Il peut s’agir d’un bogue dans l’une des applications testées.
  3. Capturez les journaux de toutes les applications impliquées. Notez que Secure Hub peut regrouper les journaux et envoyer par e-mail les journaux des applications individuelles. Depuis l’écran Mes applications, balayez vers la droite jusqu’à l’écran Support. Cliquez ensuite sur le bouton Besoin d’aide en bas de l’écran.

En plus des outils mentionnés ci-dessus, les éléments suivants peuvent également être utiles :

• AAPT pour vider les informations sur l’application.

  aapt dump badging {some.apk}

• Commande DUMPSYS sur l’appareil.

  adb shell dumpsys 2>&1 | tee {dumpsys.out}

• DEX2JAR pour recompiler les classes en pseudo-Java.

  dex2jar {some.apk}

  Convertir les classes des applications encapsulées Dual-Dex :

  apktool d {some.apk} -o {some.dir}

  dex2jar {some.dir}/assets/secondary-1.dex

• JD-GUI pour afficher le code pseudo-Java.

• BAKSMALI pour décompiler les classes d’applications à partir d’applications encapsulées Dual-Dex.

  • Décompiler l’APK encapsulé :

    apktool d {some.apk} -o {some.dir}

  • Décompiler les classes de l’application qui ne sont pas décompilées par l’appel ci-dessus :

    baksmali {some.dir}/assets/secondary-1.dex -o {some.dir}/smali