Delphi XE5 Android Device Compatibility

Unlike iOS, there are are a huge variety of Android devices. Delphi XE5 supports the large majority of those devices. The official page for Android Devices Supported for Application Development spells out the requirements of Gingerbread, Ice Cream Sandwich or Jelly Bean on an ARMv7 processor (with NEON instructions). The NEON instruction requirement excludes the TEGRA 2 processor which was apparently popular in some tablets (mostly) a few years back. Also excluded is the Intel Atom processor, which I hear is showing up in Android devices in Japan.

If you look at the Android Dashboard we see those versions of Android make up 87.5% of the Android devices accessing the Android store. What that doesn’t tell us is how many of those devices have ARMv7 with NEON instructions. The DocWiki page also includes a number of devices that were tested for various functions, but really in the grand scope of possible Android devices it is a rather small sample.

Android versions pie chart

So I had the idea of using Apkudo. They provide an online service where you upload your Android app APK and they run it on a wide variety of devices and tell you how it did. Currently I’ve only done a “hello world” type app test, but it gives a good guide for devices that support XE5 at a minimum level.

They have 118 devices that run Android 2.3.3 (Gingerbread) or better (no Honeycomb). Our of those devices, my APK failed to install on 10 devices. Looking at the log it either timed out, or was out of storage space, so that may be more related to the state of the device before the test than any issues with the actual app.  Out of the 108 devices that loaded and ran the app, it only failed (ANR = Application Not Responding) on 3.

  • Devices tested: 118
  • Failed to install: 10
  • Locked up: 3
  • Successfully ran: 105
  • Success rate: 89%

From what I hear it isn’t uncommon for an app to fail for no reason on some of these devices, due to other influences (like no storage space). So that rate may actually be higherI’ve shared the full spreadsheet report here for you to look for your favorite devices. (They don’t provided a download of the report, so I had to transcribe it to the spreadsheet. There may be typos.)

I plan to modify some of our existing test apps and upload them. Since the test system just uses monkey it isn’t guaranteed to actually perform the specific actions of the test apps, so I need to automate that part of the app. When I do I will update that spreadsheet and provide an updated post.

I’m sure some people will point out that you could use Java and reached more devices. Instead of focusing on the small percentage of Android devices you are missing with Delphi XE5, I’d instead invite you to consider the millions of iOS devices you can target from the same code base. Including iOS 7!

You can get started now by downloading the Delphi XE5 trial.

This entry was posted in Android, Mobile. Bookmark the permalink.

