web-dev-qa-db-fra.com

Publier une application privée Android pour plusieurs clients

Ce que nous traitons

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

Quel est le problème

Un de nos clients a récemment commencé à utiliser un outil MDM (Mobility Device Management) qui bloque les applications non téléchargées depuis Google Play. Comme nous l’avons bien entendu, notre client nous a demandé si nous pouvions télécharger cette application sur Google Play ou non.

Ce qui est important ici, c'est que nous avons plus de 100 clients et que le nom du package de l'application fournie à chaque client est en fait le même. Donc, c'est la même application avec un peu de Tweak ici et là. Si nous publions l’application sur le Play Store, nous risquons de nous perdre (nous ne voulons pas télécharger 100 applications différentes sur le Play Store - c’est-à-dire une pour chaque client). De notre côté, nous procédons à une optimisation afin que plusieurs clients puissent utiliser la même application (mais nous ne pouvons pas obliger plus de 100 clients à utiliser la même application.).

Qu'est-ce que je regarde?

J'ai commencé à regarder Android For Work (AFW), les applications privées de Google, Géré jouer à Google et toujours en digérant les contenus. Mais pour moi, cela ressemblait simplement à un moyen sûr pour les entreprises de déployer/publier des applications qui ne peuvent être téléchargées que sur des appareils spécifiques et sous un certain profil (ce qui permet de séparer les éléments des applications et données personnelles de l'utilisateur si elles utilisent le même et objectif de travail).

Quelle solution je cherche?

  1. Pour déployer une application en privé (hébergez-la avec Google ou hébergez-la en privé mais répertoriée avec Google play dans les deux cas) et laissez mes clients partager cette application avec leurs employés.

  2. Chaque application privée pour chaque client doit ê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'à présent, cela pourrait ne pas être possible avec Google Play. Mais j'espère que quelqu'un pourra signaler des faits s'il me manque quelque chose).

androidgoogle-playandroid-for-work
17
Dibzmania

Voici ma solution:

Création d'une application dynamique au moment de l'exécution qui récupère les données et les configurations à partir du système principal et rend ses vues et données avec son propre ID client .

Vous pouvez créer une application unique et la télécharger sur Google Play, mais vous devez gérer vos clients par clientId afin que chaque application soit séparée. Ce clientId est unique et généré par vos clients. Cette solution a deux côtés. Côté Android et côté Serever.

1 - Côté Android: Notre application devrait avoir une baseUrl comme celle-ci dans Constants:

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

Et puis 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 l'URL de 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 doit être analysé lors de la première exécution de l'application. Il est bon d'envoyer un code QR après enregistrement à son email (client de vos clients). Ce code QR a clientId. Tous les clients ont donc leurs propres services et fonctionnent vraiment comme des îlots séparés, même si vous voulez changer l’adresse du serveur, vous pouvez mettre tous baseUrl dans un code QR, mais cela n’est pas recommandé, car vous devez créer un serveur par client, ce qui est un casse-tête. .

Vous pouvez même gérer les éléments de configuration et d'interface utilisateur de votre application en appelant une API de configuration qui renvoie un customConfigDto as 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 rendre vos vues par ces configurations. Tout cela fonctionne séparé par application par leur clientId . Je preffer QR-code parce qu'il est très pratique et élégant et convient à votre cas, cependant vous pouvez entrer cet ID client avec beaucoup d'autres moyens. This est l’un des meilleurs services de génération de codes QR gratuits et simples, et this est l’une des meilleures librairies de scanners de codes QR pour Android.

2 - Côté serveur: Vous devez gérer step1 côté serveur et c'est très simple. Vous pouvez avoir des appels d'entité Client que toutes les autres entités l'ont. Parce que vous devez conserver toutes vos données au même endroit, mais séparées par vos clients. Vous pouvez également mapper des API comme celle-ci au printemps:

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

D'après ce que vous avez dit, cela ressemble plus à une solution de gestion de la configuration que d'envoyer à chaque client des fichiers APK complètement distincts.

Google a un canal privé, mais d'après la documentation, il semble être plus orienté vers une liste unique de membres (c'est-à-dire qu'une fois l'accès accordé, vous avez accès à l'intégralité du canal privé) plutôt qu'à un accès hautement personnalisé (certaines personnes y ont accès). à certains éléments de la chaîne).

