Публикация частного приложения Android для нескольких клиентов

Что мы имеем дело с

У нас есть это приложение, которое мы распространяем для наших клиентов в автономном режиме (т.е. не загружаем в Play Store). Прикладной аромат, распределенный каждому клиенту, почти идентичен с небольшим количеством настроек здесь и там. Все наши клиенты используют это приложение для своих сотрудников для использования. В основном это корпоративное приложение.

Что проблема

Недавно один из наших клиентов начал использовать инструмент MDM (Mobility Device management), который блокирует приложения, которые не загружаются из игры Google. Очевидно, мы получили запрос от нашего клиента, чтобы узнать, можно ли загрузить это приложение в игру Google или нет.

Важно, что у нас более 100 клиентов, и имя пакета приложения, предоставляемого каждому клиенту, на самом деле то же самое. Так что это одно и тоже приложение с небольшим количеством настроек. Если мы пойдем по пути публикации приложения в игровой магазин, мы, возможно, окажемся в хаосе (мы не хотим загружать в магазин игр 100 различных приложений, то есть один для каждого клиента). Мы делаем некоторую оптимизацию с нашего конца, чтобы несколько клиентов могли использовать одно и то же приложение (но мы не можем заставить все 100 клиентов использовать одно и то же приложение.)

На что я смотрю?

Я начал изучать Android For Work (AFW), личные приложения Google, управляемую Google и все еще переваривать вещи. Но для меня это выглядело как безопасный способ для предприятий развертывать/публиковать приложения, которые могут быть загружены только на определенных устройствах и под определенным профилем (который держит вещи отдельно от личных приложений и данных пользователя, если они используют один и тот же телефон для личных и цель работы).

Какое решение я ищу?

Частное развертывание приложения (размещение его в Google или частном хосте но перечислены в Google Play в обоих случаях), и пусть мои клиенты разделяют это приложение со своим сотрудником.
Каждое частное приложение для каждого клиента должно быть частный остров. Я хочу распространять приложение с тем же пакетом имя всем моим клиентам (из того, что я прочитал до сих пор, это может не с помощью Google. Но я надеюсь, что кто-то может указать факты, если я чего-то не хватает).

Ответ 1

Это мое решение:

Создание динамического приложения во время выполнения, которое получает данные и конфиги из внешнего сервера и отображает его представления и данные с помощью собственного идентификатора клиента.

Вы можете создать одно приложение и загрузить в игру Google, но вы должны управлять своими клиентами клиентом, что делает каждое приложение раздельным. Этот clientId уникален и создан для ваших клиентов. Это решение имеет две стороны. Сторона Android и Serever.

1 - сторона Android: Наше приложение должно иметь baseUrl, как это в Constants:

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

И тогда все сервисы всех клиентов используют один и тот же URL-адрес. clientId - ключевой момент. Разница вашего клиентского приложения - clientId. Для генерации url api-call вы должны сделать что-то вроде этого:

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

Вы должны создать QR-код для ваших клиентов, которые должны сначала сканировать в приложении. Хорошо отправить QR-код после регистрации на его/ее (клиент ваших клиентов) по электронной почте. Этот QR-код имеет clientId. Поэтому каждый клиент имеет свои собственные услуги и действительно работает как отдельные острова, даже если вы хотите изменить адрес сервера, вы можете поместить все baseUrl в QR-код, но это не рекомендуется, потому что вам нужно создать сервер на клиентов, и это головная боль,

Вы даже можете обрабатывать конфигурационные и пользовательские элементы вашего приложения с вызовом config api, который возвращает customConfigDto как json, как это:

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

И визуализируйте свои представления по этим конфигурациям. Все это работает для каждого приложения с помощью clientId. Я предпочитаю QR-код, потому что он очень ручно и стильно и подходит вам, но вы можете ввести этот clientId многими другими способами. Это - одна из лучших бесплатных и простых услуг генерации QR-кода, и этот является одной из лучших библиотек сканера QR-кода для Android.

2 - Сторона сервера: Вам нужно обрабатывать step1 на стороне сервера, и это очень просто. У вас могут быть сущности-вызовы Клиент, которые имеют все остальные сущности. Потому что вы должны хранить все свои данные в одном месте, но разделены вашими клиентами. Вы также можете сопоставить API как это в Spring:

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

Ответ 2

Основываясь на том, что вы сказали, это похоже на то, что вы можете решить это с помощью управления конфигурацией, чем отправлять каждому клиенту полностью отдельные APK.

Google имеет частный канал, но на основе документации он выглядит гораздо более ориентированным на наличие единого списка членов (т.е. после того, как вам предоставлен доступ к вашему доступу ко всему частному каналу), а не к высококонфигурированному доступу (то есть к определенным люди имеют доступ к определенным элементам в канале).

