AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Cross-Platform-Entwicklung Android-Bundle: Problematische Geräte 50% im Vergleich zu Android-32-APK

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

Ein Thema von philipp.hofmann · begonnen am 7. Dez 2019 · letzter Beitrag vom 12. Mär 2020
Antwort Antwort
Rollo62

Registriert seit: 15. Mär 2007
4.165 Beiträge
 
Delphi 12 Athens
 
#1

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

  Alt 19. Dez 2019, 21:42
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.
  Mit Zitat antworten Zitat
philipp.hofmann

Registriert seit: 21. Mär 2012
Ort: Hannover
917 Beiträge
 
Delphi 10.4 Sydney
 
#2

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

  Alt 20. Dez 2019, 00:24
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}
Angehängte Grafiken
Dateityp: jpg Bereitstellung.jpg (136,7 KB, 21x aufgerufen)

Geändert von philipp.hofmann (20. Dez 2019 um 00:26 Uhr)
  Mit Zitat antworten Zitat
philipp.hofmann

Registriert seit: 21. Mär 2012
Ort: Hannover
917 Beiträge
 
Delphi 10.4 Sydney
 
#3

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

  Alt 20. Dez 2019, 09:38
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.
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
4.165 Beiträge
 
Delphi 12 Athens
 
#4

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

  Alt 20. Dez 2019, 12:22
Kannst Du nicht Indy durch die System.Net Komponenten ersetzen, damit man das SSL der OS nutzen kann ?
  Mit Zitat antworten Zitat
philipp.hofmann

Registriert seit: 21. Mär 2012
Ort: Hannover
917 Beiträge
 
Delphi 10.4 Sydney
 
#5

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

  Alt 20. Dez 2019, 16:40
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.

Geändert von philipp.hofmann (20. Dez 2019 um 17:46 Uhr)
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
4.165 Beiträge
 
Delphi 12 Athens
 
#6

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

  Alt 21. Dez 2019, 20:33
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.
  Mit Zitat antworten Zitat
philipp.hofmann

Registriert seit: 21. Mär 2012
Ort: Hannover
917 Beiträge
 
Delphi 10.4 Sydney
 
#7

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

  Alt 21. Dez 2019, 23:26
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.
  Mit Zitat antworten Zitat
philipp.hofmann

Registriert seit: 21. Mär 2012
Ort: Hannover
917 Beiträge
 
Delphi 10.4 Sydney
 
#8

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

  Alt 29. Dez 2019, 11:10
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)

Geändert von philipp.hofmann (29. Dez 2019 um 11:33 Uhr)
  Mit Zitat antworten Zitat
philipp.hofmann

Registriert seit: 21. Mär 2012
Ort: Hannover
917 Beiträge
 
Delphi 10.4 Sydney
 
#9

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

  Alt 23. Jan 2020, 18:03
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.
  Mit Zitat antworten Zitat
fppoels
(Gast)

n/a Beiträge
 
#10

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

  Alt 4. Mär 2020, 22:19
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.
  Mit Zitat antworten Zitat
Antwort Antwort

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:35 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz