Android Patch für 10.2 Tokyo verfügbar

[MEissing]

https://cc.embarcadero.com/item/30781

ID: 30781, FireMonkey Android Compatibility Patch for RAD Studio 10.2
(Auch für die Trial verfügbar!)

FireMonkey Android Compatibility Patch for RAD Studio 10.2 Tokyo

This patch addresses critical Android issues in Delphi, C++Builder and RAD Studio 10.2 around text input for newer versions of Android (issues that were already present in Berlin), control rendering and performance regressions (issues introduced in Tokyo).
Below is a list of Quality Portal items that were fixed in this patch.

RSP-17308 TForm.Close and caFree not Working with Android
RSP-17120 caFree not working (Android)
RSP-17162 Android app made with Tokyo are super slow
RSP-17165 TAniIndicator fails to draw correctly on Android
RSP-17173 Android Severe painting problems - Worked in Berlin Version
RSP-17177 Android Application->OnIdle Failed
RSP-17189 Application crash with 'Can not activate current context' exception
RSP-17636 Android Painting cannot handle bitmap canvas paints
RSP-17652 TListView Performance Degraded when compiled with Tokyo
RSP-17654 TImageList saved in Berlin, do not show its images in Tokyo at runtime in Android.
RSP-17663 Delphi 10.2 Tokyo (Mobile platform) - use the FmxObject.AddObject component will occurs image overlay problem
RSP-17687 Bitmap is no more displayed on Android 4.1.2 device
RSP-17738 Delphi 10.2 Tokyo (Android platform) - TabControl problem
RSP-17803 FMX TListBox does not display images
RSP-17816 FillText problem on Android
RSP-15074 TMemo adds text when clearing Text on Android 6
RSP-15775 Android class initialization limitation (segmentation fault)
RSP-16149 Android 7 Nougat Using TEdit, pressing return on android keyboard wraps text.
RSP-17262 SubClassed FMX TEdit runs on Win32, Not on Android. Seg fault.
RSP-16668 App crashes on use of Backspace key in a TEdit
RSP-16778 Problem to edit text in tedit and tmemo in Android 6
RSP-17232 Duplicate words appear on pressing backspace in an FMX TEdit in android
RSP-17546 SubscribeToMessage in Android will crash
RSP-17346 Android TEdit and TMemo clipboard copy/cut is not working
RSP-16935 Android's TMemo and TEdit Cursor Issue + Suggested Complete Solution
After this patch, we plan to deliver additional improvements in an upcoming point release for 10.2 Tokyo for all product areas (iOS, Android, Windows, macOS and Linux).

Note: For Update Subscription customers, we have also updated the library source code of the units touched by this patch which you can access in an additional optional download.

How to install: Customers on 10.2, including trial customers, can install this patch on top of their existing 10.2 product installation. It requires that you have RAD Studio 10.2 already installed.

Important installation note for Update Subscription (non-trial) Customers: As an Update Subscription customer, you are eligible to install the 10.2 Tokyo Toolchain hotfix. This hotfix needs to be installed prior to installing the Android patch. If you install the Android patch first, and then the toolchain hotfix, you will need to reinstall the Android patch.

[Rollo62]

Danke danke danke, meine Gebete wurden erhört :-D

Für die Sources im Patch, welche Position ist die richtige ?
Im Patch unter \Androiddex wird folgendes Verzeichns benutzt
Souce: \androiddex\fmx\com\embarcadero\firemonkey\
Anhang 47578

unter dem realen BDS Source\Androiddex liegt es aber hier:
Source: \rtl\androiddex\java\fmx\src\com\embarcadero\firem onkey\
Anhang 47579

Sind die Verzeichnisse wirklich geändert worden, oder soll ich die entsprechenden Units überschreiben ?
Falls ja, was ist mit den alten Units, sollen die gelöscht werden ?
Wenn ja, dann auch Alles andere drumherum ?

Rollo

[mensch72]

Ich habe es per 2x VM(SnapShot) in beiden Varianten versucht...

-> manuell alles so kopieren, das alles 1:1 überschrieben wird, dann stimmt beim Debug der Source

