Get the fat out from XE5 Android apps - FireMonkey Runtime for Android [Edit]

In the modern mobile OSes (like iOS and Android) the applications are run into a sandbox for more control, security and performance reasons and there are no (easy) ways to separate/use a "runtime" library (in Delphi's case RTL + FireMonkey) to be shared by multiple apps. This problem is common to all mobile x-plat runtimes/wrappers like Adobe AIR ( or Mono ( 
In Delphi's case the problem with the increasingly fat apps (statically linking RTL + FireMonkey to the application binary) comes from the non-optimized linker (GCC/LLVM LD ?) that should "collect" into the generated lib/app just the actual code used not all the unused-dummies. 
The good old Delphi linker used to be quite smart, being quite well known for generating small executables (VB-runtime killer !) ... but for some time, with the new added RTTI and Generics support the bloat was coming into Delphi's town as well.
In this context more than one year ago I created a QC proposal "Extended $RTTI for metadata inclusions & exclusions for classes and units" ( but Embarcadero doesn't seems to be interested into it ... so please vote for it if you find it useful.
Now, with the new LLVM backed Delphi next-gen compilers and LD linker there is a different story, and I hope the compiler guys (Allen Bauer & co) are already looking to the bits in this area (LLVM & ld) for "smarter" linking to trim-out the unsed fat from generated executables.
So, while optimizations in the LLVM backed nextgen linker will benefit all the FireMonkey supported platforms (Win, Mac, iOS, Android) ending up to smaller static FireMonkey apps.... I consider that an Android specific solution will dramatically decrease the application size and benefit the overall runtime FireMonkey reuse.
My *PROPOSAL/IDEA* to Embarcadero is to add support for generating an application using a shared mobile FireMonkey runtime APK similar to Adobe's AIR runtime. The Adobe AIR runtime could be found here on Google Play: and the AIR applications using it will automatically detect its presence and if not available asking for it to be downloaded. I envision that Embaracadero could do the same,  by creating a FireMonkey runtime to be made available on G
oogle Play (suggestion: that will include all the FAT from the RTL and FireMonkey Android API ... so a Delphi FireMonkey app relaying an the FireMonkey Runtime will include just the REAL code & resources ... Anyhow, while the implementation might not be a small feature ... this should be quite "natural" to Delphi that already supports dynamic runtime packages.
I created a QC Feature Request so please vote if considered useful: "Create a shareable FireMonkey Runtime for Android" 
*NOTE*: This "feature" could not be definitely used on iOS due to drastically constrained sandbox/Apple policy where you can't access non-Apple shared libs. In this case Adobe AIR use a "Captive" runtime for iOS where the AIR runtime is statically linked to the application (similar to in Delphi's FireMonkey approach)
As a reference, here are some useful links in the context of Adobe AIR Runtime for Android and iOS:
How are Adobe AIR applications packaged and deployed?
Package Adobe AIR applications for Apple iOS devices
Adobe AIR Runtime for Android ...
Adobe AIR Captive Runtime FAQ
Installation and deployment options in Adobe AIR 3
*MORE-GENERAL PROPOSAL*: Providing dynamic package support for Delphi for Android compiler/linker could greatly benefit the Delphi components providers (including Embarcadero with the above proposed FireMonkey Runtime for Android) that could create specialized Android "component packages" (similar to VCL bpls) that could  be shared into the Google Play. I see quite a *HUGE BENEFIT* for Delphi Android developers and vendors with having such support in our Delphi tool-chain for Android !
9/20/2013 7:29:04 AM
📁 embarcadero.delphi.non-tech
📃 5933 articles.

💬 1 Replies

Unfortunately,  development seems to be going quite the opposite way. The new RTTI appends a lot of information about the classes onto the executable and I have the impression that it also seems to prevent unused methods from being removed. I find the whole concept awkward to tell you the truth. For a single executable it may not matter much, but when your whole development process is based on fine granularity (complex industrial applications using and sharing lots and lots of dll's which are maintained b
y separate developers) then having such overhead inside each and every single module quickly becomes unacceptable. In a sandboxed system like IOS, it makes sense to use as much of the operating system's functionality as possible without re-inventing everything.
9/20/2013 7:18:21 AM