Une alternative que je suggère: demandez à tous les clients de télécharger le même fichier APK. Donnez à chacun d'eux un "code d'activation" spécifique à votre 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 fichier APK à tout le monde sur votre canal privé et le configurer à distance une fois 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, chacun d’eux leur donnant une configuration donnée. Par exemple, si vous avez une application utilisée à la fois par les dockers et les concierges (et je ne fais que donner un exemple ici), vous pouvez donner un code d'activation aux dockers et un second code d'activation aux concierges. les différentes configurations.

4
EJoshuaS

La bonne solution à long terme:

n'utilisez pas le même nom de package pour différentes applications. Créez un projet multimodule, définissez un module pour le noyau et les éléments partagés, puis ajoutez un module pour chaque client. Vous pourrez ainsi ajuster 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 publication de l'application .

La solution de contournement courte qui peut fonctionner:

Publiez l'application en tant que version bêta fermée de Google Play et envoyez des invitations uniquement à ce client. De cette manière, il peut distribuer l'application à ses employés via Play Store et les autres clients ne remarqueront pas que cela ne fonctionnera pas si on ne sait pas à quel outil MDM vous êtes confronté, mais comme les applications de la chaîne bêta ne nécessitent pas d'autorisations d'origine inconnue , ça devrait aller.

3
Fco P.

Google Play permet désormais à un développeur de publier une application de manière privée pour un maximum de 20 organisations (ou entreprises) de jeux gérés. Pour ce faire (instructions copiées à partir du help center ):

  • Connectez-vous à la Console Google Play .
  • Accédez à Tarification et distribution> Programmes utilisateur> Géré Google Play .
  • Cochez la case Activez la zone des fonctionnalités avancées de gestion de Google Play .
  • Vérifiez la Cibler cette application en privé sur une liste d'organisations .
  • Cliquez sur Choisissez des organisations .
  • Pour chaque organisation dans laquelle vous souhaitez publier l'application, entrez l'ID de l'organisation et une description (ou nom), puis cliquez sur Ajouter . Vous pouvez entrer jusqu'à 20 organisations par application.
2
Fred

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

Si vous êtes prêt à avoir différents packages, vous pouvez simplement changer le nom du package dans le manifeste Android pour chacun et le publier en tant qu'application différente. Vous devez modifier le package partout où vous importez le fichier R et vous assurer que toutes les références de classe de votre manifeste incluent le chemin d'accès complet à la classe (<activity Android:name="[full.package].MainActivity"> au lieu de <activity Android:name=".MainActivity">). Cela devient assez déroutant et est terrible en termes de gestion de configuration, donc ce n’est pas vraiment une bonne solution en général, mais cela pourrait fonctionner pour vous.

1
windedmoose

J'ai commencé à regarder Android For Work (AFW), les applications privées de Google, la gestion de Google Play et toujours à digérer les contenus.

Ce serait probablement un bon moyen pour AFW.

Mais pour moi, cela ressemblait simplement à un moyen sûr pour les entreprises de déployer/publier des applications qui ne peuvent être téléchargées que sur des appareils spécifiques et sous un certain profil.

C'est ce que fait un MDM, oui, mais il y a plus que ça. Avec Android for Work, vous avez également Configurations gérées qui vous permettent de définir une configuration pour l'application. Ceci peut être utilisé pour changer les URL de back-end, etc.

Cela répond 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éployer une application en privé sur Google Play for Work, je ne sais pas comment la distribuer en privé à plusieurs clients.

L’avantage évident de l’utilisation de cette API Google est que vous n’avez rien à construire vous-même. De plus, la plupart des MDM prennent en charge ces API Android for Work, de sorte qu'un administrateur de domaine puisse acheter l'application en masse et la distribuer aux employés. Consultez la communauté AppConfig Community qui indique aux fournisseurs MDM qui ont incorporé ces API et meilleures pratiques.

Quoi que vous décidiez, vous devriez certainement jeter un coup d'œil sur Android for Work, car ce que vous décrivez correspond exactement à ce à quoi il est destiné. La configuration initiale est pénible et il y a way trop peu d’informations sur la manière dont tout cela fonctionne et qui s’agit bien, mais passer quelques jours à essayer de comprendre cela pourrait être mieux que de simplement construire votre propre solution alors devra maintenir aussi.

1
David Medenjak