(leider nix für BLE dabei, das geht in Tokyo immernoch "seltsam" :( )

[Sherlock]

Das sieht doch endlich mal nach einem richtigen Installer aus. Warum gibt es da noch Probleme beim "patchen"? Hab Tokyo noch nicht installiert, darum kann ich es selbst nicht ausprobieren.

Sherlock

[bra]

https://quality.embarcadero.com/browse/RSP-17189

Zitat:

I've tried the update. Old bugs out, new bugs in. An app that previously ran OK, albeit with a few issues around threading, now force closes on Android after about 10 minutes of running. The painting issue appears to have been fixed, but now after an app has been running for a few minutes it becomes very unresponsive. Clicking a button that's connect to a TChangeTabAction can now take 4 or 5 seconds to actually change the tab, whereas before this fix it was almost instant. I'm going to do some more testing, but it doesn't look good from my initial tests.

Das wird nichts mehr bei EMB... :roll:

[SneakyBagels]

@bra

meiner Meinung nach hätte man sich noch etwas länger mit der IDE selber und den bereits bestehenden Fehlern befassen sollen, bevor man iOS, Linux und Android unterstützt.
Aber andererseits kann ich auch verstehen, dass es nicht so ist. Denn man muss ja eine Lösung anbieten, die andere auch anbieten.

Stattdessen hat man jetzt eine große Menge angefangener Baustellen die niemals fertig werden, weil immer mehr Baustellen dazukommen :(

[stalkingwolf]

Wenn ich das korrekt verstehe gibt es das Problem auch schon in Berlin? Aber der Patch kommt nur für Tokyo?

Wie unproblematisch ist die Installation von 10.2 über 10.1? Das Image habe ich hier herumliegen.

[bra]

Mit Berlin funktionieren Apps unter Android, mit Tokyo quasi gar nicht mehr.

[Aviator]

Zitat:

Zitat von stalkingwolf (Beitrag 1375228)

Wenn ich das korrekt verstehe gibt es das Problem auch schon in Berlin? Aber der Patch kommt nur für Tokyo?

Wie unproblematisch ist die Installation von 10.2 über 10.1? Das Image habe ich hier herumliegen.

Habe auf einem System sowohl Delphi 10.1 Berlin als auch Delphi 10.2 Tokyo am laufen. Installation funktionierte über den Web-Installer problemlos würde ich sagen. Beide Versionen laufen auch parallel.

Etwas anderes außer VCL Entwicklung mache ich damit also nicht. Kann also nicht sagen, dass die Installation der Android Komponenten nicht doch irgendwelche Risiken birgt. Die habe ich bei mir nämlich bei der Installation außen vor gelassen.

[Rollo62]

Hallo Mensch72,

ja ich habe natürlich auch die entsprechenden Files überschrieben.
Da hat wohl jemand beim ZIP-Erstellen etwas geschlafen.

Es läuft etwas besser, aber immer noch so das ich das nicht uploaden kann.
Werde wohl noch bei Rx10.1Upd2 bleiben müssen.

• Zumindest sieht Alles bei mir wieder wie es soll aus, die "Geisterbilder" bei Glyphs und ImageList sind weg.
• Leider ist es immer noch sehr langsam, und scheint sich alle 5-10 Sekunden mal zu verschlucken.
  Weil ich klene Datenpakete per BLE an die App sende, also ca. 10 Byte alle 200ms, wird das gepuffert und
  kommt dann in einem Rutsch durchgerattert alle 5-10 Sek.
• MakeScreenshot scheint auch etwas falsch zu rendern, die Auflösung von gezeichneten Pfaden und Fornts ist zu gering.
• Location scheint nich zu gehen, aber ich bekomme regelmäßig "No response from Server" bei GeoCoder
• Es ist auch mal abgestürzt, ich vermute w.g. GeoLocation
• Kamera scheint noch zu gehen
• Speichern und Senden von Daten scheint zu funktionieren. Sowohl Bilder als auch Text lassen sich sharen.
• Das Timing von VKKeyboard scheint auch verändert, wenn es Auf- Zupoppt.
• Ansonsten immer noch recht zäh, es reagiert nicht immer auf Klicks, man muss manchmal zweimal klicken
• Getestet mit Samsung S7 Edge V6.0.1

Fazit: Es ist besser als vorher, aber immer noch ein langer Weg um das wieder so hinzubekommen wie vorher.
Unter Rx10.1Upd2 war noch Alles in Ordnung und lief sehr flott und stabil.

Rollo

[Mavarik]

Zitat:

Zitat von Rollo62 (Beitrag 1375250)

Ansonsten immer noch recht zäh, es reagiert nicht immer auf Klicks, man muss manchmal zweimal klicken

Machst Du auch schon im OnButton Click nix und führst den Code darin beim nächsten OnIdle aus oder im Thread?

[Rollo62]

Ich habe viele Units über TMessageManager entkoppekt, Entkopplung über Interfaces, viel mit Threads gearbeitet, etc.
Viel mehr Aufwand als unter Windows nötig wäre, das musste ich aber schon machen damit es überhaupt stabil läuft.
Natürlich sind da jede Menge Tricks nötig gewesen um die Sache überhaupt ans Laufen zu bekommen.

Von den Fmx Features nutze ich prinzipiell nur die einfachsten Controls (Layout, Tectangle, Label, Button), bis hin zu TListView), weil ich gar nicht erst bei komplexren Controls die Fehler bekommen möchte.
Das Dumme ist jetzt wohl das Emba beim Threading das unterste zuoberst gekehrt hat, und jetzt muss
ich vermutlich Alles nochmal komplett einzel checken wo die Probleme sind.

Mobile ist noch extrem fragil an zig Stellen, deshalb würde ich solche großen Umwälzungen bei Kernfunktionen ungerne sehen.
Aber was soll man machen, es muss halt mal was optimiert werden, dagegen will ich gar nichts sagen.
Aber wenn noch nichtmal die eigenenn Fmx-Demos mehr sauber ablaufen dann sollten Emba den Release lieber verschieben, oder zumindest eine klare Warnung oder Hinweise rausgeben.

iOS läuft auch noch nicht sauber, was aber im Wesentlichen an dem Umbau beo XCode liegt.
Dafür hätte ich mir auch schon jetzt ein Update gewünscht, damit man nicht immer mit Umschaltung der XCode-Versionen frickel muss.

Rollo

[mensch72]

ich empfehle bei BLE Sachen einen Blick in das BLEscannerDemo von Delphi... man sieht z.B. Emba das was ein True/False zurückgibt löst per Aufruf in
"TThread.CreateAnonymousThread(procedure..."

DiscoverServices in diesem Beispiel. Und man sieht auch wie man IN dem ThreadTeil auf Fehler(False Rückgabe) reagieren soll.
Witzig ist, das die Funktion des Bespiels nur exakt einmal funktioniert... ohne NeuScan klapp im org. Beispiel kein 2. Aufrauf !?

Dabei müsste man doch nur per vorherigem "UpdateOnReconnect:=True" dafür sorgen, das es wieder geht wie früher.
Da der "Fehler" ja aktuell in dem AnonymousThread nur eine nichtssagende Exeption wirft, braucht es viel Geduld sowas zu finden. Und das ist nur der erste Step.

Nach Connect sollte man sich hüten in den OnRead/OnWrite Events zu versuchen weitere WriteCharacteristic Aufrufe "direkt" zu machen... die müssen in einen "TThread.CreateAnonymousThread(procedure...", sonst gibt es nach mehr wie ca 16 Aufrufen je nach Androidversion die seltsamsten (wohl Rekursions) Efekte.
Wer schnell viel hintereinander senden will, sollte dennoch nicht im OnWrite gleich das nächste "Threaded Write" aufrufen, besser "merken" und schnell raus aus allen OnXXX Events(weil diese wohl blocked synchron zum Android-OS-BLEstack laufen und allergisch auf große Verzögerung oder gar Rekursion reagieren). OnIdle geht ja jetzt wohl wieder, ich hatte zwischendurch versuchsweise auf einen 20ms Timer umgestellt... das macht so alles keinen Spaß.

Bei unkontrollierten Verbindungsabbrüchen beenden einige Androidversionen gerade eine FMX APP hart... man kann es testen wenn man bei aktiver Verbindung einfach mal seine Gegenstelle "hart abschaltet", ober wer MicroChip BLE-Module ala RN4020/RN4871 einsetzt dort einen "Reboot" per "R,1" Kommando auslöst wenn die Verbindung noch besteht. (Rollo62 wird das kennen)

Gut ist, man kann in Tokyo viel mit Aufwand irgendwie lösen oder umgehen, aber man kann auch weiter Berlin 10.1u2 einsetzen, bzw. sich eben einen eigenen Merge aus Berlin&Tokyo RTL FMX-Sourcen basteln(den man dann aber bei so Stückwerk wie jetzt auch wieder nachführen und neu testen muss).

Trotzdem hoffe ich auf Tokyo 10.2u1 mit/für IOS11 :)

