subir publicar prueba privadas privada play lanzamiento interna iniciar gratis google deshabilitado app aplicaciones android google-play android-for-work

prueba - Publicar una aplicación privada de Android para múltiples clientes.



publicar aplicaciones privadas google play (6)

Con qué estamos tratando

Tenemos esta aplicación que distribuimos a nuestros clientes de forma offline (es decir, no cargada en Play store). El sabor de la aplicación distribuido a cada cliente es casi idéntico con un poco de ajuste aquí y allá. Todos nuestros clientes comparten esta aplicación con sus empleados para su uso. Básicamente esta es una aplicación empresarial.

Cuál es el problema

Recientemente, uno de nuestros clientes comenzó a utilizar una herramienta MDM (gestión de dispositivos de movilidad) que bloquea las aplicaciones que no se descargan de Google Play. Como es obvio, recibimos una solicitud de nuestro cliente para ver si podemos cargar esta aplicación en Google Play o no.

Lo importante aquí es que tenemos más de 100 clientes y el nombre del paquete de la aplicación que se proporciona a cada cliente es el mismo. Así que es la misma aplicación con un poco de ajuste aquí y allá. Si vamos por el camino de publicar la aplicación en la tienda de juegos, podríamos terminar en un caos (no queremos subir 100 aplicaciones diferentes a la tienda de juegos, es decir, una para cada cliente). Estamos optimizando algo para que varios clientes puedan usar la misma aplicación (pero no podemos hacer que los más de 100 clientes utilicen la misma aplicación).

Qué estoy mirando ?

Comencé a buscar en Android For Work (AFW), aplicaciones privadas de Google, Google Managed Managed y aún digiriendo las cosas. Pero a mí me pareció una forma segura para que las empresas implementen y publiquen aplicaciones que pueden descargarse solo en dispositivos específicos y bajo un perfil determinado (que mantiene las cosas separadas de las aplicaciones y datos personales del usuario en caso de que usen el mismo teléfono para uso personal y propósito de trabajo).

¿Qué solución estoy buscando?

  1. Para implementar una aplicación en forma privada (alojarla en Google o en una sesión privada pero listada con Google Play en ambos casos) y permitir que mis clientes compartan esta aplicación con su empleado.

  2. Cada aplicación privada para cada cliente debe estar en su propia pequeña isla privada. Quiero distribuir la aplicación con el mismo nombre de paquete a todos mis clientes (por lo que he leído hasta ahora, esto podría no ser posible con Google Play. Pero espero que alguien pueda señalar los hechos si me falta algo).


Comencé a buscar en Android For Work (AFW), aplicaciones privadas de Google, Google Managed Managed y aún digiriendo las cosas.

Esto probablemente sería un buen ajuste para AFW.

Pero para mí, parecía una forma segura para que las empresas implementen y publiquen aplicaciones que solo se pueden descargar en dispositivos específicos y bajo un perfil determinado.

Eso es lo que hace un MDM, sí, pero hay más que eso. Con Android for Work también tiene configuraciones administradas que le permiten pasar una configuración para la aplicación. Esto se puede utilizar para cambiar urls backend, etc.

Seguro que es compatible con tu segundo requisito, pero sé muy poco para estar seguro sobre el primero. Si bien puede alojar y desplegar una aplicación de forma privada en Google Play for Work, no sé cómo distribuirla de forma privada a varios clientes.

El beneficio obvio de usar esta API de Google es que no tienes que construir nada por ti mismo. Además, la mayoría de los MDM son compatibles con las API de Android for Work, de modo que un administrador de dominio puede comprar la aplicación de forma masiva y distribuirla a los empleados. Eche un vistazo a la Comunidad AppConfig que muestra a los proveedores de MDM que incorporaron esas API y las mejores prácticas.

Decida lo que decida, definitivamente debería tener un buen vistazo a Android for Work ya que lo que está describiendo es exactamente para lo que está destinado. La configuración inicial es una molestia y hay muy poca información sobre cómo funciona todo y cómo se juega en conjunto, pero pasar unos días tratando de resolverlo podría ser mejor que simplemente crear su propia solución administrada, que luego tendrá que mantener también. .


Google Play ahora permite que un desarrollador publique una aplicación de forma privada para hasta 20 organizaciones (o empresas) de Managed Play. Para hacerlo (instrucciones copiadas del centro de ayuda ):

  • Inicia sesión en la consola de Google Play .
  • Vaya a Precios y distribución> Programas de usuario> Google Play administrado .
  • Marque la casilla Activar las funciones avanzadas administradas de Google Play .
  • Marque la casilla Dirigir de forma privada esta aplicación a una lista de organizaciones .
  • Haga clic en Elegir organizaciones .
  • Para cada organización en la que desee publicar la aplicación, ingrese la ID de la organización y una descripción (o nombre) y haga clic en Agregar . Puedes ingresar hasta 20 organizaciones por aplicación.

La buena solución, larga:

