In my CodeRage X Product Address for the Delphi/Object Pascal track last week I covered the status of the product with Luis Navarro and highlighted the "broadening" of FireMonkey Android target platform. In particular I showed two short demos covering:
- How the current beta version of the Microsoft Astoria UWP (Universal Windows Platform) bridge can be used to execute FireMonkey applications build for Android on a beta version of the Windows 10 Phone operating system. To test this you need a compatible phone, with a beta of Windows 10, to sign up for project Astoria, configure the Android SDK with specific Microsoft add-ons, and the RAD Studio IDE will be able to target the Lumia devices directly. Not everything we have tested works, but this is still in beta.
- How the most recent Android Intel tablets can run FireMonkey applications build for ARM targets using the pre-installed libHoudini library Intel is offering. From some recent internal tests on the libHuodini that comes with Intel Android Lollipop, the compatibility is very high, and in the session Jim demonstrated running InterBase IBLite, FireDAC, and FireMonkey smoothly. It is important to notice you need to disable the Intel platform check in the deployment options, or that code will display an error message and stop the application. That check was originally added to avoid an odd crash of the application on earlier Android Intel devices.
Now the real question becomes, with these solutions working is RAD Studio going to provide also a native solution for Windows Phone and Android Intel?
In the case of Windows Phone the apps you are building in RAD Studio are binaries that can run on the phone CPU as they are, with a mapping layer for APIs only. Astoria offers extra Java APIs and an Astoria app is a UWP app that you should be able to distribute via Windows Store. While we do plan improving our support for Windows 10 Phone via Astoria once this is released, we consider this native platform support.
In the case of Android Intel, the solution works like a virtual machine, remapping assembly instructions to a different CPU, while the APIs are already compatible. This is not the ideal solution, as performance is affected, although the applications still seem quite responsive. We plan keeping this platform under scrutiny, collecting feedback on the libHoudini layer, evaluating the market share (which remains quite modest), and determining the priority for a potential Intel Android compiler and toolchain.
Getting back to the overall Product Address, including the mentioned demos, you can find it on YouTube or linked below: