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

[philipp.hofmann]

Hi,

ich habe meine App bisher als apk-32bit-Datei in den Google PlayStore hochgeladen (mit Delphi 10.3.2 kompiliert). Bei den Pre-Launch-Berichten hatte ich immer die Anzahl an problematischen Geräten=0. Jetzt habe ich erstmals die App als Bundle (sprich 32-bit und 64-bit) hochgeladen und plötzlich ist die Hälfte der getesteten Geräte problematisch, sprich die App startet dort erst gar nicht. Im Android-Log kann ich wenig erkennen, im Video sehe ich, dass der Splash-Screen nicht verlassen wird. Meine App selbst erzeugt keine Exception, sonst würde mir das die App direkt melden.

Ich habe jetzt die gleiche Version nochmals als apk-32bit-Datei hochgeladen (dieses Mal mit Delphi 10.3.3 kompiliert) und es wurden wieder keine problematischen Geräte gefunden.

Hat sonst noch jemand Erfahrung mit den Bundles.

Grüße, Philipp

[TurboMagic]

Hast du eine 64 Bit Version deiner App schon mal erfolgreich auf einem
64 Bit Android Gerät getestet?

Also mal nur für 64 Bit compilieren und auf 64 Bit Gerät ausführen.
Ggf. monitor.bat aus dem Android SDK starten um die Logcat Logmeldungen
anzeigen zu können.

[philipp.hofmann]

Ja, auf meinen Geräten läuft alles stabil. Ich habe aber tatsächlich nur zwei 64-bit Device (Samsung S4-Tablet und Samsung S10-Handy). Der Rest ist alles 32-bit.

[philipp.hofmann]

Den ersten Punkt habe ich jetzt schon mal verstanden. Man muss in der Android-64-Bereitstellung trotzdem alle 32-bit Libraries mit dem Remote-Pfad library\armeabi-v7a\ und alle 64-bit-Libraries mit dem Pfad library\lib\arm64-v8a\ aufnehmen. Sonst funktioniert die Bundle-Datei nicht.

[Rollo62]

Ja davon gehe ich mal aus, den das AAB beinhaltet Beides.
Erst im PlayStore wird das evtl wieder auseinandergenommen, aber das macht Google.
Hattest Du die manuell weggeschaltet, oder war da ein Fehler beim AAB Linken ?
Normalerweise sollten die Libraries alle korrekt dabei sein wenn man ein neues Projekt anlegt.

[philipp.hofmann]

Für den AV-Player muss ich manuell Libraries hinzufügen und für OpenSSL. Ich hatte in der Android-32-Bereitstellung die 32-Bit-Version hinzugefügt und in der Android-64-Bereitstellung die 64-Bit-Version und bin dann davon ausgegangen, dass Delphi für das Bundle beides zusammenfasst. Aber wie gesagt, ich musste manuell in der Android-64-Bereitstellung beide Lib-Sets hinzufügen und v.a. bei OpenSSL dann auch die zur nutzende Verzeichnisse anpassen:

Code:

  
  {$IFDEF ANDROID}
    {$IFDEF CPU64BITS}
      IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetDocumentsPath())+'libssl64');
    {$ELSE}
      IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetDocumentsPath())+'libssl32');
    {$ENDIF}
  {$ENDIF}

[philipp.hofmann]

Jetzt habe ich nur noch 25% problematische Devices, dies hängt aber eher an der Library von AV-Player:

Huawei P8 Lite - Android-Modelname (64-bit): ALE-L23

12-19 21:44:17.267: I/info(30839): FMX: icTrainer: INFO: MediaCenter used TAVPlayer
12-19 21:44:17.277: I/art(30839): Can not find class: Lcom/embarcadero/firemonkey/dialogs/FMXDialogFactory;
12-19 21:44:17.277: I/art(30839): Can not find class: Lcom/embarcadero/firemonkey/dialogs/FMXStandardDialog;
12-19 21:44:17.317: I/art(30839): Can not find class: Lcom/embarcadero/firemonkey/dialogs/FMXDialogListener;
12-19 21:44:17.467: E/Thermal-daemon(2351): [ap] temp_new :42 temp_old :43