no utilice el mismo nombre de paquete para diferentes aplicaciones. Cree un proyecto multimodular, configure un módulo para el núcleo, cosas compartidas y agregue un módulo para cada cliente donde pueda ajustar lo que necesita y configurar el nombre del paquete de forma dinámica según el tipo de compilación. De esa manera, puede utilizar el mismo nombre de paquete para su servidor de CI y todo lo demás y tener otro nombre de paquete al lanzar la aplicación .

La solución corta que puede funcionar:

Publique la aplicación como una versión beta de google play cerrada y envíe invitaciones solo a este cliente. De esa manera, puede distribuir la aplicación a sus empleados a través de Play Store y los demás clientes no se darán cuenta. No puedo asegurar que funcionará sin saber qué herramienta MDM está enfrentando, pero dado que las aplicaciones del canal beta no requieren permisos de origen desconocido. , deberias estar bien


Según lo que ha dicho, esto suena más como que puede resolver esto con la administración de la configuración que enviar a cada cliente APK completamente separados.

Google tiene un canal privado, pero según la documentación parece estar mucho más orientado a tener una sola lista de miembros (es decir, una vez que se le otorga acceso, tiene acceso a todo el canal privado) en lugar de un acceso altamente personalizado (es decir, ciertas personas tienen acceso) a ciertos elementos en el canal).

Una alternativa que sugiero: haga que todos los clientes descarguen el mismo APK. Dé a cada uno de ellos un "código de activación" específico para el cliente para su aplicación. Cuando la aplicación se inicia por primera vez, llama a un servicio web y le pasa su código de activación; en el lado del servidor, utiliza el Código de activación para identificar al cliente y luego devolver los datos sobre la configuración correcta al cliente. Luego, puede distribuir el mismo APK a todos en su canal privado y configurarlo de forma remota una vez que esté instalado.

Una ventaja importante de este esquema es que puede tener múltiples configuraciones para una organización. Simplemente dé al cliente una selección de varios códigos de activación, cada uno de los cuales les dará una configuración determinada. Por ejemplo, si tiene una aplicación que utilizan tanto los trabajadores del muelle como los conserjes (y solo estoy lanzando un ejemplo aquí), puede dar a los trabajadores del muelle un código de activación y los conserjes un segundo código de activación y luego puede dar fácilmente Las diferentes configuraciones.


Si desea el mismo nombre de paquete, deberá hacer algo como lo que sugirió EJoshuaS: administrar las diferentes configuraciones dentro de una versión de la aplicación. No podrá tener más de una aplicación con el mismo paquete implementado en Google Play.

Si está abierto a tener paquetes diferentes, simplemente puede cambiar el nombre del paquete en el Manifiesto de Android para cada uno y lanzarlo como una aplicación diferente. Necesitaría cambiar el paquete en cualquier lugar donde importe el archivo R y debería asegurarse de que todas las referencias de clase en su Manifiesto incluyan la ruta de la clase completa ( <activity android:name="[full.package].MainActivity"> lugar de que <activity android:name=".MainActivity"> ). Esto se vuelve bastante confuso y es terrible en términos de administración de la configuración, por lo que no es realmente una gran solución en general, pero podría funcionar para usted.


Esta es mi solución:

Creación de aplicaciones dinámicas en tiempo de ejecución que obtienen datos y configuraciones de back-end y representan sus vistas y datos con su propia identificación de cliente .

Puede crear una sola aplicación y subirla a Google Play, pero debe administrar a sus clientes por clientId que hace que cada aplicación se separe. Este ID de cliente es único y generado por sus clientes. Esta solución tiene dos caras. Lado Android y lado Serever.

1 - Lado de Android: nuestra aplicación debería tener una baseUrl como esta en Constantes:

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

Y luego todos los servicios de todos los clientes utilizan la misma url. clientId es el punto clave. La diferencia de tu aplicación cliente es clientId. Para generar el url de api-call debes hacer algo como esto:

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

Debe crear un código QR para sus clientes que deben escanearse en la aplicación ejecutada por primera vez. Es bueno enviar un código QR después del registro a su correo electrónico (cliente de sus Clientes). Este código QR tiene clientId. Por lo tanto, cada cliente tiene sus propios servicios y realmente funciona como islas separadas, incluso si desea cambiar la dirección del servidor, puede poner todo BaseUrl en el código QR, pero esto no se sugiere, porque tiene que crear un servidor por cliente y esto es un dolor de cabeza. .

Incluso puede manejar la configuración y los elementos de la interfaz de usuario de su aplicación llamando a una configuración que devuelve un customConfigDto como json como este:

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; } }

Y renderiza tus vistas con estas configuraciones. Todo esto funciona separado por aplicación por su ID de cliente . Prefiero el código QR porque es muy práctico y elegante y se adapta a su caso, sin embargo, puede ingresar este ID de cliente de muchas otras maneras. This es uno de los mejores servicios gratuitos y simples de generación de códigos QR, y this es una de las mejores bibliotecas de escáneres de códigos QR para Android.

2 - Lado del servidor: tiene que manejar el paso 1 en el lado del servidor y es muy fácil. Puede tener llamadas de entidad al Cliente que todas las demás entidades lo tienen. Porque debe mantener todos sus datos en un lugar, pero separados por sus clientes. También puedes mapear API como esta en Spring:

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