Android - приложение whitelabel

Question

ПРИМЕЧАНИЕ: Это старый вопрос, и, соответственно, старый ответ с поправкой на голосование может не относиться к делу - см. Более новые ответы о вариантах сборки (также известные как App Flavors).

У меня есть вопрос по поводу публикации на рынке.

Компания X предоставляет аналогичные услуги компаниям A & B, и A & B хотят иметь приложение на рынке.Компания X хочет написать только одно приложение и различать их, используя соответствующие логотипы, настройки конфигурации, языковые строки во время компиляции.Однако, когда дело доходит до публикации, приложения имеют одно и то же имя пакета приложения (с использованием базы общего кода).Приложение будет поддерживаться и

Итак, учитывая, что я хочу сохранить единую кодовую базу, какова лучшая практика здесь?

Answer 1

Насколько я знаю, на Маркете не может быть двух приложений с одинаковым именем пакета.Чтобы избежать копирования и вставки общего кода, макетов, рисованных объектов и т. Д., Я бы порекомендовал поместить эти ресурсы в проект библиотеки, а затем ссылаться на этот проект из приложений A и B, которые вы упомянули, и в этих приложениях просто переопределяйте значения, которые вы хотите изменить.

Подробнее о библиотечных проектах в официальной документации .

Answer 2

Смотрите это сообщение в блоге, blog.javia.org / android-package-name / .

[править] Чтобы избежать потери информации, если эта ссылка умирает: это сообщениео разнице в определении пакета приложения и определения пакета Java.Можно изменить пакет приложения (внутри манифеста), не касаясь java-пакета исходных текстов. [/ Edit]

Answer 3

Это довольно старый вопрос.Однако теперь я думаю, что лучшим подходом будет использование Product Flavors для Android с использованием новой системы сборки gradle.

• Для каждого аромата вы можете определить applicationId.Существует разница между packageName и applicationId.ApplicationId уникально идентифицирует ваше приложение на устройстве и в Google Play Store.Последний предназначен для пространства имен кода.Вы можете прочитать больше здесь: https://developer.android.com/studio/build/application-id.html
• Для каждого аромата вы можете иметь различные рисованные элементы, строки, другие XML-файлы, используя специальную папку для аромата.Вам нужно только поместить эти активы в новые файлы, которые отличаются от ресурсов в папке main.Затем есть buildConfigField, который вы можете определить для каждого варианта в build.gradle, к которому можно получить доступ из файлов Java в качестве ваших настроек для каждой белой метки.
• Также вы можете определить resValue для каждого аромата оттуда.
• Вы также можете настроить свой AndroidManifest.xml для ключей и т. Д., Используя manifestPlaceholder .

Answer 4

Йохан ответ правильный.В моей компании мы только что создали небольшой скрипт, который создает «бренды» приложения из одного «базового» приложения, не только применяя новые ресурсы, но и создавая собственное имя пакета и исправляя соответствующие файлы XML.

Answer 5

Что вам нужно, так это варианты сборки (a.k.a. App Flavors).

Вы можете прочитать об этом здесь https://developer.android.com/studio/build/build-variants.html

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

defaultConfig {
    applicationId "com.example.example"
    minSdkVersion 16
    targetSdkVersion 25
    versionCode 1
    versionName "1.0.0"
}

productFlavors {
    variantone {
            applicationId 'com.company1.example'
    }
    varianttwo {
            applicationId 'com.company2.example'
    }
}

Вы можете создавать папки ресурсов с именами вариантов, где вы можете разместить альтернативные ресурсы или исходный код. Например, src/variantone/res

Переключение между вариантами сборки в Android Studio не приводит к изменению файла (вы просто выбираете «выходные данные»). Вы можете создавать APK для всех вариантов одновременно. Используйте мастер в Построить / Создать подписанный APK.

P.S. Вот как у вас может быть другое имя пакета для сборок Debug:

buildTypes {
    release {
    }
    debug {
        applicationIdSuffix '.debug'
        versionNameSuffix '.debug'
    }
}

Answer 6

Я знаю, что немного опоздал на вечеринку, но вы можете сделать это следующим образом:

1) Измените свой project.properties, добавив строку manifestmerger.enabled=true

2) Изменитьимя вашего пакета в манифесте.

3) Обновите / измените ваши ресурсы, Drawables, строки, что угодно.

4) Пометьте свой мастер-проект как библиотеку и установите для него зависимость в своем проекте white-label.Вуаля, белая этикетка!

Answer 7

Я согласен с тем, что сказал Reflog, моя компания использовала сценарий ant для изменения имени пакета для каждого бренда, а также для замены ресурсов по мере необходимости.Я написал базовое приложение с учетом поведения по умолчанию и создал папки для каждого дополнительного бренда, содержащие только те файлы, которые отличались от базовых, точно так же, как несколько папок для рисования с разными размерами dpi («drawable», «drawable-hdpi»)...).Другие изменения включали изменение файлов строк для каждого бренда для соответствующих цветов и легального текста.

Поименовывая их в стиле локализации (например, «drawable-en-rAA-hdpi», «layout-en-rBB»)...), я смог быстро протестировать это в нескольких эмуляторах, открыв приложение «Custom Locale» в каждом эмуляторе и установив в качестве языка «en_AA», «en_BB», если необходимо.Сохраняя несколько копий базового AVD, я смог сохранить эти настройки, поэтому мне не пришлось переключаться в эмуляторе для тестирования всех конечных брендов.

Одним из предостережений в этом подходе является эта эмулированная версияприложение будет включать все файлы в .apk, в то время как ant-скрипт удаляет дубликаты.Кроме того, хотя этот «полный» файл .apk будет установлен на устройствах, он будет отображать только поведение по умолчанию, если вы не можете установить языковой стандарт на устройстве в соответствии с языковым стандартом бренда.(Пользовательская локаль не была установлена ​​ни на одном из моих физических устройств.) Это хорошо работает, если вы намеренно используете существующие именованные локали (en_AU, en_CA, en_GB), но может быть проблематичным для пользовательских имен (en_B1, en_XX).