Publiez une application privée Android pour plusieurs clients

Ce dont nous traitons

Nous avons cette application que nous distribuons à nos clients de manière hors ligne (c.-à-d. Pas téléchargée sur Play Store). La saveur de l'application distribuée à chaque client est presque identique à un peu d'ajustement ici et là. Tous nos clients partagent cette application à leurs employés pour utilisation. Fondamentalement, c'est une application d'entreprise.

  • Comment puis-je obtenir une couleur d'un attribut AttributeSet de manière fiable?
  • Vedettes de disposition de la grille Table Layout
  • RecyclerView: trouve le dernier élément visible immédiatement après la création de la vue
  • Comment puis-je ajouter un effet de filigrane à une image dans Android?
  • GetActionBar renvoie null
  • L'exportation d'APK depuis eclipse (ADT) se bloque en silence
  • Quel est le problème

    Récemment, l'un de nos clients a commencé à utiliser un outil MDM (Mobility Device Management) qui bloque les applications qui ne sont pas téléchargées par Google Play. Comme nous avons évidemment reçu une demande de notre client pour voir si nous pouvons télécharger cette application sur Google Play ou pas.

    Une chose importante ici est que nous avons plus de 100 clients et que le nom de package de l'application fournie à chaque client est en fait le même. C'est donc la même application avec un peu de réglage ici et là. Si nous passons à la publication de l'application sur le Play Store, nous pourrions nous retrouver dans un chaos (nous ne voulons pas télécharger 100 applications différentes sur le Play Store, c'est-à-dire pour chaque client). Nous faisons de l'optimisation à partir de notre fin afin que plusieurs clients puissent utiliser la même application (mais nous ne pouvons pas faire en sorte que les 100 utilisateurs utilisent la même application).

    Qu'est-ce que je regarde?

    J'ai commencé à regarder Android For Work (AFW), Google applications privées, Managed Google Play et encore à digérer les choses. Mais pour moi, il s'agissait simplement d'un moyen sécurisé pour les entreprises de déployer / publier des applications qui ne peuvent être téléchargées que sur des périphériques spécifiques et sous un certain profil (qui garde les choses séparées des applications et des données personnelles de l'utilisateur au cas où elles utiliseraient le même téléphone pour le personnel Et but de travail).

    Quelle solution je recherche?

    1. Pour déployer une application privée (l'héberger avec Google ou un hôte privé, mais listé avec Google Play dans les deux cas) et laisser mes clients partager cette application avec leur employé.

    2. Chaque application privée pour chaque client devrait être sur sa propre petite île privée. Je souhaite distribuer l'application avec le même nom de package à tous mes clients (d'après ce que j'ai lu jusqu'ici, cela pourrait ne pas être possible avec Google Play. Mais j'espère que quelqu'un peut indiquer des faits si je manque quelque chose).

  • Wear App et avec un type de construction personnalisé avec applicationIdSuffix
  • Arrêtez le son du clic de la caméra de manière programmée dans Android
  • Fragments sur le lotCreateView (). D'où est ce que ça vient?
  • Comment puis-je partager du texte dans l'application sur le numéro particulier?
  • Obtenir l'événement de clic de la page Web dans mon application Android
  • Android view layout_width - comment changer de manière programmée?
  • 5 Solutions collect form web for “Publiez une application privée Android pour plusieurs clients”

    C'est ma solution:

    Création d'une application dynamique qui permet d'obtenir des données et des configurations depuis l'arrière-plan et de rendre ses vues et données avec son propre Id . Client .

    Vous pouvez créer une application unique et télécharger sur google play, mais vous devez gérer vos clients par clientId qui rend chaque fonction de l'application séparée. Ce clientId est unique et généré par vos clients. Cette solution comporte deux côtés. Côté Android et côté Serever.

    1 – Côté Android: notre application devrait avoir une base comme cette dans Constants:

    baseUrl = "http://yourCorporation.com/{clienId}/api/" 

    Et alors tous les services de Tous les clients utilisent la même URL. ClientId est le point clé. La différence de votre application client est clientId. Pour générer une url d'api-call, vous devriez faire quelque chose comme ceci:

     Constant.ClientId = scannedQRCode; url = baseUrl.replace("{client_id}",Contant.ClientId) + apiUrl ; 

    Vous devez créer un code QR pour vos clients qui devraient être scannés dans la première exécution de l'application. Il est bon d'envoyer un code QR après l'enregistrement à son courriel (client de vos clients). Ce QR-code a clientId. Par conséquent, tous les clients ont leurs propres services et fonctionnent vraiment comme des îles séparées, même si vous souhaitez modifier l'adresse du serveur, vous pouvez mettre tout baseUrl dans le code QR, mais cela n'est pas suggéré, car il faut créer un serveur par client et c'est un mal de tête .

    Vous pouvez même gérer les éléments de configuration et d'interface utilisateur de votre application en appelant un config api qui renvoie un CustomConfigDto comme json comme ceci:

     public class CustomConfigDto { String colorPrimary ; String colroPrimaryDark ; String colorAccent ; int tabCounts; //and more... public String getColorPrimary() { return colorPrimary; } public void setColorPrimary(String colorPrimary) { this.colorPrimary = colorPrimary; } public String getColroPrimaryDark() { return colroPrimaryDark; } public void setColroPrimaryDark(String colroPrimaryDark) { this.colroPrimaryDark = colroPrimaryDark; } public String getColorAccent() { return colorAccent; } public void setColorAccent(String colorAccent) { this.colorAccent = colorAccent; } public int getTabCounts() { return tabCounts; } public void setTabCounts(int tabCounts) { this.tabCounts = tabCounts; } } 

    Et rendez vos vues par ces configurations. Tous ces travaux sont séparés par application par leur clientId . Je préfère le code QR car il est très pratique et chic et adapté à votre cas, mais vous pouvez entrer ce clientId de nombreuses autres façons. C'est l' un des meilleurs services de génération de code QR gratuit et simple, et c'est l'une des meilleures bibliothèques de scanner de code QR pour Android.

    2 – Ligne du serveur : vous devez gérer l'étape 1 du côté du serveur et c'est très simple. Vous pouvez avoir un appel d'entité Client que toutes les autres entités l'ont. Parce que vous devez conserver toutes vos données dans un endroit mais séparé par vos clients. Vous pouvez également mapper des API comme ceci en Spring:

     @RequestMapping(value = "http://yourCorporation.com/{clienId}/api/customers", method = RequestMethod.GET) Customers getCustomers(@PathVariable("clienId") Long clientId) { return customerService.findCustomerByClientId(clientId); } 

    Sur la base de ce que vous avez dit, cela ressemble davantage à ce que vous pouvez résoudre cela avec la gestion de la configuration que l'envoi de chaque client des APK complètement séparés.

    Google a une chaîne privée, mais en fonction de la documentation, il semble beaucoup plus orienté vers une liste de membre unique (c.-à-d. Une fois que vous avez accès, vous avez accès à toute la chaîne privée) plutôt qu'un accès hautement personnalisé (c.-à-d. Certaines personnes ont accès À certains éléments de la chaîne).

    Une alternative que je suggère: que tous les clients téléchargent le même APK. Donnez à chacun d'eux un «code d'activation» spécifique au client pour votre application. Lorsque l'application démarre pour la première fois, elle appelle un service Web et lui transmet son code d'activation; Du côté du serveur, vous utilisez le code d'activation pour identifier le client, puis renvoyez les données sur la configuration correcte au client. Ensuite, vous pouvez distribuer le même APK à tout le monde sur votre chaîne privée et le configurer à distance une fois qu'il est installé.

    Un avantage majeur de ce schéma est que vous pouvez avoir plusieurs configurations pour une organisation. Il suffit de donner au client un choix de plusieurs codes d'activation, dont chacun leur donnera une certaine configuration. Par exemple, si vous avez une application utilisée par les dockers et les concierges (et je jette un exemple ici), vous pourriez donner aux dockers un code d'activation et les concierges un deuxième code d'activation et vous pouvez facilement donner Différentes configurations.

    La bonne et longue solution:

    N'utilisez pas le même nom de paquetage pour différentes applications. Créez un projet multimodèle, définissez un module pour le noyau, des éléments partagés et ajoutez un module pour chaque client où vous pouvez modifier ce dont vous avez besoin et configurer le nom du package de manière dynamique en fonction du type de construction. De cette façon, vous pouvez utiliser le même nom de package pour votre serveur CI et tout le reste et avoir un autre nom de package lors de la sortie de l'application .

    La courte solution de rechange qui pourrait fonctionner:

    Publiez l'application en tant que version beta fermée de google play et envoyez des invitations uniquement à ce client. De cette façon, il peut distribuer l'application à ses employés par le biais de Play Store et les autres clients ne remarqueront pas que je ne peux pas assurer qu'il fonctionnera sans savoir quel outil MDM vous faites face, mais puisque les applications de la chaîne bêta ne nécessitent pas d'autorisations d'origine inconnue , Vous devriez être bien.

    Si vous voulez le même nom de paquetage, vous devrez faire quelque chose comme ce que suggère EJoshuaS: gérer les différentes configurations à l'intérieur d'une application. Vous ne pourrez pas avoir plus d'une application avec le même package déployé sur Google Play.

    Si vous êtes ouvert à des paquets différents, vous pouvez simplement modifier le nom du package dans le Manifeste Android pour chacun d'entre eux et le lancer comme une autre application. Vous devriez changer le package partout où vous importez le fichier R et vous devriez vous assurer que toutes les références de classe dans votre manifeste incluent le chemin de classe entier ( <activity android:name="[full.package].MainActivity"> plutôt <activity android:name=".MainActivity"> ). Cela devient très déroutant et est terrible en termes de gestion de la configuration, donc ce n'est pas vraiment une excellente solution en général, mais cela pourrait fonctionner pour vous.

    J'ai commencé à regarder Android For Work (AFW), Google applications privées, Managed Google Play et encore à digérer les choses.

    Ce serait probablement un bon ajustement pour AFW.

    Mais pour moi, il semblait juste que les entreprises déployaient et publiaient des applications qui ne peuvent être téléchargées que sur des dispositifs spécifiques et sous un certain profil.

    C'est ce qu'un MDM fait, oui, mais il y en a plus. Avec Android for Work, vous disposez également de Configurations Gérées qui vous permettent de passer une configuration pour l'application. Cela peut être utilisé pour modifier les URL du backend, etc.

    Cela assure certainement votre deuxième exigence, mais je sais trop peu pour être certain de la première. Bien que vous puissiez héberger et déposer en privé une application sur Google Play for Work, je ne connais pas la distribution privée de plusieurs clients.

    Le bénéfice évident de l'utilisation de cette API Google est que vous n'avez pas à créer quoi que ce soit vous-même. De plus, la plupart des MDM prennent en charge ces API Android pour Work, de sorte qu'un administrateur de domaine peut acheter l'application en vrac et les distribuer aux employés. Consultez la communauté AppConfig qui montre les fournisseurs MDM qui ont intégré ces API et les meilleures pratiques.

    Quoi que vous décidiez, vous devriez avoir un bon aperçu d'Android for Work car ce que vous décrivez est exactement ce qu'il est destiné. La configuration initiale est une douleur et il y a trop peu d'informations sur la façon dont tout fonctionne et joue ensemble, mais passer quelques jours à essayer de comprendre cela pourrait être mieux que de construire votre propre solution gérée, que vous devrez alors maintenir .

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.