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.