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

Question

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

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

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

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

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

9

android google-play publishing white-labelling

Источник

user156477 22 дек '10 в 08:34

7 ответов

Другие вопросы по тегам android google-play publishing white-labelling

user31785 22 дек '10 в 09:54 2010-12-22 09:54 · Answer 1 · 2010-12-22 09:54

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

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

user476747 22 дек '10 в 08:43 2010-12-22 08:43 · Answer 2 · 2010-12-22 08:43

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

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

user1306419 14 мар '17 в 21:05 2017-03-14 21:05 · Answer 3 · 2017-03-14 21:05

Это довольно старый вопрос. Однако теперь я думаю, что лучшим подходом будет использование 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.

user2454753 22 дек '10 в 12:34 2010-12-22 12:34 · Answer 4 · 2010-12-22 12:34

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

2

Источник

user2454753 22 дек '10 в 12:34

user1045941 16 авг '17 в 08:07 2017-08-16 08:07 · Answer 5 · 2017-08-16 08:07

То, что вам нужно, это Build Variants (он же 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.

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

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

user804894 24 мар '15 в 18:38 2015-03-24 18:38 · Answer 6 · 2015-03-24 18:38

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

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

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

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

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

user1470567 18 июл '12 в 18:35 2012-07-18 18:35 · Answer 7 · 2012-07-18 18:35

Я согласен с тем, что сказал 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).