[Fmx,Android] Tokyo 10.2.2 App crasht vor Application.Initialize;

[Mavarik]

Zitat von Rollo62:

Das hatte ich natürlich auch so gemacht.

Ich habe das nur eingebaut weil ich das schon so weit zerlegt hatte
und schon diese Zeile den Crash verursacht.
Vermutlich NUR diese Zeile.

Rollo

Bedeutet so geht es auch bei Dir?

[Rollo62]

Ok, ich hab das SDK gelöscht und neu installiert per GetIt.
Jetzt hat er hier API22 eingestellt
und das in CatalogRepository installiert
AndroidNDK-9c_x86
AndroidSDK-24.3.3
AndroidSDKAndTools-XE9

Was soll ich sagen, jetzt läuft die App wieder, und anscheinend auch meine größeren Apps

Also ich hatte Probleme mit Android 5.0 Kompatibilität, und hatte versucht die API von AndroidStudio einzuspielen.
Aber offensichtlich war das API 22 und nicht API23, wie ich versucht hatte.
Verdammte Versionshölle.

Kann es sein das Emba speziell angepasste SDKs/NDKs hat, oder sind das die Gleichen (wovon ich immer ausgehe) ?

Muss weiter Testen.

Dankesehr für die Unterstützung, ich hoffe das ich bald komplett auf Tokyo wechseln kann, mit iOS/MacOs bin ich ja schon, Android fehlt noch.

Rollo

[Rollo62]

Zitat:

Vermutlich NUR diese Zeile.

Ja, das war ja das seltsame.
NUR diese eine Zeile mit Sqlite machte den Crash.

Aber jetzt mit ganz anderer API22 (statt vorher 23), scheints wieder zu Laufen ...

Rollo

[himitsu]

Zitat:

- Start mit Debug

--> Crash

Vielleicht hab ich die Infos übersehn, aber wo knallt es denn?

Der Debugger wird doch hoffentlich auch ein bissl was anzeigen.
Stacktrace usw.

[Rollo62]

Es crasht vor dem Eintritt in die Pascal-Routinen, also vor Initialize.
In C würde ich vor main sagen

Es scheint sich geklärt zu haben, das wird mit den unterschiedlichen API-Versionen zu tun gehabt haben.

Unter Belin konnte ich mit Updates der API arbeiten, und habe komplexere Apps am Laufen mit API-23.

Unter Tokyo scheint es API-22 sein zu müssen, denn dies hat der GetIt Installer installiert.

Ich bin noch am Testen, aber es scheint jetzt unter Android wieder brauchbar zu werden nach dem letzten 10.2.2 Update.

Die APIs hatte ich unter Berlin mit dem Android-Studio verwaltet, unter Tokyo scheint dies das Problem gewensen zu sein.

Ich bin aber noch am Testen.

Der Grund warum ich vom GetIt SDK abgewichen bin waren Probleme mit älteren Phones, auf z.B. Android-5, dise waren unter Belin mit höherem APi oder Update des API gelöst.
Ich bin noch dabei für mich eine Liste der nötigen/möglichen APIs zu Erstellen, ach weil anscheinend ab Android 7 etwas Unruhe in die APIs gekommen war.

Eine problematische/beunruhigende Frage wäre noch:
Warum hat es bei Frank auch gecrasht (minimale App, nur mit FireDac.Sqlite.Phys in den Uses) ?
Die TestApp hängt unten im 1. Post dran, kannst du ja gerne auch mal checken.
Die läuft jetzt jedenfalls wieder, nach der Neuinstallation von SDK/NDK via GetIt.

Rollo

[Rollo62]

In dem Ganzen Versionsdschungel bin ich vielleicht auf der falschen Fährte ?
EDIT: Diese schöne Liste will ich euch auch nicht vorenthalten ...

Laut Emba braucht Tokyo:

Zitat:

Bei der Installation des Produkts installiert RAD Studio die Android SDK-Tools Revision 24.3.3 und das Android NDK. Enthalten sind:

Die Android OS-Version 6.0 (API-Level 23)
Das Android NDK (android-ndk-r9c)

Warnung: RAD Studio unterstützt diese Android-Entwicklungstools. Verwenden Sie keine anderen Versionen oder aktualisieren Sie sie nicht unabhängig von RAD Studio.

(Ok, die Warnung würde ich jetzt ernster nehmen)

