Android - Whitelabel App

Question

HINWEIS: Dies ist eine alte Frage, und die entsprechend alte upvoted Antwort kann nicht relevant sein - siehe die neueren Antworten zu Build-Varianten (auch bekannt als App Flavors).

Ich habe eine Frage über die Veröffentlichung auf dem Markt.

Firma, X, bietet ähnliche Dienste für Unternehmen A & B, und beide A & B wollen eine App auf dem Marktplatz. Unternehmen X möchte nur eine App schreiben und zwischen ihnen mit den entsprechenden Logos, Konfigurationseinstellungen und Sprachzeichenfolgen bei der Kompilierung unterscheiden. Wenn es jedoch um das Publizieren geht, haben die Apps den gleichen Namen des App-Pakets (unter Verwendung der gemeinsamen Codebasis). Die App wird gepflegt und

Also, da ich eine einzige Code-Basis behalten möchte, was ist die beste Praxis hier?

Answer 1

Sehen Sie diesen Blogpost, blog.javia.org/android-package-name/.

[edit] Um einen Verlust von Informationen zu vermeiden, wenn dieser Link stirbt: Es ist ein Beitrag über den Unterschied der Anwendungspackendefinition und der Java-Paketdefinition. Es ist möglich, das Anwendungspaket (innerhalb des Manifests) zu ändern, ohne das Java-Paket der Quellen zu berühren.

Answer 2

Soweit ich weiß, können Sie nicht zwei Anwendungen auf dem Markt mit dem gleichen Paketnamen haben. Um das Kopieren und Einfügen von gemeinsam genutztem Code, Layouts, Zeichenvorlagen usw. zu vermeiden, würde ich empfehlen, diese Ressourcen in ein Bibliotheksprojekt zu stellen und dann auf dieses Projekt von App A und B zu verweisen und in diesen Apps einfach die Werte zu überschreiben, die Sie ändern möchten .

Mehr über Bibliotheksprojekte in the official documentation.

Answer 3

Johans Antwort ist korrekt. In meinem Unternehmen haben wir ein kleines Skript erstellt, das Anwendungsmarken aus einer Basisanwendung erstellt, indem nicht nur neue Ressourcen angewendet werden, sondern auch ein benutzerdefinierter Paketname erstellt und die entsprechenden XML-Dateien gepatcht werden.

Answer 4

Ich stimme zu, was Reflog sagte, mein Unternehmen verwendet ein Ant-Skript, um den Paketnamen für jede Marke zu ändern und auch Ressourcen nach Bedarf zu ersetzen. Ich schrieb die Basis-App mit Standardverhalten und erstellte Ordner für jede weitere Marke, die nur die Dateien enthielt, die sich von der Basis unterschieden, genau wie die mehreren aufklappbaren Ordner mit unterschiedlichen dpi-Größen ("Drawable", "Drawable-hdpi"). ..). Zu den weiteren Änderungen gehörte das Ändern der Zeichenkettendateien für jede Marke für die entsprechenden Farben und den Rechtstext.

Durch ihre Benennung im Lokalisierungsstil (zum Beispiel "drawable-de-rAA-hdpi", "layout-de-rBB" ...) konnte ich dies schnell in mehreren Emulatoren testen, indem ich den " Custom Locale "App in jedem Emulator, und stellen Sie das Gebietsschema auf" en_AA "," en_BB "je nach Bedarf. Durch das Speichern mehrerer Kopien des Basis-AVDs konnte ich diese Einstellungen speichern, sodass ich nicht innerhalb des Emulators wechseln musste, um alle endgültigen Marken zu testen.

Eine Einschränkung dieses Ansatzes ist, dass diese emulierte Version der App alle Dateien in der .apk enthält, während das Ant-Skript die Duplikate entfernt. Auch wenn diese "vollständige" .apk auf Geräten installiert wird, wird nur das Standardverhalten angezeigt, es sei denn, Sie können das Gebietsschema auf dem Gerät so einstellen, dass es dem Markengebietsschema entspricht. (Benutzerdefiniertes Gebietsschema wurde auf keinem meiner physischen Geräte installiert.) Dies funktioniert gut, wenn Sie absichtlich vorhandene benannte Gebietsschemata verwenden (en_AU, en_CA, en_GB), aber problematisch für benutzerdefinierte Namen sein können (en_B1, en_XX).

Answer 5

Ich weiß, ich bin ein wenig an die Partei spät, aber Sie können dies tun, indem:

1) Ihre project.properties ändern, indem Sie die Zeile hinzufügen manifestmerger.enabled=true

2) Ändern Sie Ihre Paketnamen in der manifestieren.

3) Aktualisieren/ändern Sie Ihre Ressourcen, Zeichen, Zeichenfolgen, was auch immer.

4) Markieren Sie Ihr Masterprojekt als Bibliothek und legen Sie die Abhängigkeit dafür in Ihrem White-Label-Projekt fest. Voila, White-Label!

Answer 6

Dies ist eine ziemlich alte Frage. Aber jetzt denke ich, der beste Ansatz wird sein, Product Flavours für Android zu verwenden, das das neue Gradle-Build-System verwendet.

• Für jeden Geschmack können Sie applicationId definieren. Es gibt einen Unterschied zwischen packageName und applicationId. ApplicationId identifiziert Ihre App auf dem Gerät und im Google Play Store eindeutig. Letzteres ist für den Code-Namespace. Sie können mehr hier lesen: https://developer.android.com/studio/build/application-id.html
• Für jede Geschmacksrichtung können Sie eine andere Zeichensätze, Zeichenfolgen, andere XML-Datei mit bestimmten Ordner für den Geschmack haben. Sie müssen diese Assets nur in die neuen Dateien einfügen, die sich von den Assets im Ordner main unterscheiden. Dann gibt es buildConfigField Sie können für jeden Geschmack in build.gradle definieren, auf die von Java-Dateien als Ihre Konfigurationen für jedes whitelabel zugegriffen werden kann.
• Sie können auch resValue für jeden Geschmack von dort definieren.
• Sie können auch Ihre AndroidManifest.xml konfigurierbar für Schlüssel usw. mit manifestPlaceholders.

Answer 7

Was Sie brauchen, ist Build-Varianten (a.k.a.App Flavors).

Sie auf hier nachlesen kann https://developer.android.com/studio/build/build-variants.html

Kurz gesagt, dies ermöglicht es Ihnen verschiedene Varianten der App zu haben, die Teil des Codes und Ressourcen gemeinsam nutzen, können aber auch ihre eigenen Ersatz haben. Sie können unter anderem verschiedene Paketnamen/IDs für jede Variante angeben (wie Logo, Farben, Begrüßungsbildschirm und sogar Java-Code).

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

Sie können Ressourcenordner mit dem Namen der Varianten erstellen, in denen Sie Ihre alternativen Ressourcen oder den Quellcode platzieren können. Zum Beispiel src/variantone/res

Der Wechsel zwischen Build-Varianten in Android Studio führt nicht zu Dateiänderungen (Sie wählen nur die "Ausgabe"). Sie können APKs für alle gewünschten Varianten gleichzeitig erstellen. Verwenden Sie den Assistenten in Build/Generate signed APK.

P.S. Hier ist, wie Sie einen anderen Paketnamen für Debug-Builds haben können:

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