Wednesday 11 September 2013

Delphi for Android (aka Delphi XE5 aka RAD Studio XE5) has appeared

Delphi Android dude

Blimey, that took me by surprise (again)! I figured it was coming fairly soon, but I didn’t realise quite that soon.

Anyway, Delphi XE5 is here (as is RAD Studio XE5 and siblings), as Tim Del Chiaro on his Delphi Insider blog.

The Trial Edition is up and available for download and those with Software Assurance should have access to the full version.

You can get a run down of what’s new in the XE5 doc wiki – specifically the What’s New page, but there’s also a general What’s New page. However the thrust of this release is all about adding Android to the portfolio of supported target platforms, with the suggestion that you can get applications compiling for both iOS and Android from a single source base.

But before getting bogged down in Android it’s worth mentioning these new features:

  • the REST client library, a new cross-platform framework for easy access of REST-based web services
  • REST debugger
  • the full integration of FireDAC
  • IDE support for MacinCloud
  • Extendible IDE mobile design devices
  • the awesome IDE Insight functionality (Ctrl+. or F6) is no longer a modal dialog but is now a search box
  • style support for the freshly released iOS 7
  • swipe to delete feature on mobile platforms
  • TListView search filtering support
  • the removal of the long defunct WebSnap and InternetExpress (with the suggestion to use IntraWeb and WebBroker instead for similar functionality)

Also there have been a bunch of iOS fixes along the way, as you’d expect.

The full Delphi range of platform targets now covers:

  • 32-bit Windows
  • 64-bit Windows
  • 32-bit OS X
  • iOS Simulator (Intel)
  • iOS (ARM)
  • Android (ARM)

This is achieved with this half dozen compilers:

  • dcc32 – Embarcadero Delphi for Win32 compiler version 26.0 – your regular Win32 Delphi, the latest version updated over many versions since Delphi 2
  • dcc64 – Embarcadero Delphi for Win64 compiler version 26.0 – the 64-bit Windows targeting compiler
  • dccosx – Embarcadero Delphi for Mac OS X compiler version 26.0 – the Delphi compiler that generates 32-bit OS X apps
  • dccios32 – Embarcadero Delphi Next Generation for iPhone Simulator compiler version 26.0 – the NextGen Delphi compiler that builds Intel executables that run in the iOS simulator
  • dcciosarm - Embarcadero Delphi Next Generation for iPhone compiler version 26.0 – the NextGen Delphi compiler that builds ARM executables that run on iOS devices
  • dccaarm – Embarcadero Delphi for Android compiler version 26.0 – the NextGen Delphi compiler that builds ARM executables that run on Android emulators and devices

Android requirements

Because the Delphi compiler generates native machine instructions, its output is processor-specific. In other words it doesn’t target the Dalvik Virtual Machine, where regular Android applications reside, which are basically Java p-code applications that are executed by a variant of the Java VM. Instead it generates raw machine code, as all the current wave of Delphi compilers do (the long gone Delphi for .NET was the exception to this general rule). So because it’ a compiler compiling native machine instructions Delphi’s Android support has the following requirements:

  • there must be a GPU
  • the CPU must be ARMv7 with NEON instruction support
  • the OS on the target device must be one of:
    • GingerBread: Android 2.3.3+ (MR1 or later), which is API level 10
    • Ice Cream Sandwich: Android 4.0.3+ (MR1 or later), which is API level 15
    • Jelly Bean: Android 4.1+ (release, MR1, MR2 or later), which are API levels 16, 17 and 18
  • you can run the app on an Android emulator if:
    • the emulator is set to use the host GPU
    • the emulator is running Ice Cream Sandwich (MR1 or later) or Jelly Bean (release or later)
    • the emulator is not running in a Virtual Machine

These requirements appear here and there in the documentation, mostly concurring with itself: 1, 2, 3. [Update: the 3rd link is new and also lists various devices that FireMonkey apps have been tested on]

[Edit: It should be noted that the Android emulator is an *emulator* – it emulates ARM instructions when set up as an ARM emulated device. This is in contrast to the iOS simulator, which simulates an iOS device by running an Intel code version of the app, where the real iOS app again will be built with ARM instructions for the iOS device ARM chip. The implication of this is that the performance is atrocious and extremely disappointing for most. As Warren Postma details in XE5 Trial Download and Install Experience, you would really be advised to get a cheap Android tablet to test on, and use the emulator as a last resort.]