Aber trotzdem,
gestern neu mit GetIt installiert wirft mir das Setup nur
SDK: platforms\android-22 raus
NDK: platforms\android-3 bis android-19 raus

Infos:
API-Level:

SDK Version History
- SDK "Zusatz" aktuell: 24.3.3
- BuildTools: 22.0.1
- Platforms: android-22 OK, hier ist mal die gewünschte 22, aber 23 ist noch eins höher
- Platform tools: ???



SDK Tools History

Zitat:

1. SDK Tools, Revision 24.3.3 (June 2015)
   Dependencies:
2. Android SDK Platform-tools revision 19 or later.
3. General Notes:
   Fixed issues with using Ant build tasks with the Eclipse ADT build structure.
   Fixed the emulator boot problem on Mac OS X 10.8.5.

--> Diese "aktuellen" SDK-Tools sind von 2015, und verweisen auch auf womöglich API 19

NDK revision history

Zitat:

1. Header fixes:
   Changed prototype of poll to poll(struct pollfd *, nfds_t, int); in poll.h.
   Added utimensat to libc.so for Android API levels 12 and 19. These libraries are now included for all Android API levels 12 through 19.
   Introduced futimens into libc.so, for Android API level 19.
   Added missing clock_settime() and clock_nanosleep() to time.h for Android API level 8 and higher.
   Added CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME, CLOCK_REALTIME_ALARM, and CLOCK_BOOTTIME_ALARM in time.h.
   Removed obsolete CLOCK_REALTIME_HR and CLOCK_MONOTONIC_HR.

- NDK "Zusatz" aktuell: 9c_x86
- NDK Platforms: android-3 bis android-19 ??
- Release: r9c

--> Nirgends die Rede von API-Level 22 hier, also sind die NDKs doch nur bis API-level 19, oder nicht ?

Laut Android sieht die History folgendermassen aus.

Stimmen diese "API-nummern" bei SDK und NDK etwa nicht überein, sind das womöglich nur unabhängige "revision" Nummern ?

FAZIT: Für mich sieht es in etwa so aus:
FMX fordert:
SDK API-Level android-23
NDK r9c

GetIt installiert:
SDK API-Level android-22: NICHT OK, das scheint mir da nur die 22 statt 23 zu sein
SDK-Tools: 24.3.3 (ist nirgends spezifiziert, scheint aber android-19 zu sein)
NDK r9c: OK, (aber auch hier sehe ich nur android-19, nirgends den Hinweis auf android-23)

Wer kann denn etwas mehr Licht in dieses Dunkel der Versionitis bringen,
welche Version darf/muss da sein bei den SDK/NDK und Tools ?

Rollo

[mensch72]

ich habe eine kleine Übersicht mit "geht gut"/"geht nicht" für Android hier schon mal irgendwo gepostet.

Bei mir war "Tokyo" damals am neuesten JAVA und dem neuesten NDK gescheitert.
- Emba installiert altes "8.x.86er" Java... neu "8.x.14x" oder gar Java "9.0.1" wollte nicht
- gleiches beim NDK, hier geht die Emba Variante, und die "neueste" ging nicht
- SDK !unter Tokyo! "exportieren", Das als TextFile manuell per TextEditor bearbeiten(also alle Path und Files so ändern, das es gemeinsam mit AndoidStudio geht), dann SDK wieder "importieren"... fertig ist eine "beliebige" AndroidSDK Version, bzw. so auch recht einfach mehrere.
- Achtung: man exportiere KEIN SDK von Berlin, um es in Tokyo zu importieren, da hat sich was mit dem "GrundJava" intern geändert, man bekommt dann stets die Info das JAVA Path x,y nicht da, was auch stimmt nur kann man es per Dialog nirgends in der GUI wieder einstellen. Steht dann nur irgendwo in Registry und nervt... mir war damals die Zeit zu schade und ich bin einfach ein VM Backup zurück gegangen


=> ich habe mittlerweile etwas weiter "geforscht" und habe ein aktuelles Java8 sowie ein etwas aktuelleres NDK mit verschiedenen SDKs(API19,API22,API25) verwaltet per AndroidStudio am laufen. (BLE, Sensoren und Debug funktionieren mit Android 4.4 bis 8.0 mit Google Nexus Geräten)

Wenn Zeit, "exportiere" ich all mal meine SDKs unter Tokyo und lade sie als ZIP hier hoch... dann einfach per Texteditor dort alles auf die eigenen Verzeichnisse anpassen und importieren... dann sollte es wie bei mir funktionieren