Альтернатива, которую я предлагаю: все клиенты загружают один и тот же APK. Дайте каждому из них "код активации" для конкретного приложения для вашего приложения. Когда приложение запускается в первый раз, он вызывает веб-службу и передает ей свой код активации; на стороне сервера вы используете код активации для идентификации клиента, а затем возвращаете данные о правильной конфигурации клиенту. Затем вы можете распространять один и тот же APK для всех на своем личном канале и настроить его удаленно после его установки.

Основным преимуществом этой схемы является то, что вы можете иметь несколько конфигураций для организации. Просто дайте клиенту выбор нескольких кодов активации, каждый из которых даст им определенную конфигурацию. Например, если у вас есть приложение, которое используется как док-станциями, так и дворниками (и я просто выбрасываю пример здесь), вы можете дать док-работникам один код активации и janitors второй код активации, и вы можете легко дать их разные конфигурации.

Ответ 3

Хорошее, длинное решение:

не использовать одно и то же имя пакета для разных приложений. Создайте многомодовый проект, установите один модуль для ядра, общий материал и добавьте модуль для каждого клиента, где вы можете настроить то, что вам нужно, и настроить динамическое имя пакета на основе типа сборки. Таким образом вы можете использовать одно и то же имя пакета для своего CI-сервера и всего остального и иметь другое имя пакета при выпуске приложения.

Короткое обходное решение, которое может работать:

Опубликуйте приложение как закрытую бета-версию google play и отправьте приглашения только этому клиенту. Таким образом, он может распространять приложение своим сотрудникам через игровой магазин, а другие клиенты не заметят, что я не могу гарантировать, что он будет работать, не зная, с каким MDM-инструментом вы столкнулись, но так как приложения бета-каналов не требуют разрешения неизвестного происхождения, вы должны быть в порядке.

Ответ 4

Если вы хотите иметь такое же имя пакета, вам нужно будет сделать что-то вроде того, что предлагает EJoshuaS: управлять различными конфигурациями внутри одной версии приложения. Вы не сможете иметь более одного приложения с тем же пакетом, который был развернут в Google Play.

Если вы открыты для разных пакетов, вы можете просто изменить имя пакета в манифесте Android для каждого из них и выпустить его как другое приложение. Вам нужно будет изменить пакет везде, где вы импортируете R файл, и вам нужно будет убедиться, что все ссылки на классы в вашем манифесте включают весь путь класса (<activity android:name="[full.package].MainActivity">, а не <activity android:name=".MainActivity">). Это становится довольно запутанным и ужасным с точки зрения управления конфигурацией, поэтому это не очень хорошее решение в целом, но оно может сработать для вас.

Ответ 5

Я начал смотреть Android For Work (AFW), частные приложения Google, управлял Google и все еще переваривал материалы.

Это, вероятно, будет подходящим для AFW.

Но для меня это выглядело как безопасный способ для предприятий развертывать/публиковать приложения, которые могут быть загружены только на определенных устройствах и под определенным профилем

Что делает MDM, да, но там больше. С Android for Work у вас также есть Managed Configurations, которые позволяют вам передать конфигурацию для приложения. Это можно использовать для изменения внутренних ссылок и т.д.

Это точно поддерживает ваше второе требование, но я знаю слишком мало, чтобы быть уверенным в первом. Хотя вы можете приватно размещать и распространять приложение в Google Play for Work, я не знаю, как его частным образом распространять на несколько клиентов.

Очевидным преимуществом использования этого API Google является то, что вам не нужно ничего строить самостоятельно. Кроме того, большинство MDM поддерживают эти API для работы с приложениями для работы, так что администратор домена может купить приложение навалом и распределить его сотрудникам. Посмотрите на Сообщество AppConfig, в котором представлены поставщики MDM, которые включают эти API и лучшие практики.

Независимо от того, что вы решите, вы обязательно должны хорошо взглянуть на Android for Work, так как то, что вы описываете, именно то, для чего оно предназначено. Первоначальная настройка - это боль, и есть слишком мало информации о том, как все это работает и играет вместе, но потратить несколько дней, пытаясь понять это, может быть лучше, чем просто создать собственное управляемое решение, которое вам тогда придется поддерживать.

Ответ 6

Google Play теперь позволяет разработчику публиковать приложение в частном порядке до 20 организаций управляемого управления (или предприятий). Для этого (инструкции скопированы из справочного центра ):

Войдите в Google Play Console.
Перейдите в раздел Ценообразование и распространение > Пользовательские программы > Управляемый Google Play.
Установите флажок Включить расширенные функции управляемого Google Play.
Отметьте Частное целевое приложение для списка организаций.
Нажмите Выбрать организации.
Для каждой организации, к которой вы хотите опубликовать приложение, введите идентификатор организации и описание (или имя) и нажмите Добавить. Вы можете ввести до 20 организаций для каждого приложения.