[himitsu]

Problem ist IMHO auch, dass Exceptions in Threads standardmäßig abgefangen und dann einfach fahrlässig verworfen werden, anstatt sie im laufenden Programm auszugeben.

Am Einfachsten ist es, wenn man sich eigene TThread-Ableitungen bastelt, wo nach dem Terminate Diese ausgegeben werden.
Problem, dass die meisten, welche sowas bei sich nicht einbauen auch jene sind, die scheinbar nicht wissen wofür man den Debugger nutzt, denn standardmäßig werden solche Exceptions nur da angezeigt.
Aber Codegear/Embacardero hört zu selten auf die Community, anstatt mal ein ordentliches Standardverhalten direkt ab Werk anzubieten.

[Rollo62]

Hallo Mensch72,

ja genauso mache ich das auch.
Um BLE habe ich eine Menge Threads und Queues rumgebaut damit es sauber funktioniert.
Ein paar kleinere Bugfixes inklusive in den Libraries.
Es lief bis zuletzt dann auch sehr sauber, obwohl Emba seit XE8 da nicht mehr viel dran geändert hat.
Die Demos sind meistens proof-of-concept, da scheint Niemand tiefer in die Problematik einzutauchen.
Das muss man halt selber machen.

Übrigens läuft die gleiche App unter iOS / OSX noch perfekt so wie sie soll mit Rx10.2.
Also sollte Android wieder FMX-Kompatibel gemacht werden.

Aber danke für den kleinen Hinweis das es ja nur ein "Patch" ist und
die Regel lautet "Warten bis Update 1".
Ich hoffe das in Upd1 die Fehler dann moderat beseitigt werden, und nicht noch eine neue Baustelle bei iOS aufgemacht wird.

Rollo