Google Pixel 3 - Android-Modelname (64-bit): Pixel 3

12-19 21:49:26.240: I/info(18046): FMX: icTrainer: INFO: MediaCenter used TAVPlayer
12-19 21:49:26.698: W/z(18016): Skipping null root node for window: AccessibilityWindowInfo[title=Device Details, id=0, type=TYPE_APPLICATION, layer=0, bounds=Rect(0, 0 - 1080, 2160), focused=true, active=true, pictureInPicture=false, hasParent=false, isAnchored=false, hasChildren=false]
12-19 21:49:26.767: W/.android.chrom(18472): JIT profile information will not be recorded: profile file does not exits.
12-19 21:49:26.936: I/PeopleChimeraService(17240): onService. callbacks = aaga@839799, request = com.google.android.gms.common.internal.GetServiceR equest@98e5a5e
12-19 21:49:26.972: I/ActivityManager(1164): Killing 16724:com.google.android.calendar/u0a124 (adj 906): empty #17
12-19 21:49:26.973: W/libprocessgroup(1164): kill(-16724, 9) failed: No such process
12-19 21:49:26.987: I/ActivityManager(1164): Start proc 18585:com.google.android.apps.wellbeing/u0a26 for broadcast com.google.android.apps.wellbeing/com.google.apps.tiktok.account.data.device.DeviceA ccountsChangedReceiver_Receiver
12-19 21:49:26.994: W/libprocessgroup(1164): kill(-16724, 9) failed: No such process
12-19 21:49:26.995: E/.apps.wellbein(18585): Not starting debugger since process cannot load the jdwp agent.
12-19 21:49:27.001: I/Zygote(733): Process 16724 exited due to signal (9)
12-19 21:49:27.005: W/libprocessgroup(1164): kill(-16724, 9) failed: No such process
12-19 21:49:27.005: I/libprocessgroup(1164): Successfully killed process cgroup uid 10124 pid 16724 in 31ms
12-19 21:49:27.022: I/.apps.wellbein(18585): The ClassLoaderContext is a special shared library.

Google Pixel 2 - Android-Modelname (64-bit): Pixel 2

12-19 21:49:38.253: I/Finsky(10984): [179] mvt.b(40): IQ: Notifying installation update. package=com.google.android.soundpicker, status=SCHEDULED
12-19 21:49:38.273: I/Finsky(10984): [179] mvt.b(40): IQ: Notifying installation update. package=com.google.ar.core, status=SCHEDULED
12-19 21:49:38.273: I/Finsky(10984): --------- beginning of crash
12-19 21:49:38.276: A/google-breakpad(12373): Microdump skipped (uninteresting)
12-19 21:49:38.283: W/google-breakpad(11950): ### ### ### ### ### ### ### ### ### ### ### ### ###
12-19 21:49:38.283: W/google-breakpad(11950): Chrome build fingerprint:
12-19 21:49:38.283: W/google-breakpad(11950): 71.0.3578.99
12-19 21:49:38.283: W/google-breakpad(11950): 357809952
12-19 21:49:38.283: W/google-breakpad(11950): ### ### ### ### ### ### ### ### ### ### ### ### ###

Mal sehen, wie wir da zurande kommen.

[Rollo62]

Kannst Du nicht Indy durch die System.Net Komponenten ersetzen, damit man das SSL der OS nutzen kann ?

[philipp.hofmann]

Ich nutze TIdHttp für Downloads, dass wäre recht gut durch System.Net ersetzbar und TIDSMTP für E-Mails zu versenden. Bei zweiterem wüsste ich nicht, wie ich dies ersetzen soll. Daher ist OpenSSL jetzt zunächst drinnen.

