When it comes to Delphi, C++Builder and FireMonkey’s support for Android, there are 5 caveats.:

1. ARM Cortex-A series CPU (not Intel Atom)
2. ARMv7 Instructions
3. NEON Technology
4. GPU
5. Specific versions of Android

At one point there was some attempts made to make a list of devices that were supported either completely or partially, but new devices were coming to quick to track. This lead to the misconception that FireMonkey apps only run on a very small subset of Android devices.

Since that time there have been a number of improvements to the compiler and the FireMonkey framework. Also the landscape of Android devices continues to evolve and change. Yet I still run into people who believe that FireMonkey still only runs on a small subset of devices. I thought I would provide an update and set the record straight.

Tegra 2 and NEON

Shortly before Android support was added, the Tegra 2 processor was in use. It was ARMv7 and Cortex-A, but lacked the NEON SIMD extension. So what is NEON? NEON is a SIMD (Single Instruction Multiple Data) instruction set. When it was introduced it was an option that some ARMv7 processors included to improve performance. Since it was optional, the Tegra 2 excluded it.

It seems kind of uncertain to have some processors with some features, and others missing them, especially if you require them for your application to run. This isn’t some crazy thing that only happened with Android and ARM. Back in the time of the Intel 486 CPU (right before things went Pentium) some systems had an optional 487 math co-processor. This co-processor introduced some additional x87 instructions that accelerated some floating point operations. Some programs would be faster on a machine with x87 support, and others required it. When the Pentium came out, it incorporated the x87 instructions into most of the CPUs (there are always exceptions).

The Pentium didn’t end up being the “One CPU to rule them all” though. Along came MMX Instructions. MMX is a is a single instruction, multiple data (SIMD) instruction set that was optional for some CPUs (where have I heard that before?) Some programs were faster on an MMX enabled CPU, and others required it to run at all. After a few years, most all CPUs, even those made by AMD included MMX instructions. It didn’t end there. New CPU instruction sets are introduced all the time, but it is rare that they get the same publicity that MMX or the x87 set did.

What does all of this have to do with NEON, besides perspective? Well, Neon is now part of the ARM standard. The new ARM chips in modern Android devices include Neon. They don’t even both listing it as a feature because it is assumed. The R&D team bet on NEON and they won. Since the compiler takes advantage of Neon instructions it is faster than it would be if they hedged their bets and ignored Neon.

Enter the GPU

Much like the x87 was a separate processor that augmented the system performance, there are many other processors in your computer, specifically around audio and graphics. The big thing about the GPU is that it not only beefed up the existing graphics co-processors, but it took on the 3D and texture operations and ran them through a massively parallel architecture. The original GPU that I had was actually a separate board in addition to my graphics card. Today they are mostly integrated.

On Android they typically go with a System on a Chip (SOC) that includes the CPU, GPU and a number of the other electronics.

The Rise and Fall of Intel Atom

ARM is an open standard CPU manufactured by many different chip makers, often times under their own brand. A few manufactures include Qualcomm, Texas Instruments, Samsung and even Apple (for their mobile devices). Intel wanted a piece of the mobile processor action, but instead of just implementing ARM they introduced the Atom processor. It still used the x86 instruction set of the desktop CPUs, but was designed to be more energy efficient. They put them in Windows tablets and Android devices.

This introduced another division in the Android landscape. There were two different processor architectures. Since most Android apps were written with Java and ran in a virtual machine, it wasn’t a huge deal. Except for games. Most games use native code for performance reasons, so that required either the game to include both ARM and Atom code and libraries, or the game just wouldn’t work on Atom.

Enter libHoudini. Intel realized that mobile gaming was a big part of Android, and the fact that you couldn’t play a lot of popular games on Atom devices wasn’t good. So they created libHoudini, a proprietary ARM translation layer that translates ARM instructions into x86 instructions for the Atom processor.

libHoudini was around for a while, but around Jelly Bean or KitKat it became standard on Atom based Android devices. This resulted in ARM native apps just working on Atom devices.

Embarcadero was actually in discussions with Intel. There was talk of making an Atom targeted compiler for Android, but work was also done to improve compatibility with libHoudini. Atom was never officially supported (mostly because the market share was too small) so the Android app packager includes a check to say it didn’t work with Atom processors. But you can remove that checker and your app will probably run great on most Atom devices.

