Android-Bundle: Problematische Geräte 50% im Vergleich zu Android-32-APK

[philipp.hofmann]

Man sieht in meinem Bundle-File, dass die Libraries dort landen, wo sie eigentlich hingehören und ich habe es über den Bereitstellungsmanager konfiguriert, so wie es auch der Komponentenhersteller dokumentiert hat. Und ich habe auch das Patch von EMBT installiert, weil es gab im Bundle noch ein Problem in den XML-Konfigurationen. Beim lokalen Deployment klappt es bei meinen Geräten damit auch sowohl unter Android-32 und Android-64.

Ich glaube nicht, dass es bei Android-64 über die Build-Settings funktionieren kann, denn du musst im Bereitstellungsmanager des Android-64-Zweiges, sowohl die Android-32-so-Libraries als auch die Android-64-so-Libraries konfigurieren, damit beides im Bundle landet, weil du brauchst definitiv weiterhin die Android-32-Version, weil Unmengen von Android-Geräten sind 32-Bit und um es noch komplizierter zu machen, ist es auch noch vom Store abhängig:

Ich liefere aktuell zwei Android-Zweige aus:
a) Für den Amazon-App-Store (also für Amazon-Fire-Devices) liefere ich eine reine Android-32-bit-Version als apk-File aus. Hier sind dann nur die 32-bit-Libraries enthalten. Diese wird in Delphi mit der Android-32-Konfiguration gebuildet.
b) Für den Google-PlayStore liefere ich die Bundle-Version aus (d.h. das aab-File, welches sowohl die Android-32-bit- als auch die Android-64-bit-Version beinhaltet und in Delphi mit der Android-64-Konfiguration gebuildet wird).

Eigentlich ist es auch Sache des Komponentenhersteller, wie sich dies lösen lässt. Ich habe jetzt sowohl EMBT als auch den Komponentenhersteller mit einem Beispiel-Projekt versorgt, wo man sieht, was passiert und das der "normale" Weg bei 75% der Devices funktioniert und bei ein paar Ausnahmen nicht. EMBT hat jetzt einen alternativen Vorschlag gemacht, der wieder bei 75% der Devices funktionierte, dafür aber waren die nicht funktionierenden Devices andere. Daher mache ich jetzt einfach die Kombination aus beidem (bzw. bei OpenSSL sind es drei Wege, die zum Ziel führen).

Der Rest ist jetzt nicht mehr mein Bier, ich habe dem Hersteller von AVPlayer schon genügend unter die Arme gegriffen, da dort leider noch nicht alles so funktionierte wie es soll (z.B. habe ich letztes Wochenende gerade relativ viel Zeit investiert, um aufzuzeigen, wie man zur Laufzeit eines Liedes/Videos das Output-Device unter Windows und MacOS wechseln kann, man wollte mir erzählen, dass dies nicht (stabil) funktioniert und man die App neu starten muss und das ist nur einer von vielen Punkten auf der Liste, was dort noch zu tun war - jetzt läuft es meiner Meinung nach stabil und zufriedenstellend).

[Rollo62]

Also das heisst Du fummelst das selber per UNZIP/ZIP in die ABB.

Eigentlich sollte es doch komplett durch die IDE verarbeitbar sein, was spricht dagegen ?

Es gibt ja zwei Zweige im Projekt:

Project\Android\Libraries
- Package1_32
- Package2_32
Project\Android64\Libraries
- Package1_64
- Package2_64

von dort automatisch ins Deploment, läuft oder lief schnmal so
Deployment\Android32
Deployment\Android64

von dort automatisch ins Bundle, bei Ausführen von Deploy
ARM7
Arm8

Ich hoffe mal das ist am Ende das eigentliche Ziel von EMBA.
Mal hoffen das es bald über die IDE-Konfiguration Bug-Frei so läuft wie gedacht.

Amazon ist ja ein anderes Thema, und kann damit auch wie bisher erstelt werden.

[philipp.hofmann]

Nein, ich fummele nichts per Hand in die ABB und im Bereitstellungsmanager ist es dann wie folgt konfiguriert:

1. Android-32:
a) alle 32-bit-Libraries (so-files) nach library\lib\armeabi-v7a\

2. Android-64:
a) alle 32-bit-Libraries (so-files) nach library\lib\armeabi-v7a\
b) alle 64-bit-Libraries (so-files) nach llibrary\lib\arm64-v8a\

2.a) ist notwendig, damit das Bundle beides enthält. Die 1.Konfiguration wird bei der Erstellung des Bundles vollkommen ignoriert.