Irgendwann werde ich aber zumindest den ersten Schritt für den Download gehen und diese mit System.Net umsetzen, muss aber auch dafür mal schauen, wie dies funktioniert (z.B. den Fortschritt anzeigen, Authentication und den Download sauber in einem separaten Thread durchführen), ist also auch kein 5-Minüter.

[Rollo62]

Man kann auch emails ohne Indy versenden
https://stackoverflow.com/questions/...app-delphi-xe7

Aber ich vermute mal Du möchtest das ohne Android.Dialog erledigen.
Vielleicht wäre ein Ausweg über einen REST Service zu bauen.

[philipp.hofmann]

Ja, ich will nicht den jeweiligen OS-Dialog für die Mails nutzen, sondern direkt Mails versenden. Für die Downloads habe ich jetzt auf System.Net umgestellt, das ist schon smarter, für die Mails stört mich aktuell OpenSSL noch nicht so richtig. Das letzte Problem für 64-Bit ist ja jetzt auch nur, dass der AVPlayer nicht auf allen Geräten läuft. Er läuft generell in 32-bit und auf 64-bit nur auf der Hälfte der Geräte. Da hoffe ich, dass der Hersteller nachbessert und so lange bleibe ich aktuell bei meiner 32-Bit-Auslieferung.

[Bernhard Geyer]

Zitat:

Zitat von philipp.hofmann (Beitrag 1453834)

Ja, ich will nicht den jeweiligen OS-Dialog für die Mails nutzen, sondern direkt Mails versenden.

Wieso willst du das machen?
Gibt dir jeder Nutzer wohl seine Zugangsdaten für sein Konto?
Oder willst du nur einen Datenrückkanal haben.
Dann würde ich den Vorschlag von Rollo62 umsetzen und das über REST machen.

[philipp.hofmann]

Ich verschicke aus der App auf User-Request Status-Mails über meinen eigenen SMTP-Server, relativ einfache Sache, daher reicht mir da die Indy-Lösung. Seht ihr da ein Stabilitätsproblem?

[philipp.hofmann]

Zitat:

Man muss in der Android-64-Bereitstellung trotzdem alle 32-bit Libraries mit dem Remote-Pfad library\lib\armeabi-v7a\ und alle 64-bit-Libraries mit dem Pfad library\lib\arm64-v8a\ aufnehmen.

Das stimmt so leider nicht, weil die so-Dateien dann nicht auf jedem Device gefunden werden. Ich habe vier Sets von Libraries und stelle diese nun folgendermaßen bereit:

AV-Player 32-Bit .\assets\internal\libavplayer32\
AV-Player 64-Bit .\assets\internal\libavplayer64\
OpenSSL 32-Bit .\assets\internal\libssl32\
OpenSSL 64-Bit .\assets\internal\libssl64\

Daher muss ich dann die Pfade in Form.create setzen:

Delphi-Quellcode:

  {$IFDEF ANDROID}
    {$IFDEF CPU64BITS}
      sslPath:=IncludeTrailingPathDelimiter(TPath.GetDocumentsPath())+'libssl64';
      avPlayerPath:=IncludeTrailingPathDelimiter(IncludeTrailingPathDelimiter(TPath.GetDocumentsPath())+'libavplayer64');
    {$ELSE}
      sslPath:=IncludeTrailingPathDelimiter(TPath.GetDocumentsPath())+'libssl32';
      avPlayerPath:=IncludeTrailingPathDelimiter(IncludeTrailingPathDelimiter(TPath.GetDocumentsPath())+'libavplayer32');
    {$ENDIF}
    IdOpenSSLSetLibPath(sslPath);
    avlib.FFMPEG_DLL_PATH:=avPlayerPath;
  {$ENDIF}

