L’utilisateur moyen d’Android a probablement depuis longtemps cessé de se soucier du « problème de fragmentation » d’Android. Mais le problème hante toujours les développeurs.
La fragmentation est littéralement un problème controversé sur Android depuis l'annonce du système d'exploitation mobile.
En plus d'être un outil que les trolls peuvent utiliser dans les guerres de flammes en ligne, la diversité qui accompagne la fragmentation est désormais largement considérée comme un problème. net positif pour les consommateurs des appareils Android. Après tout, nous disposons d'une telle liberté dans le choix du type d'appareil et du type de logiciel que nous souhaitons qu'il est difficile pour le consommateur moyen de se soucier de la fragmentation. Visualiser l'incroyable variété d'appareils Android produit une belle mosaïque de la représentation diversifiée d'Android.
Mais la fragmentation du matériel et des logiciels ne fait pas le bonheur des développeurs de logiciels. En fait, tout le contraire. Développer une application sur autant de configurations matérielles et logicielles différentes peut s'avérer être une nuisance majeure lors du débogage. Les OEM peuvent apporter des modifications majeures ou subtiles qui doivent être prises en compte lors du développement d'une application, mais il n'existe vraiment aucun moyen simple pour le développeur individuel de garantir que son application fonctionnera universellement. Alors que le consommateur moyen a depuis longtemps oublié le débat sur la fragmentation, le problème hante toujours Android. développeurs d'applications et il n'y a apparemment rien à faire à ce sujet, à part aspirer et gérer les erreurs au fur et à mesure qu'ils apparaître.
Le triste état de fragmentation
Un équipementier en particulier reçoit une grande part de haine pour les maux de tête qu'il provoque lors du développement d'une application: Samsung. Les développeurs se déchaînent sur Samsung depuis des années maintenant, certains écrivant même des articles aussi cinglants que "Il y a une place spéciale pour Samsung dans l’enfer Android" qui décrit un bug particulièrement frustrant provenant de Appareils Samsung et bibliothèque de compatibilité d'applications de support. Je voudrais attirer l'attention sur un paragraphe en particulier du discours de M. Ambri, qui explique parfaitement pourquoi les développeurs se soucient toujours de la fragmentation :
Si vous êtes un développeur Android, votre haine pour les appareils Samsung est probablement sans limites. Plus qu'un utilisateur moyen, pour qui Samsung est synonyme de Touchwiz idiot et bloatware excessif, vous méprisez Samsung parce que vous n’avez pas le choix. Grâce à Samsung part de marché massive, vous ne pouvez tout simplement pas choisir de ne pas prendre en charge les appareils Samsung. Et c’est ce qui fait le plus mal; le fait que ce choix vous est retiré !
Ce n'est pas non plus une diatribe des années anciennes d'existence d'Android - cet article a été publié à la mi-décembre de l'année dernière. Je vais être franc et déclarer que je ne suis pas sûr que ce problème ait encore été officiellement résolu, cependant, M. Ambri a fourni une solution dans son message à quiconque tombe sur son discours via une recherche Google pour le bogue. Tout ce que vous avez à faire est d'utiliser ProGuard avec la seule ligne de code suivante :
# Samsung ruining all nice things-keep class !android.support.v7.view.menu.**, !android.support.design.internal.NavigationMenu, !android.support.design.internal.NavigationMenuPresenter, !android.support.design.internal.NavigationSubMenu, android.support.** {*;}
Ce n'est pas si grave, n'est-ce pas? Le problème, cependant, est que ce correctif a été retiré de Stack Overflow. Ne vous méprenez pas, Stack Overflow est un excellent site Web. Mais ce n'est pas vraiment une source idéale pour découvrir des correctifs pour vos applications. Trouver quelque chose sur Stack Overflow implique souvent de plonger profondément dans les liens après de nombreuses recherches par essais et erreurs sur Google. Parfois, vous trouverez même un autre utilisateur mentionner le même bug que vous avez rencontré, mais sans solution en vue. Ou encore plus frustrant sont les moments où vous trouvez un fil de discussion dans lequel l'auteur original a prétendu ont trouvé une solution mais ils ont depuis longtemps abandonné leur fil de discussion sans indiquer aux autres comment résoudre le problème. problème.
Un exemple de problème de fragmentation subtil
Je ne suis pas moi-même développeur, mais je connais suffisamment les capacités d'Android après des années de bricolage dans Tasker pour avoir commencé à pseudo-programmer mes propres solutions aux problèmes auxquels j'ai été confronté. Et quand je n’arrive pas à comprendre quelque chose, je le recherche sur Google, comme tout le monde. Alors que j'étais en train de rédiger mon précédent article sur fouiller dans l'application Paramètres de votre téléphone pour rechercher des activités cachées, je suis tombé sur un bug assez étrange que je n'arrivais pas à expliquer. Un bug propre aux appareils Huawei.
Chaque fois que j'essayais de démarrer certaines activités (telles que le menu "Test" qui contient les statistiques d'utilisation de l'application) dans l'application Paramètres, je rencontrais toujours une erreur d'autorisation. En particulier, l'application que j'utilisais pour démarrer l'activité n'avait pas l'autorisation autorisation.huawei.android. HW_SIGNATURE_OR_SYSTEM. Aucun autre appareil que j'ai testé ne nécessitait d'autorisations uniques pour lancer ces activités de paramètres, uniquement les téléphones exécutant la version Android de Huawei (EMUI). Une analyse de com.android.settings a révélé que certaines activités au sein de l'application Paramètres étaient effectivement sous un niveau de protection qui nécessitait soit le signature ou autorisation système.
Malheureusement pour moi, cela signifie que seules les applications installées sous /system ou les applications signées avec le même signature car l'application Paramètres serait capable d'ouvrir ces activités en utilisant la méthode que j'étais tenter. Lorsque j'ai recherché cette erreur sur Google, je suis (vous l'avez deviné) tombé sur un Fil de débordement de pile. Le développeur qui a publié son problème a rencontré le même problème que moi (même si il était en train de développer une application). Son problème est survenu lorsqu'il a tenté d'exécuter le code suivant :
<span >Intentspan><span > mainIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_MAINspan><span >,span><span >nullspan><span >);span><span >mainIntentspan><span >.span><span >addCategoryspan><span >(span><span >Intentspan><span >.span><span >CATEGORY_LAUNCHERspan><span >);span><span >Intentspan><span > pickIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_PICK_ACTIVITYspan><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_TITLEspan><span >,span><span >"Pick App to Play in"span><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_INTENTspan><span >,span><span > mainIntentspan><span >);span><span >thisspan><span >.span><span >startActivityForResultspan><span >(span><span >pickIntentspan><span >,span><span > REQUEST_PICK_APPLICATIONspan><span >);span>
À en juger par les chaînes d'intention et la page Web du développeur, il essayait probablement de permettre à l'utilisateur de choisir une application tierce pour lire certains médias. Le correctif, fourni par un développeur vétéran CommonsWare, c'était assez simple: utiliser Intention. Créer un sélecteur au lieu de ACTION_PICK_ACTIVITY. Cependant, pourquoi devrions-nous avoir besoin de mettre en œuvre ce correctif? Pourquoi Est-ce que Huawei a besoin de cette autorisation en premier lieu? Pourquoi avions-nous besoin de trouver une réponse sur StackOverflow en utilisant une recherche Google très spécifique ?
Le paradoxe du choix
Pour trouver une réponse, CommonsWare a déposé un rapport de bug sur le outil de suivi des bogues Android demandant à Google d'examiner le problème. En particulier, le développeur a demandé à Google d'interdire les exigences d'autorisation non documentées pour empêcher les applications tierces d'accéder à ACTION_PICK_ACTIVITY. En écrivant ces exigences dans CTS, Huawei serait contraint de se conformer à ces changements.
Pour être honnête, cependant, ce bug en lui-même n’est pas vraiment un gros problème. Même si aucune autre application que j'ai essayée (telle que Tasker) n'a pu contourner cette autorisation exigence et lancer certaines activités dans l'application Paramètres, je n'ai pas été vraiment déçu par le résultat. Mais quand je me suis souvenu du discours de M. Ambri, j'ai réalisé que de petits changements comme ceux-ci devaient être très frustrants à gérer, surtout car aussi petits soient-ils, ils sont sans aucun douteadditionner, parfois suffisant pour provoquer un mal de tête. Un petit changement dans l'application Paramètres pourrait entraîner un avis négatif immérité contre un développeur. Un petit changement qui est plutôt mal documenté et qui m'a obligé à parcourir Internet à la recherche d'un fil de discussion Stack Overflow. Combien d’autres petits bugs y a-t-il sur d’autres appareils?
La concurrence accrue dans l'espace mobile s'est avérée bénéfique pour le consommateur, mais après avoir vu comment ces changements subtils dans tant de gammes de produits différentes peuvent affecter les développeurs, j'ai appris à apprécier le point de vue des développeurs sur fragmentation. Ce n’est pas le choix lui-même qui pose problème, mais plutôt le fait que la communauté n’en fait pas assez pour cataloguer ces problèmes. Comme M. Ambri l'a suggéré dans son article, les développeurs Android ont peut-être besoin de leur propre version de caniuse.com ou sdkcritic.com pour collecter tous les bogues obscurs dans une seule base de données. La seule autre alternative est d’amener les équipementiers à documenter correctement ces modifications ou à cesser de les apporter en premier lieu, mais bonne chance avec ça.
Crédits d’image de fonctionnalité: Signal ouvert