[Edit: I should add that if you are going to get a cheap Android device to test your apps then you should most definitely take steps to ensure it meets the minimum specifications required by a Delphi application – it must have an ARMv7 chip that supports NEON instructions and be running an appropriate OS version. Thanks for the reminder on that, Jolyon]

How do you find out if your device is supported? Well, the OS version you can find out in the Settings. The path and menu items may vary but goes roughly like this: Settings, About phone (or tablet), Software information, Android version.

To check the CPU details you’ll need to run one of the tools from the Android SDK against your connected device. Delphi installs the Android SDK and NDK if you don’t tell it you have it pre-installed. The Android SDK gets installed into a directory something like: C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk. In the platform-tools subdirectory from there is the Android Debug Bridge, adb.exe.

To run a command against your device it needs to be connected, typically by USB. This requires you to install an appropriate USB driver for your device as the ones located by Windows typically don’t do the job. Refer to the helpful The Delphi Geek blog post on the matter, XE5 and USB Drivers, for more information and links to drivers for the more common Android phone manufacturers.

When your phone is connected you’ll need to launch a command prompt and run an adb command. This may be easiest if you change directory to the platform-tools subdirectory (or Shift+right-click on the platform-tools folder in Windows Explorer and choose Open command window here). Firstly run the command:

adb devices

just to prove that your device can be seen by the Android tool chain. Assuming it can, run:

adb -d shell cat /proc/cpuinfo

This will show you CPU information something like this:

Processor       : ARMv7 Processor rev 0 (v7l)
processor       : 0
BogoMIPS        : 13.52

processor       : 1
BogoMIPS        : 13.52

processor       : 2
BogoMIPS        : 13.52

processor       : 3
BogoMIPS        : 13.52

Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4

CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0x06f
CPU revision    : 0

Hardware        : UNKNOWN
Revision        : 0003
Serial          : 0000000000000000

Check the Processor line to ensure you are running ARMv7. In the Features line check that neon is included in the CPU feature list

Product Launch

There have been various events worldwide over recent fays and more coming in the days ahead, spreading the word about the new Android support in Delphi XE5. Today I attended the London event, which was held in a theatre in the Natural History Museum.


Embarcadero’s JT was over to help with the launch, and also on stage were Jason Vokes and Steve Ball.

I was a long way back in the audience with the zoom on my telephone’s camera on maximum. But this was the theme for the day.



If you are keen to try out Delphi’s Android support, go right ahead and start downloading and installing. However I would urge you to read up on how Android development works whilst the download/install process takes place. There are many docwiki pages that help you get a handle on how it all fits together with the main entry point here: Android Mobile Application Development. A whole bunch of subtopics are listed here.

Recent posts about Delphi’s Android support, which pre-dated today’s launch, include the following:

In a previous blog post I discussed the Objective-C Bridge, available when building iOS apps. This is part of the RTL that allows Delphi code to interact with Objective-C API code. Objective-C code is compiled native code and Delphi code is compiled native code, so the bridge allows the two sets of code to get along. You can define Delphi versions of iOS classes (rather akin to how you can declare Delphi versions of Win32 API functions in classic Delphi), create instances of Objective-C classes, inherit from Objective-C classes and generally do what is necessary to access parts of the CocoaTouch API that are not consumed and surfaced by FireMonkey or parts of the API that do not have similar behaviour exposed by FireMonkey.

Oh, I should mention it’s not so much called FireMonkey now. It seems to be getting referred to more and more as the FM Application Platform. I suspect the latter sounds a little more “business”-y.

Anyway, the Android support offers a similar API bridge called the Java Bridge. Now the Android SDK classes are Java classes living in the world of the Dalvik VM. Delphi code is machine code running on the CPU. This is different to the iOS case. So the Java Bridge uses JNI to communicate across the native/managed boundary but basically offers broadly similar behaviour. You can declare Delphi versions of Android classes, create instances of them and communicate with them. So aspects of the Android API that do not get employed by regular Delphi apps can be accessed for the most part.