Nachteil: Die 32-bit und die 64-Bit-Version wird so rund 10 MB größer, weil eben immer alle 4 Sets an Libs enthalten sind, aber nur so werden die Libraries auch auf allen Devices gefunden. Sonst werden die so-Files auf 3 von 12 der getesteten Geräte (Prelaunch-Report) nicht entpackt, warum auch immer (ich kann keine Logik, wie 32-bit oder 64-bit entdecken). Es gibt auch schon ein Patch, welches sich mit dem Issue beschäftigt, dieses hat bei mir aber nicht geholfen (https://cc.embarcadero.com/item/30905).

Jetzt habe ich nur noch einen Fehler unter Android 5.0 und 64-Bit, welchen ich vernachlässige und eine Warnung mit folgendem Fehler (also nur noch 1 von 12 sind im Vergleich zu 32-bit-Version fehlerhaft gemeldet):

Problem: java.lang.OutOfMemoryError: Failed to allocate a 112 byte allocation with 1224 free bytes and 1224B until OOM

Code:

FATAL EXCEPTION: FinalizerWatchdogDaemon
Process: com.android.vending, PID: 978
java.lang.OutOfMemoryError: Failed to allocate a 112 byte allocation with 1224 free bytes and 1224B until OOM
   at gtk.uncaughtException(PG:3)
   at java.lang.Daemons$FinalizerWatchdogDaemon.finalizerTimedOut(Daemons.java:316)
   at java.lang.Daemons$FinalizerWatchdogDaemon.run(Daemons.java:238)
   at java.lang.Thread.run(Thread.java:818)

[philipp.hofmann]

Jetzt mal noch die Info, wie man externe so-Files aktuell einbinden kann, wenn man Bundles benutzt. Ich habe die Libraries jetzt in folgende Pfade gesteckt:

- AV-Player

- 32-Bit-so-files -> library\lib\armeabi-v7a\

- 64-Bit-so-files -> library\lib\arm64-v8a\

- OpenSSL

- 32-Bit-so-files -> library\lib\armeabi-v7a\

- 64-Bit-so-files -> llibrary\lib\arm64-v8a\

Das Problem hier ist, dass je nach Device die Libraries in unterschiedlichen Pfaden gesucht werden. Lösung ist für mich jetzt, dass ich diese Pfade hintereinander durchprobiere, wobei dies je nach Komponente unterschiedlich geht. Dies ist deutlich platzsparender als die Lösung vom 29. Dez 2019 11:10, wo die Libraries für Android-32 auch unnötigerweise die 64-bit-Versionen enthielten und umgekehrt.

Open-SSL:

Delphi-Quellcode:

  {$IFDEF ANDROID}
    IdOpenSSLSetLibPath(String.Empty);
    IdSSLOpenSSLHeaders.Load();
    error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
    if (length(error)>0) then
    begin
      IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetLibraryPath));
      IdSSLOpenSSLHeaders.Load();
      error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
      if (length(error)>0) then
      begin
        IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetDocumentsPath));
        IdSSLOpenSSLHeaders.Load();
        log.d('SSL-Version(3): '+OpenSSLVersion);
        error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
        if (length(error)>0) then
        begin
          log.d('SSL-Errors: '+error);
        end;
      end else begin
        log.d('SSL-Version(2): '+OpenSSLVersion);
      end;
    end else begin
      log.d('SSL-Version(1): '+OpenSSLVersion);
    end;
  {$ENDIF}