17 Responses to Delphi XE5 Android Device Compatibility

  1. Petr Nehez says:

    The new XE5 could be nice but if your current app written in Java runs on more than million devices which are not supported by XE5 then you are stuck with Java.
    You cannot just start to ignore such large user base…

  2. Eric Fleming Bonilha says:

    Petr, the devices that XE5 does not support are most likely to fade away in a couple of years, given the rate that new devices are coming and the rate that people change devices…. so I don’t see any issue and I was really expecting less devices to be compatible but this test just proved XE5 apps can run in many many devices

  3. Petr Nehez says:

    Eric, we’d like to use XE5 but as I said to cut now more than million users would be half suicide for us because our users are sport fans who are very sensitive if anything stops working. They would definitely start blaming us on google play.
    XE5 is for us just waste of money.

  4. Jolyon Smith says:

    Or put another way, Eric: Just keep driving your car toward the cliff. Someone will have built a bridge by the time you get there. 😉

    Jim McKeeth was very careful to only submit an empty app for this test which he claims is a “good guide”, but then he wants you to think that even though it is obviously anything *but* a good guide. It’s an almost meaningless guide in fact.

    If you look at Embarcadero’s own testing, as soon as you add anything even as simple as use of the device camera, FireMonkey starts running into problems on far more devices.

    And the problem devices are hardly old ones that are going to fade away. And besides, when people upgrade their old devices don’t just disappear. They get handed down, sold on – perhaps to fledgling developers looking for some cheap kit to develop and test on.

    Their high percentages even in their own tests don’t reflect a particularly high population of samples. 87% success sounds good, but is only 14 out of 16 tests. Doubling the number of tests still wouldn’t be a particularly exhaustive suite, and there is no telling the impact that would have on the % pass rate. much more likely to go down, than up I would suggest, given the seeming broad range of issues found across a range of different devices, failing even on devices from the same family of devices that the tests manage to achieve 100% on.

    i.e. these results do not indicate to me that there is just some bug in FireMonkey that needs to be fixed but something a little more fundamental. The sort of thing that might result in a fix for an issue for a Galaxy Tab2 10 breaking on a Galaxy Tab2 which was OK before.

  5. Jim McKeeth says:

    @Jolyon: It wasn’t a matter of being “very careful” to only submit an empty app. It was a matter of that will tell me which devices are compatible with XE5. I’ll add more tests as I convert them to be sure they exercise well on Apkudo.

    Anyone who has done any amount of Android development can tell you that it isn’t uncommon for the first pass of an app to work on all devices. If that were the case then services like Apkudo wouldn’t exist. We could just write code and ship it when it compiles without ever testing it on actual hardware.

    I’ve had a lot of camera apps crash on my different devices, regardless of what they are written in. If you look in the Play Store you will see where new devices and new Android versions will frequently have trouble with existing apps until they are updated. I had a camera app that rebooted one of my Android devices when I updated it to Ice Cream Sandwich. Luckily they updated that.

    This isn’t a fundamental issue with FireMonkey, it is the nature of software development, especially on mobile devices. The “It works on my machine” answer was never a valid one, and it predates mobile devices. Netflix has a huge install base and works on most of my devices, but if I flip my Nexus 7 (2013) 180 degrees while playing a movie it reboots every time.

    The compatibility tests that we’ve published are not stacked. We didn’t exclude problem devices. So statistically speaking that success ratio should scale. The tests were on the usage patterns most likely to fail. Adding a test for buttons or text input is less likely to increase the failure rate. If you come up with some usage patterns that are more likely to fail please pass them along and I would be happy to test them.

    I appreciate your obvious deep interest in XE5 and Android development. It is nice to know I can count on your willingness to help with testing and provide feedback. I look forward to more feedback from you.


  6. Jim McKeeth says:

    @Petr XE5 is ideal for when you want to reach that larger number of Android + iOS devices with one code base. You might be better off developing an XE5 app that reaches the majority of users with the majority of features, and then if you want to get 100% coverage you could create a reduced feature set version with another tool to pick up that few percent that XE5 doesn’t reach.

    I’ve actually seen a lot of apps that have two different versions: one for older OSs with less features, and one that has all the features that only works on the more recent OSs. Usually this a result of an app being forked when they had to move to non-backwards compatible APIs.

    If you really wanted to get 100% coverage on Android with any tool then you are probably going to need to either fork the app, or be very careful to avoid certain APIs.

  7. Cicero says:

    @Jim McKeet
    there is any app in Google Play to detect which devices are enabled to run XE5 Android app, or what resources are incompatibles, please?

    Sorry my poor English.

  8. Jim McKeeth says:

    @Cicero: Check out SysCheck by Christopher Moeller
    When you run it the first line tells you if you have an ARMv7, second line is Android OS version and 3rd line is if you have NEON. Those are the dependencies of Delphi XE5 on Android. The rest of the lines are extra.

  9. AlyssonRPG says:

    There’s something WRONG in the result you showed.

    The Galaxy Y passed the test (it’s on the spreadsheet), but Galaxy Y have an ARMv6 processor.. (Hello ARMv7+NEON requirement)

    You cant trust in this test.

  10. Jim McKeeth says:

    @alyssonRPG You are correct. Apkudo reported a success on the Galaxy Y, but when I read the Logcat output (which was quite long on that device) it showed that it was a failure. Interesting that it didn’t report it as such.

    In this case the failure is due to being an ARMv6, which isn’t compatible.

  11. Jolyon Smith says:

    @Jim – nope you cannot count on that at all. I simply cannot afford the prices you charge your QA staff (i.e. customers) and even if I could, I prefer tools that enable me to work directly with the platforms. Otherwise, there could be whole aspects of those platforms that I cannot take advantage of in my apps – either easily or perhaps at all – for my users.

    I look forward to seeing some tutorials on, for example, a FireMonkey app implementing an intent filter on Android. Or an Android widget.

    As far as I can tell, these things are either uncomfortably difficult (intent filters might be doable in a limited fashion via the JNI bridge) or impossible (widgets I think are entirely off-limits) without some additional support in the FireMonkey runtime.

    Unfortunately for Embarcadero, unlike iOS 7 “support”, I don’t think this is something you can address with the judicious deployment of a graphic designer. 😉

  12. Petr Nehez says:

    @Jim – “you might be better off developing an XE5 app that reaches the majority of users”… hmm, I can hear what my employer tells me if I suggest him to start developing 1 major version for iOS & Android and then 2 additional versions each for Android and iOS devices which are not supported by XE5.
    I really did not get your point.
    We target millions of sport fans and we do not do rocket science. We make the app as simple as possible that’s why there is no point to start using XE5 if we wanna target vast majority of users.

    Jim, basic requirement – can you show a demo with a widget for Android?

  13. Jim McKeeth says:

    @Petr: I don’t believe XE5 supports widgets. Maybe in a future version, but I will investigate to be sure. I’ll post on this blog when I find out more.

  14. Magno says:

    Not only in Japan, here in Brazil Motorola has released Razr I and other 2 minor variation, not sure about the last two but there are a lot of people using Atom processor here. My son has a Razr I and I cant run my app at his phone 🙁

  15. Jim McKeeth says:

    I didn’t realize Atom was gaining so much traction. I imagine it would be added soon in Delphi because they already have an x86 compiler.

  16. Bjoern Hansen says:

    Also the Samsung Galaxy Pocket has a ARMv6 processor and passed the test. I just testet it myselve an in didn’t work!

  17. jeffam70 says:

    To Jim: thanks for the blog and good job at handling the comments. I’m looking forward to updates.

    To “some” others: we’re all developers, right? That means we’re intelligent enough to take things with a “grain of salt” where needed given our experience. I was happy to read Jim’s blog about this and immediately realized the cautions to be weary of before I got to the comments; Jim didn’t try to hide it. It’s absolutely good and welcomed for you to point out weak areas to be concerned about, thank you; but berating the company and the tool that you’re never going to use anyway (because you already have the right tools for you and your audience) is a waste of time for you and others. Publicly bashing something is often just a show of a person’s innate hatred without control, and without acknowledging attributes that are valuable in different cases- the act is not beneficial to the whole. If your point is to be constructive to the people and the cause, and garner the respect that you probably deserve from experience, please find a more positive way to do it; i.e., leave out the emotion and snide remarks and stick to the undeniable facts that empower the rest of us to make wise decisions and move forward.

    Great advancement can not be made without caveats. And some advancements are not for everybody. Other’s are just not for everybody right now, but things change over time. Let’s push the efforts forward; don’t hide things, be open, don’t sugar coat or berate, be constructive.

Leave a Reply