[Rollo62]

Ich dachte ich hätte Tokyo unter Api-25 auch schon am Laufen, aber dann passiert mal dies, mal das.
- Mal gehen die Sensoren, mal nicht.
- Mal läuft es bis runter zu Android 5.0 (wäre meine Zielvorhgabe), mal nicht.

Wir können gerne mal eine "saubere" Prozessbeschreibung und Tests zur Installation von neuesten APIs,
denn Emba macht das wohl nicht für uns
Die nötigen APIs können wir gerne mal abgleichen.

Bin auch weiter am forschen, aber ich muss im Moment noch andere Feature-Updates bei mir fertigmachen, dann kann ich weiter mit Android spielen.

Jedenfalls die gute Nachricht scheint zu sein: Rx10.2.2 läuft wieder mehr oder weniger mit Android
Zumindest für meine Apps (habe momentan 3 getestet, und einige Emba Demos).
Die Details was geht/was nicht muss ich aber noch rausfrickeln.

Edit:
Zu "eigenen Verzeichnissen", ich hatte etwas gefunden das RadStudio nur CatalogRepository als Ziel akzeptiert (so wie von GetIt angelegt).
Hast du da vielleicht auch etwas zu herausgefunden ?

Rollo

[mensch72]

beim NDK verwende ich produktiv derzeit noch das Verzeichnis und die Version von GetIT
beim SDK verwende ich schon wieder die vom AndroidStudio verwalteten und woanders abgelegten Dateien und Pathe


ach ja, "SDK anlegen" per RadStudio funktioniert bei mir nicht, ich exportiere ein SDK, bearbeite es als Textfile und importiere es wieder.
Alleine weger der Archivierung und dem Transfer der Einstellung auf andere Installationen wull und muss ich das so machen

[Rollo62]

Bei mir ist gerade die aktuelle GetIt configuration drin, auf etwas anderem Pasispfad.
Aber ansonsten ähnlich, bis auf ein paar Unterschiede.

Wie du unten schreibst hast du anscheinen auf API26 und BuildTools 26.0.3 upgedatet.
NDK sollte gleich sein, aber bei Beiden unterschieden sich die Pfade ein wenig.
- Ich habe es angelegt mit neues Projekt, dann kompilieren, startet den GetIt-Installer.
- Du hast womöglich via Tools\GetIt installiert

Trotzdem seltsam das es dabei Unterschiede gibt.

Der NDK Basispfad AndroidNDK-9c_x86 statt ...19.028979.1978 deutet ein wenig darauf hin das diese Packages von Emba angelegt wurden (...19.028979.1978), und nicht das Orginal Android NDK verwendet wird.

Hast du mal gecheckt ob die Files in den Verzeichnissen r9c von Emba und r9c von Android 1:1 gleich sind ?
Leider habe ich im Moment kein Android r9c installiert, sonst hätte ich selbst mal eben nachgeschaut.
Ich vermute das Emba da vielleicht noch die ein oder andere Library angepasst hat.

Zitat:

SDK-Basispfad
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidSDK-24.3.3

ZipAlign
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidSDK-24.3.3\build-tools\22.0.1\zipalign.exe // statt 26.0.3

Aapt
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidSDK-24.3.3\build-tools\22.0.1\aapt.exe // statt 26.0.3

API-level location
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidSDK-24.3.3\platforms\android-22 // statt 26



NDK-Basispfad
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidNDK-9c_x86 statt ...19.028979.1978

arm-abi toolchain
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidNDK-9c_x86\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-ld.exe

GDB-Server
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidNDK-9c_x86\prebuilt\android-arm\gdbserver\gdbserver

NDK-API
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidNDK-9c_x86\platforms\android-14

C++ Builder library pfad
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidNDK-9c_x86\platforms\android-14\arch-arm\usr\lib

Delphi library pfad
C:\Users\Public\Documents\Embarcadero\Studio\19.0\ CatalogRepository\AndroidNDK-9c_x86\sources\cxx-stl\gnu-libstdc++\4.8\libs\armeabi-v7a;C:\Users\Public\Documents\Embarcadero\Studio\1 9.0\CatalogRepository\AndroidNDK-9c_x86\platforms\android-14\arch-arm\usr\lib



Java
C:\Program Files\Java\jdk1.8.0_60\bin\keytool.exe
C:\Program Files\Java\jdk1.8.0_60\bin\jarsigner.exe