AV-Player (http://www.flashavconverter.com/cont...hi-component):

Delphi-Quellcode:

  {$IFDEF ANDROID}
    try
      avlib.FFMPEG_DLL_PATH:=string.Empty;
      avPlayerVideo:=TAVPlayer.Create(mainForm);
    except on E: Exception do
      begin
        avlib.FFMPEG_DLL_PATH:=IncludeTrailingPathDelimiter(TPath.GetLibraryPath);
        avPlayerVideo:=TAVPlayer.Create(mainForm);
      end;
    end;
  {$ENDIF}

Ich bin da mit EMBT noch dran (https://quality.embarcadero.com/browse/RSP-27336), wobei die Hauptkommunikation via E-Mail läuft.

[Rollo62]

Dankesehr für die Info.

Ich bin mir jetzt nicht sicher wo Du die Libraries einstellst, über den Deployment-Manager vermute ich.
Falls das hier unten schon steht, sorry, ich habe mir die vorherigen Punkten icht komplett durchgelesen.

Ohne es jetzt ausprobiert zu haben, es gibt ja unter Build-Setting im Project auch die Libraries-Zweige.
Unter iOS kann man da .a Files entsprechend hinkopieren, und es gelangt automatisch ins Deployment.

Das gibt es unter Android auch, und da liegen normalerweise ein paar Systemlibraries.

Es sollte doch möglich sein die Library-Zweige um Custom-Libraries zu ergänzen, so wie unter iOS auch.
Ich denke es ist ja generell dafür gedacht.
Dann sollten naturlich die richtigen Libraries am Ende in den richtigen Pfad kommen (gesteuert durch die IDE),
also von Library32 in den Pfad für 32-Bit, etc.


Hast Du das mal ausprobiert, oder nur über den Deploment-Manager ?
Falls es nicht geht, dann bitte rege das doch bei EMBA mal an.

[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.

[fppoels]

Hast du eine 64 Bit Version deiner App schon mal erfolgreich auf einem
64 Bit Android Gerät getestet?

Also mal nur für 64 Bit compilieren und auf 64 Bit Gerät ausführen.
Ggf. monitor.bat aus dem Android SDK starten um die Logcat Logmeldungen
anzeigen zu können.

[philipp.hofmann]

Natürlich teste ich die App sowohl auf 32- als auch auf 64-bit Geräten. Das Problem passiert auch nicht bei meinen Geräten, das wäre easy. Es passiert nur, wenn du das Bundle hochlädst und dann der Prelaunch-Report von Google mit einer Vielzahl von Geräten durchgeführt wird. Für zumindest zwei Bibliotheken habe ich die Lösung ja auch hier schon gepostet, man muss eben nur wissen wie.

[philipp.hofmann]

Hier zur Info, die Lösung, welche für die TAVPlayer-Implementierung und zwar sowohl für das Google-Bundle als auch die Amazon-Auslieferung funktioniert. Dafür waren gemeinsam mit dem Delphi-Support mindestens 5 Testrunden notwendig bis alles klappte.

Hi Lifang,

the following avlib.pas-implementation was now successful for all Google-Prelaunch-(32/64bit-Bundle) and all Amazon-Prelaunch-Tests (32bit):

a)

Delphi-Quellcode:

   {$IFDEF Android}
        FFMPEG_DLL_PATH:=TPath.GetLibraryPath+'/';
        {$ENDIF}

b)

Delphi-Quellcode:

function MySafeLoadLibrary(ModuleName:string):HMODULE;
   var
  Error: string;

  {$IF Defined(ANDROID)}
  function ShouldNativeLibrariesBeExtracted: Boolean;
  begin
    if TOSVersion.Check(6, 0) then
      Result := (TAndroidHelper.Context.getApplicationInfo.flags and TJApplicationInfo.JavaClass.FLAG_EXTRACT_NATIVE_LIBS) <> 0
    else
      Result := True;
  end;
  {$ENDIF}
begin
  {$IF Defined(ANDROID)}
  if ShouldNativeLibrariesBeExtracted then
    ModuleName := TPath.Combine(TPath.GetLibraryPath, ModuleName);
  {$ENDIF}

  Result := LoadLibrary(PChar(ModuleName));

  if Result = 0 then
  begin
    Error := string.Format('Could not load ''%s'' due to: %s', [ModuleName, string(UTF8String(dlerror))]);
   log.d('mySafeLoadLibrary: '+error);
    ShowMessage(Error);
    raise Exception.Create(Error);
  end;
end;

Best regards, Philipp

[TurboMagic]

Hallo,

einen kleinen Verbesserungsvorschlag zu der geposteten Lösung:
gib doch den Formatstring Platzhaltern Indizes.

%0:s und %1:s, dann ist das Übersetzen flexibler!

Grüße
TurboMagic