While Atom never had a huge share of the market, it looks like it is going to have even less as Intel has cancelled their next Atom processor line.

Android Versions

Unlike Apple, new version updates don’t tend to roll out as fast on Android devices. This means you typically encounter a few different versions of Android running in the wild. It isn’t all that bad though. In my opinion, Ice Cream Sandwich (API 15) was really when Android came into its own. It was Honeycomb (API 14) that finally gave tablets some serious love, and ICS merged those new features back to phones. Anything before ICS is really legacy at this point (at least in my opinion). Android tracks the popularity of Android versions on their Developer Dashboard.

Ice Cream Sandwich and older only account for a total of 4.3% of Android devices. While there are feature differences between the top 3, nothing is too revolutionary as to make the others obsolete yet.

A Thousand Flowers

Unlike iOS, where Apple is the only company to make devices that run it, Android is EVERYWHERE! I guess I’m kind of a collector of Android devices. I owned the first Android powered watch by WIMM and even created a 6 sided dice app for it. Now that Delphi supports Android I love testing it on different Android devices. Here is a list of my findings

1. Android Wear – I’ve tested 4 or 5 different Android wear devices, including the Moto 360, and they all worked flawlessly with FireMonkey.
2. Google Glass – Again, worked out of the box with FireMonkey. We even later added official support. Unfortunately Google is reimagining Glass right now, but I suspect when then new version comes out it will work great.
3. Epson Moverio BT-200  – Similar to Google Glass, but has two independent translucent lenses so it can do 3D. Runs Android Jelly Bean and works with FireMonkey right out of the box. There is a BT-300 coming soon.
4. Ouya – This was the Android gaming console that was going to change the world. It ended up under delivering, and then not evolving fast enough. It does however run FireMonkey just fine, and I know a few developers who used it for creative projects.
5. Amazon FireTV and Fire TV Stick –  Designed to work with your TV and running Amazon’s own version of Android. Again worked like a charm with FireMonkey.
6. Amazon Fire Phone – I think this is a pretty cool device, a shame it didn’t catch on. Also runs FireMonkey apps fine.
7. Amazon Kindle Tablets – I’ve not tested these, but I know people who have. Again it runs a different flavor of Android. From what I hear some people had to update their OS to get it to work with FireMonkey, but it did work.
8. BlackBerry Phone – Yeah, I went there, and so did FireMonkey. It worked too, although there are some idiosyncrasies about the OS that show up when you invoke the share sheet. I originally tested it on the BlackBerry OS, which supports Android apps, but now they’ve gone full Android.
9. Windows Phone 10 – My Windows Phone wouldn’t install the right preview of Windows 10, but Marco had better luck than I and got FireMonkey apps running on Windows 10 Phone under the Astoria bridge. Then Microsoft discontinued it. Windows Phone never had much market share, and continues to dwindle.
10. Huge collection of tablets and phones, including one with an Atom processor – they all worked (except that one old Tegra 2 tablet that ran Gingerbread).

Since Android is everywhere I’d wager that there is no Android app that actually runs on every single Android device out there, I don’t care what you wrote it with. Now if someone wants to prove me wrong, that is fine, I suspect different Android devices will be released faster than we can test them.

Conclusion

Let’s run through those requirements again and see how big of an impact they really represent.

1. ARM Cortex-A series CPU – Atom was never big, and is on its way out. Most everything else is ARM Cortex-A (or newer / compatible).
2. ARMv7 Instructions – ARMv6 is either really old, or used in a micro device like a beacon or some other IoT device. Not in any Android devices. Oh, and ARMv8 is the big thing now. It is 64-bit and runs FireMonkey apps fine.
3. NEON Technology – Like I said, it is part of the standard now, so unless you have an old Tegra 2 tablet (I still have one) then nothing to worry about.
4. GPU – All of the GPU compatibility and performance issues I know of have been fixed, and GPUs are standard on Android devices (at least ones with a screen).
5. Specific versions of Android – Only 2.3% of devices have an unsupported version of Android.

So while FireMonkey apps may not run on every single Android device in existence, most apps don’t and no app needs to. FireMonkey apps to run on the vast majority of them, and that is what matters.