One shortcoming of the Java Bridge is that you cannot inherit from a Java class, which makes certain things rather tricky. However I’m going to write up my understanding of the Java Bridge and Objective-C Bridge in additional fuller articles with various examples over coming months, and try and offer ways around the Java Bridge shortcomings. Watch this space. Well, ok, you’d do better to read up on all the Android backgrounders in docwiki while downloading and installing XE5 :o)

Here are some more Embo pages for you to chew over and apply due consideration to:

Delphi Android dude


  1. I'm afraid you've given me credit for a post I didn't write - 'XE5 News: Coming in September, With Android Support' is from Joylon Smith's blog, not mine.

  2. Oh. Oops. Apol.s.

    Allow me to pop up and correct that.

  3. Unfortunately they forget that the majority of coders do not go along with Delphi anymore as it seems to be a forgotten programming language.

    I contacted a reseller today and it does not seem that Embarcadero has an upcoming C/C++ version for RAD Studio on their wair any soon. TTht's so far so bad and would prevent a big boost on RAD Studio sales.

    1. RAD Studio XE5 already contains C++ for Win32, for Win64 and for Mac OS X. RAD Studio XE4 also did.
      iOS and Android support for C++ will be along later in the year, I gather.

  4. Unfortunately, you didn't write about prices and best/cheapest way to buy it.
    I read this post couple minutes ago:

    and expecting a clear explanation, if there's any.

    1. No, I didn't put any pricing info in. I'm hoping most customers will be on Enterprise SA, at which point they'll just download it.
      To be honest I have no idea what the price of the product is. I was, however, rather disappointed that they turned the Android support into a new release - I'd hoped they'd make it an update. But alas, not.
      But with no obvious new shiny things currently being chased after (bar the C++ support for iOS and Android) hopefully at least we'll get some solid bug-fixing time.

  5. There's plenty of cheap Android tablets out there, but the problem with this is that it means there's no real standard set in stone when it comes to hardware (compared to Apple's offerings). I've looked around, and did find one at £46 shipped (UK) which features a Cortex-A8 -- apparently is ARMV7 and does support NEON, and Mali-400. It's a basic model, nothing special, but I figured that it's good enough as a test platform (and for running my own apps as a mobile companion to the desktop/mobile data display -- I have an iOS device, but I'm not prepared to buy into a mac and a yearly dev sub, and then have to deal with all the issues surrounding setup and deployment).

    However, I had assumed that all Android tablets would be compatible provided they were running on ARM instructions. I'm not yet sure whether the tablet mentioned above will be sufficient, but on the surface it certainly appears to be (and I'll certainly post a model name and number once I receive it and test it out to confirm the situation - I do imagine a large majority of devs have one already, but for those like me who want just a test platform, this model may be ideal on both price and specs).

    1. If yours does ARMv7 and supports NEON and runs the right OS version, that should cover all the required bases. Sounds a steal at that price! Sure, it will have no bells, and I'm fairly confident it will be bereft of whistles also. But at that price, you can justify it as a replacement for the emulator for the most part.
      The emulator is still useful to test different screen sizes etc., but running on the device first to iron out the logic bugs is most important.
      I just hope you can readily get the USB driver for it.

    2. Following on from my earlier post, as promised, I can confirm that the rather cheap Digimate T-704S is indeed compatible with Firemonkey apps - cost me £46 delivered from Aria (UK). It's certainly no show stopper, but it's good enough to test on if you need an actual device (e.g. for wifi support which isn't available in the emulator). There's no readily available drivers for it unfortunately, but I've modified the stock Android Tools driver with support for it:

      In order for it to work on Windows 8, you'll need to disable driver signature enforcement ( but it could easily be 'fixed' if someone was able to sign it. Feel free to copy the android tools USB driver and replace just the .inf file as that's all that was changed. Likewise, you could modify it to work with any Android device by simply editing the hardware ID's specified in the inf file (found through Windows hardware manager).

      From there, you simply hook it up via USB and set it as your deployment target device. I've verified that FMX applications will run on it and again, while the tablet is relatively low quality, it's sufficient for testing and much easier to work with than the emulator.

    3. Nice! Thanks for coming back with details on that conveniently budget-priced device.