Does Delphi XE5 on Android work with the Android emulator? [Edit]

I find that even a hello-world app exactly like the one that David I outlines (add a button, one line of code, set button text) will not run on the Android Emulator configured
out of the box.

First, after installing the Rad Studio XE5 trial, I followed David I's steps exactly, and the emulator would not even start.  Then I clicked Android SDK manager, updated it, 
and clicked run-without-debugging.  It asked me if I wanted to start  the emulator this time so I did.

Now the Firemonkey app will not start up the emulator, and while it does appear to start debugging, the emulator screen is all black and frozen, and the FMX form (app UI) is never displayed.    


However, I also have Android studio Preview 0.2.8 on my system, and if I launch the already installed FMX application APK , while Android Studio is running I see this, over and over again:

09-12 01:47:24.316    1528-1541/com.embarcadero.HeaderFooterNavigation E/libEGL﹕ called unimplemented OpenGL ES API
09-12 01:47:24.316    1528-1541/com.embarcadero.HeaderFooterNavigation E/libEGL﹕ called unimplemented OpenGL ES API

I guess that means my firemonkey Hello World app is never going to draw on this Android-ARM emulator.

Does the Android-ARM emulator work with Firemonkey, in Delphi XE5 RTM?

Warren

Edited by: Warren Postma on Sep 11, 2013 6:53 PM
0
Warren
9/12/2013 1:55:44 AM
embarcadero.delphi.firemonkey 4901 articles. 4 followers. Follow

33 Replies
4085 Views

Similar Articles

[PageSpeed] 4

Warren Postma wrote:

> hello-world app

> HeaderFooterNavigation

The issue notwithstanding, I wouldn't call that a hello-world app. I started with a blank form and a label. Haven't
tried the emulator yet (apparently it is dog slow), however the app doesn't "respond" on my device (Samsung Galaxy
Mini), so not sure if it's the device; I'd be interested in whether others make something work on it.

-- 
Dave Nottage [TeamB]
0
Dave
9/12/2013 2:15:49 AM
If the header-footer template is broken out of the box, that's not too hopeful either.

I hope it is just down to the fact that the Arm Emulator doesn't properly provide the OpenGL/ES APIs that Firemonkey needs, and that this will be fixed at some point.

Warren
0
Warren
9/12/2013 2:20:43 AM
> {quote:title=Warren Postma wrote:}{quote}
> I find that even a hello-world app exactly like the one that David I outlines (add a button, one line of code, set button text) will not run on the Android Emulator configured
> out of the box.
> 
> First, after installing the Rad Studio XE5 trial, I followed David I's steps exactly, and the emulator would not even start.  Then I clicked Android SDK manager, updated it, 
> and clicked run-without-debugging.  It asked me if I wanted to start  the emulator this time so I did.
> 
> Now the Firemonkey app will not start up the emulator, and while it does appear to start debugging, the emulator screen is all black and frozen, and the FMX form (app UI) is never displayed.    
> 
> 
> However, I also have Android studio Preview 0.2.8 on my system, and if I launch the already installed FMX application APK , while Android Studio is running I see this, over and over again:
> 
> 09-12 01:47:24.316    1528-1541/com.embarcadero.HeaderFooterNavigation E/libEGL﹕ called unimplemented OpenGL ES API
> 09-12 01:47:24.316    1528-1541/com.embarcadero.HeaderFooterNavigation E/libEGL﹕ called unimplemented OpenGL ES API
> 
> I guess that means my firemonkey Hello World app is never going to draw on this Android-ARM emulator.
> 
> Does the Android-ARM emulator work with Firemonkey, in Delphi XE5 RTM?
> 
> Warren
> 
> Edited by: Warren Postma on Sep 11, 2013 6:53 PM

I had a similar problem, my app would launch in the emulator and then display a black screen until a message popped up prompting me to Wait or Kill the process.

2 things.

1) If you're running Delphi XE5 in a VM, or through an RDP connection, you'll receive this error every time. I'm not knowledgeable enough to tell you why that is, but it's been a consistent issue with me since beta 6. 

2) Create a new emulator through the Android Virtual Device Manager. But check 'Use Host GPU'. This solved my problem (issue number 1 still withstanding). The default emulator they ship with Delphi XE5 (rsxe5_android) doesn't seem to have this option enabled by default. 

HTH

Dusten
0
Dusten
9/12/2013 3:12:31 AM
Note sure if your running in a VM but the XE5 release notes mentions :-

The default Android emulator (rsxe5_android) will typically not display FireMonkey applications correctly when the emulator is running on a virtual machine. FireMonkey Android applications require GPU-accelerated graphics. The Android emulator is typically not able to provide these graphics capabilities when it is run within a virtual machine. For more information, see Running Your Android Application on an Android Emulator.
The rsxe5_android emulator is not defined automatically on Windows 7 Ultimate x64 VM.
If the emulator is not automatically created by the installer, you can create your own Android emulator; for instructions, see Creating an Android Emulator.
0
Brett
9/12/2013 3:59:36 AM
The emulator is by it self a VM. It might help to install the android native 
windows version http://www.android-x86.org/ in the virtual machine instead.
0
Gilbert
9/12/2013 5:47:07 AM
install android tools onto a mac
then run the emulator on that (with set to use host GPU)
runs much faster

then install either manually via the adb via a terminal window (adb install [yourapp.apk] )
or create a ssh tunnel to that running emulator

or better, have a compatible phone (needs NEON CPU Feature)
you can test for that with this app
https://play.google.com/store/apps/details?id=com.Bfield.CpuIdentifier

Edited by: Brian Hamilton on Sep 11, 2013 11:54 PM
0
Brian
9/12/2013 6:55:17 AM
> {quote:title=Gilbert Padilla wrote:}{quote}
> The emulator is by it self a VM. It might help to install the android native 
> windows version http://www.android-x86.org/ in the virtual machine instead.

problem with that is that it wont run an app compiled for ARM CPU
it will only run apps compiled for x86 cpu type (which XE5 cant do (yet))

but it does run much faster that emulator on windows thats for sure
0
Brian
9/12/2013 7:09:01 AM
I wonder when (if any) the update is planned that does not require a NEON supported device.
0
Teo
9/12/2013 8:37:23 PM
> {quote:title=Teo Super wrote:}{quote}
> I wonder when (if any) the update is planned that does not require a NEON supported device.

I dont think that is likely, too late now
its not going to be a problem going forward as people update their phones and or new phones in the last year work OK
0
Brian
9/12/2013 9:02:54 PM
> its not going to be a problem going forward as people update their phones and or new phones in the last year work OK

Would love to know the statistics on that one, how many phones have NEON and how many don't ?

The target market of android may drop dramatically with that requirement.
0
Brett
9/12/2013 10:15:54 PM
googling shows
http://news.cnet.com/8301-1035_3-57601472-94/jelly-bean-swallows-up-45-percent-of-android-devices/

i.e about half the phones out there should be compatible?
0
Brian
9/13/2013 12:05:30 AM
> {quote:title=Brian Hamilton wrote:}{quote}
> googling shows
> http://news.cnet.com/8301-1035_3-57601472-94/jelly-bean-swallows-up-45-percent-of-android-devices/
> 
> i.e about half the phones out there should be compatible?

NEON is a hardware issue, nothing to do with Android version.

My ASUS TF101 with JellyBean 4.1 will not run your app, for example.  From what I gather, the Tegra2 in that device does not support NEON.
0
Jolyon
9/13/2013 2:12:49 AM
Well, I am getting the black screen of death as well in the emulator.

Under Windows 8, the emulator ... well, the entire SDK....didn't install correctly.  I can compile just fine.  But, the emulator as stuff wouldn't start.

I pointed it to a newly installed Android SDK and NDK and now it, at least, launches the emulator.  For some reason, Android Tools simply doesn't work.

So...I then followed DavidI's instructions...to the letter.  The AVD launches when I go to run and I see the app install in the AVD.  But, when I run it...black screen.  WTH?

Has anybody figured this one out  yet?   It has to be something really stupid I am missing.

Thanks!

Charles
0
Charles
9/13/2013 2:39:38 AM
I do agree it is hard to know what % of devices support NEON
certainly the latest popular samsung devices do
it would have been ideal if it was a compiler switch...as many apps i would have thought would perform  OK without that extra floating point arithmitic...but maybe having it means Fire Monkey vector based GDI drawing would be faster?
just guessing here
0
Brian
9/13/2013 3:25:16 AM
> {quote:title=Brian Hamilton wrote:}{quote}
> > {quote:title=Teo Super wrote:}{quote}
> > I wonder when (if any) the update is planned that does not require a NEON supported device.
> 
> I dont think that is likely, too late now
> its not going to be a problem going forward as people update their phones and or new phones in the last year work OK

I wonder then how to tell a customer that he has to buy a new tablet for all his employees that are going to use my app..

Sorry, just disappointed to learn that Delphi XE 5, the lastest version of the tool I appericiate very much, and looked very very promising, takes ages to compile and forever to deploy to the emulator on which the only thing seen is a black screen.

I'm a bit annoyed when I see that XE5 won't run on the emulator that goes along with the platform that is developed for. Does not run on the emulator, not even the one installed by the tool, does not run on whatever emulator, does not run on androidx86, does not run on my Samsung phone, does run on the tablet but only if i copy it there..

And after pressing F9 it takes so much time to deploy that I forget what I was debugging..
0
Teo
9/16/2013 9:55:11 AM
> Does not run on the emulator, not even the one installed by the tool, does not run on whatever emulator, does not run on androidx86

of course it wont run on android86 emulator....its a ARM compiled program, not a x86 compiled on

and the arm version shows a black screen if run under VM
read the DOCWIKI about that

it does run on the actual mac emulator running on the mac

there are already lots of threads about this...people really need to do some digging/searching on the forum for solutions to their problems

there is also a compile switch..add to the project, view source, 
 {$D1}

just before
{$R *.res}

and that will speed up compile time....again...there is already threads about that
(also second time compile should be faster)

also the phone you try to run it on needs NEON cpu feature support
also make sure to have the driver installed, and set the phone to usb debugging mode as well
then refresh the target list

works great here XE5 with my phone..compiling  and running and debugging

Edited by: Brian Hamilton on Sep 16, 2013 5:07 AM
0
Brian
9/16/2013 12:09:22 PM
Man...you are arrogant.  Don't treat people like they are stupid.  I know it won't run under the android86 emulator.  But, I DO expect it run under the ARM emulator that ships with the Android SDK.  Even in the Webinar, they taut it running on the simulator.  yeah...show me as I can't get it work and I have working Android developer configurations on my Windows machine that run Android SDK apps just fine.

And, personally, for a product that shipped on 12 SEP, I am clearly NOT the only one who has this problem.  Nobody should have to search across all the EMBT forums to find a post among thousands that provides a solution to a problem of this magnitude.  Period.  I haven't seen a single post that clearly defines how to work around this problem in a step-by-step manner that ANYBODY can follow.

If YOU know where the instructions are to set up the SSH tunnels and run/debug on the MAC, then post the link -  It's people who behave as you that contribute to the "elitism" that is cited on such sites as the Delphi Haters Blog.  Why do you give them ammunition?  I wonder if they have already latched onto this issue....probably.

*A working solution or work-around needs to be posted on the EMBT BLOGS or as a technical article and highlighted on the EDN page when you log in.  That's how CRITICAL this problem is.*  

*If you or EMBT don't get this, it only shows ignorance and the reason why developers are opting for other tools.*



> {quote:title=Brian Hamilton wrote:}{quote}
> > Does not run on the emulator, not even the one installed by the tool, does not run on whatever emulator, does not run on androidx86
> 
> of course it wont run on android86 emulator....its a ARM compiled program, not a x86 compiled on
> 
> and the arm version shows a black screen if run under VM
> read the DOCWIKI about that
> 
> it does run on the actual mac emulator running on the mac
> 
> there are already lots of threads about this...people really need to do some digging/searching on the forum for solutions to their problems
> 
> there is also a compile switch..add to the project, view source, 
>  {$D1}
> 
> just before
> {$R *.res}
> 
> and that will speed up compile time....again...there is already threads about that
> (also second time compile should be faster)
> 
> also the phone you try to run it on needs NEON cpu feature support
> also make sure to have the driver installed, and set the phone to usb debugging mode as well
> then refresh the target list
> 
> works great here XE5 with my phone..compiling  and running and debugging
> 
> Edited by: Brian Hamilton on Sep 16, 2013 5:07 AM
0
Charles
9/16/2013 2:09:55 PM
> {quote:title=Teo Super wrote:}{quote}
> > {quote:title=Brian Hamilton wrote:}{quote}
> > > {quote:title=Teo Super wrote:}{quote}
> > > I wonder when (if any) the update is planned that does not require a NEON supported device.
> > 
> > I dont think that is likely, too late now
> > its not going to be a problem going forward as people update their phones and or new phones in the last year work OK
> 
> I wonder then how to tell a customer that he has to buy a new tablet for all his employees that are going to use my app..
> 
> Sorry, just disappointed to learn that Delphi XE 5, the lastest version of the tool I appericiate very much, and looked very very promising, takes ages to compile and forever to deploy to the emulator on which the only thing seen is a black screen.
> 
> I'm a bit annoyed when I see that XE5 won't run on the emulator that goes along with the platform that is developed for. Does not run on the emulator, not even the one installed by the tool, does not run on whatever emulator, does not run on androidx86, does not run on my Samsung phone, does run on the tablet but only if i copy it there..
> 
> And after pressing F9 it takes so much time to deploy that I forget what I was debugging..

It takes a long time to deploy primarily because of the speed that the emulator runs at. It's emulating ARM instructions on an x86 system. I too felt a little disappointed at the speed of this, but I've accepted that there's nothing to be done. It's an issue with the deployment to the virtual device (i.e. the installation), and not with the compiler itself. Delphi ARM compiler obviously compiles to the ARM instruction set. By contrast, the traditional Windows compiler compiles to the x86 or x64 instructio
n sets both of which are native to desktop CPU's and operating systems. When you have to deal with emulation, you have to basically interpret each individual instruction and map it to the equivalent instruction on the other platform.

The requirements for XE5 Android apps are as follows;
 - CPU with ARMV7 Instructions and NEON support (NEON is an ARM co-processor used for multimedia processing, similar to DirectShow and DirectDraw on Windows).
 - A GPU
 - Android 2.3.3-2.3.7 or 4.0.3+

If the device doesn't meet all 3 criteria, the application will not run. The requirements are quite fair if you ask me. Cheap Android tablets that have all 3 are plentiful, and most of them are even running Android ICS or Jelly Bean as opposed to Gingerbread). The CPU might not be great but most in these devices do support NEON, and the GPU only needs to be basic (something as simple as a Mali should suffice). Complaining about the requirements is like complaining about requiring DirectX 9 and a supportin
g GPU on Windows to run FMX applications. Sure, Windows equivalent FMX apps can run on an OS that's over a decade old (Windows XP - when DX9 was first properly introduced), but the Android Mobile/Tablet equivalent can run on hardware that almost 3 years old (Gingerbread 2.3 was announced in December 2010) - in the mobile world, that's a long time.
0
Scott
9/16/2013 3:55:55 PM
> {quote:title=Charles Stack wrote:}{quote}
> Man...you are arrogant.  Don't treat people like they are stupid.  I know it won't run under the android86 emulator.  But, I DO expect it run under the ARM emulator that ships with the Android SDK.  Even in the Webinar, they taut it running on the simulator.  yeah...show me as I can't get it work and I have working Android developer configurations on my Windows machine that run Android SDK apps just fine.
> 
> And, personally, for a product that shipped on 12 SEP, I am clearly NOT the only one who has this problem.  Nobody should have to search across all the EMBT forums to find a post among thousands that provides a solution to a problem of this magnitude.  Period.  I haven't seen a single post that clearly defines how to work around this problem in a step-by-step manner that ANYBODY can follow.
> 
> If YOU know where the instructions are to set up the SSH tunnels and run/debug on the MAC, then post the link -  It's people who behave as you that contribute to the "elitism" that is cited on such sites as the Delphi Haters Blog.  Why do you give them ammunition?  I wonder if they have already latched onto this issue....probably.
> 
> *A working solution or work-around needs to be posted on the EMBT BLOGS or as a technical article and highlighted on the EDN page when you log in.  That's how CRITICAL this problem is.*  
> 
> *If you or EMBT don't get this, it only shows ignorance and the reason why developers are opting for other tools.*

Perhaps we'd be able to help if it wasn't all just white noise we were getting. We've not be told of any error messages, what your AVD/Emulator device config is, what your application's permissions are, what components your application uses. All we've been told is "HELP! IT DOESNT WORK!". Perhaps if people weren't so happy about jumping on the "Let's blame Embarcadero" bandwagon, the community would be willing to listen. There's a lot of factors to consider that could be the cause, and without anything to
 work with, how are we supposed to help? If you want help, you have to meet us on the middleground and give us something to work with. You can't expect us to magically know what the problem is if you never provide details. You're a developer, you do nothing for your credibility AS a developer if you think the little details don't matter.

I've been in IT for over a decade, dealing with it every single day because I enjoy it. Even when things go wrong on a monumental scale, I still find a way to fix it without it costing me anything financially (most of the time at least). I've been a developer since 2005, but only since late 2010 have I actually focused on making proper software (that's still 3 years of solid developing). Because of the knowledge I've accrued over the years, I was able to fix what problems I had with my first test applicat
ions on the emulator without even investigating much. I'd always assumed other developers were as knowledgeable about IT in general. Don't try and tell me that's an unfair assumption to make - development is usually something that leads on from.

I'm a critic and a fan of Embarcadero. I criticize them for the bugs that seem to slip in with new releases and for the way certain things are designed. If I can find a bug in an IDE, then it's apparent that it's extremely obvious and shouldn't have made it through testing. I'm a critic because of the way that some 'data processing' methods in the stock units are very obscure (e.g. their JSON implementation is just so frustrating to deal with compared to something third-party like SuperObject). I'm a crit
ic because it took them until XE5 to add oAuth components. I'm a critic because there's a lot of things I wish were available, like a stock WMI component where you select a namespace and such, that just aren't (for example, if I want WMI, I have to use a third-party tool to generate some code for me or use something like MAGWMI). I'm a critic because of Apple's requirements to compile to iOS, but that's a fault of Apple and not of Emb. I'm a critic because their Livetile system doesn't work without unreas
onable changes to the system and so is not suitable for release applications - this, again, is partly down to another company (Microsoft), but I had always hoped they'd find a way to work with MS to solve the problem. I'm a critic because their documentation is often lacking on new releases - the popup window that displays help when a problem occurs with an Android app compile has no content whatsoever.

I'm a fan because they created FMX, a product that despite it's flaws, has allowed me to discover and forge my own direction in development. It's allowed me to create fantastic interfaces that simply aren't possible at stock with VCL, all without me needing to learn another language. It's the framework of my dreams. Again, it's not without it's flaws, but the benefits I get from it far outweigh the flaws. With Android support now available, this is just a bonus as now I can finally build apps for me that 
feed information from my desktop. Since I'm fairly confident in PHP and DB development, I can build an API on my web server and use that as a middle ground that's accessible both on the desktop and on mobile. Simply feeding data in via GET or POST (i.e. PHP $_GET to retrieve URL parameters), pushing it to a DB, and then parsing it out to JSON when it's requested by a device has allowed me to essentially create mobile data displays. With Android, this JSON can be parsed and displayed however I like in an F
MX UI. I'm a fan because their Android implementation is actually quite impressive when it works (which for me, is actually around 95% of the time).
0
Scott
9/16/2013 4:17:05 PM
Wow- 3 years as a "real" IT developer.  You are young.

 FYI, I've been using Delphi for 17 years....and been developing software since 1974 (starting in the 4th grade on an IBM 360).   At this point, when I plunk down $2500 on a product that claims to do something...it sure as heck better do it if they plan to keep me as a customer  I, nor others, should be responsible for having to figure out why basic functionality doesn't work (assuming that prerequisites have been installed and configured).   Last week...DBExpress didnt't work properly following install. 
 Solution??? REINSTALL for ALL USERS.  Where is that in the read-me on that?  It took someone who saw my post and took the time to offer a possible solution from THEIR experience. 

That was helpful and an easy fix. It SHOULD have been caught before it was released to the community...even if that meant a longer beta period to get it right. 

 And, if you are  someone who is trying the product for the first time and it doesn't work as advertised,  for whatever reason, what would be your reaction?  Would you whip out your credit card or look at another tool instead?  Would you bad mouth the product?  Give it your recommendation? Exactly.  That is what, precisely, loyal users have been trying to prevent.  So, yes, we point our fingers at EMBT - they need to fix the problem - out of the box - they needed / need to get this right.  They need to de
dicate the resources (personnel and finances) to get it right.  They need to release when 98%+ of reported issues are fixed and then work hard to fix the other 2% in a very short order.

The Delphi Haters blog hasn't gotten ahold of this issue yet - just you wait.  They are still railing on another issue.  I can barely tolerate or stomach what is written there (let alone, the writer can't write).  But, why are they being given material to work with?  

I will take one from your playbook - go read all the posts about how people have configured their AVDs...per the docwiki.  It seems it DOESN'T WORK for most of us.  Provided we select an existing ARM model..say..Nexus 4 or 10 and verify the enabled Use Host GPU, it is supposed to work.  Guess what?  Right. 

The reason is because FM requires a GPU.  The emulator apparently doesn't properly support it properly on a large number of developer's machines.  EMBT states that we can use the emulator for development.  Most are having a poor experience. They need to figure out why this is and provide a solution - even if it means offering a free or low cost cloud solution with AVDs that have been proven to work.

Now, it appears that we need to have a NEON capable device physically attached to develop....So, yeah...we are irked....I gave up my Android device for a shiny new iPhone 5 two months ago.  I am, at this time, screwed when it comes to Android development using XE5.

On a plus side, iOS development works, pretty much, as it should.  They GOT that feature set right.
0
Charles
9/16/2013 5:46:10 PM
You wrote
"... but I've accepted that there's nothing to be done. It's an issue with the deployment to the virtual device (i.e. the installation), and not with the compiler itself. Delphi ARM compiler obviously compiles to the ARM instruction set..."

Sorry - I cannot follow your arguments.

Since 5 days I tried to get a working Environment:
First: for me (and I believe: for most others too), a working environment is NOT "playing a little bit with a tool" and waiting over 3 minutes till app starts in avd. TIME IS MONEY !
Second: THERE IS x86-support in SDK-Manager (Intel x86 Atom System Image + HAXM), which behaves much faster. Also all libraries seems to be existing in the android sdk directory. DELPHI cannot deal with x86 android, so THIS IS NOT AN ISSUE OF INSTALLATION, it's just a lack of Delphi !
Third: I tried not only Android SDK. I also tried for example VirtualBox in combination with AndroVM - very very fast System. 
Result: app Crash. But the fact is: Other apps downloaded from Google Play store did not Crash. So please tell me: Will I have to ask the users "what kind of android do you have because our application can only run on Samsung SGS3, ...." ???
Fourth: Beside all of that I wander "oh god, what does Delphi do all the time - waiting, waiting, no high CPU usage, no disk usage (on SSD-PCI-Card), no traffic at all, but - you wait and wait over minutes till application starts in emulator...
oh no, this dosn't make fun !

And to your previous post: I googled hours and hours, but nowhere the right answers to get this fast - buying a car I will start to drive ! NOT start with a screw driver and NOT build up my car or first make a study in "how must I tune to get a Speed over 10miles/hour"
0
Adalbert
9/18/2013 5:18:14 PM
Adalbert -be my guest and feel free to write a simulator for ARM that runs on x86.  You would be doing the community a great service.

Fact is, I whined as well.  The version of the emulator that runs on Apple doesn't handle the GPU correctly.
If you have a Mac, try installing Android Tools on the Mac.  Then use Putty to tunnel ports 5554 and 5555 to the Mac.  It works. It is slow...but it works.

Now, if you have a physical Android device, use that instead.  You will get native performance and do it without having to use a Mac for emulation.

The instructions for tunneling are on the docwiki ... Just search for AVD and pick the article about running the emulator on a remote device.

Yes, time is money.  So, either get a physical device (preferred) or use a Mac (not ideal).  But, there is not reason to scream - there is a solution.  And, the problem with the emulator is not Embarcadero's.

Alas...waiting my iOS 7 to finish updating ... It's on the apple screen with progress bar!!!  Almost there!

> {quote:title=Adalbert Menhofer wrote:}{quote}
> You wrote
> "... but I've accepted that there's nothing to be done. It's an issue with the deployment to the virtual device (i.e. the installation), and not with the compiler itself. Delphi ARM compiler obviously compiles to the ARM instruction set..."
> 
> Sorry - I cannot follow your arguments.
> 
> Since 5 days I tried to get a working Environment:
> First: for me (and I believe: for most others too), a working environment is NOT "playing a little bit with a tool" and waiting over 3 minutes till app starts in avd. TIME IS MONEY !
> Second: THERE IS x86-support in SDK-Manager (Intel x86 Atom System Image + HAXM), which behaves much faster. Also all libraries seems to be existing in the android sdk directory. DELPHI cannot deal with x86 android, so THIS IS NOT AN ISSUE OF INSTALLATION, it's just a lack of Delphi !
> Third: I tried not only Android SDK. I also tried for example VirtualBox in combination with AndroVM - very very fast System. 
> Result: app Crash. But the fact is: Other apps downloaded from Google Play store did not Crash. So please tell me: Will I have to ask the users "what kind of android do you have because our application can only run on Samsung SGS3, ...." ???
> Fourth: Beside all of that I wander "oh god, what does Delphi do all the time - waiting, waiting, no high CPU usage, no disk usage (on SSD-PCI-Card), no traffic at all, but - you wait and wait over minutes till application starts in emulator...
> oh no, this dosn't make fun !
> 
> And to your previous post: I googled hours and hours, but nowhere the right answers to get this fast - buying a car I will start to drive ! NOT start with a screw driver and NOT build up my car or first make a study in "how must I tune to get a Speed over 10miles/hour"
0
Charles
9/18/2013 6:34:48 PM
in answer to what is Delphi doing...its waiting on adb (which does the code signing and then un install then install of the app to the device or emulator
(if you run that manually form a terminal window you will see if takes a while)
0
Brian
9/19/2013 3:58:29 AM
Thank you, Charles and Brian for your explanations.
No doubt, it has been a great work to realize mobile development in XE5 and of course, embarcadero developers are restricted by other products and libraries.
But to my mind, there is just a simple step missing to a really great product:

In current Version I can't compile against android on x86 Plattform. Because of that I can't start the application f.e. in AndroVM.
Delphi provides a lot of Settings in Tools->Options->SDK -> Android : which Compiler and so on will be  used in the android SDK.
You may call this stupid, but I tried to change the directories from f.e. "android-ndk-r9\toolchains\arm-linux-androideabi-4.6" to "android-ndk-r9\toolchains\x86-4.6" in the hope to get it running on "Intel x86 Atom" instead of "ARM EABI".

I'm not confirmed with android development or android SDK and I tried this without knowing how the changes will impact or how it would interact with Delphi. But I'm absolutely shure, that somehow it must be possible (with or without changes in Delphi) to get this running and it will run faster.
Then -for development process only - it would be able to use HAXM and also another Android Emulators like AndroVM which is much, much faster.

Maybe some android SDK experts will success in get delphi and android x86 running ? - please let me know.
At know I will try your recommendations to start...
but where is the mistake in my opinion, that with x86 support most performance problems could be eliminated ?
0
Adalbert
9/19/2013 9:52:26 AM
> {quote:title=Adalbert Menhofer wrote:}{quote}
> Thank you, Charles and Brian for your explanations.
> No doubt, it has been a great work to realize mobile development in XE5 and of course, embarcadero developers are restricted by other products and libraries.
> But to my mind, there is just a simple step missing to a really great product:
> 
> In current Version I can't compile against android on x86 Plattform. Because of that I can't start the application f.e. in AndroVM.
> Delphi provides a lot of Settings in Tools->Options->SDK -> Android : which Compiler and so on will be  used in the android SDK.
> You may call this stupid, but I tried to change the directories from f.e. "android-ndk-r9\toolchains\arm-linux-androideabi-4.6" to "android-ndk-r9\toolchains\x86-4.6" in the hope to get it running on "Intel x86 Atom" instead of "ARM EABI".
> 
> I'm not confirmed with android development or android SDK and I tried this without knowing how the changes will impact or how it would interact with Delphi. But I'm absolutely shure, that somehow it must be possible (with or without changes in Delphi) to get this running and it will run faster.
> Then -for development process only - it would be able to use HAXM and also another Android Emulators like AndroVM which is much, much faster.
> 
> Maybe some android SDK experts will success in get delphi and android x86 running ? - please let me know.
> At know I will try your recommendations to start...
> but where is the mistake in my opinion, that with x86 support most performance problems could be eliminated ?

You are missing one important point here: Android compiler is provided by Embarcadero and
it is not part of any Android SDK/NDK. Currently there is only ARM Android compiler in Delphi and
until Embarcadero creates x86 Android compiler no amount of tweaking will enable you to create
x86 binaries for Android nor use x86 Android emulators. 

Dalija Prasnikar
0
Dalija
9/19/2013 10:12:30 AM
Bingo.

We are stuck using the ARM emulator...X86 Emulator is not targetted by the Delphi compiler.  Perhaps, in the future....just not today.

Me?  I would rather see them generate compiled Java byte code.  But, that is not their stated direction...at least not at this time. :-)

Good luck!

Charles


> {quote:title=Dalija Prasnikar wrote:}{quote}
> > {quote:title=Adalbert Menhofer wrote:}{quote}
> > Thank you, Charles and Brian for your explanations.
> > No doubt, it has been a great work to realize mobile development in XE5 and of course, embarcadero developers are restricted by other products and libraries.
> > But to my mind, there is just a simple step missing to a really great product:
> > 
> > In current Version I can't compile against android on x86 Plattform. Because of that I can't start the application f.e. in AndroVM.
> > Delphi provides a lot of Settings in Tools->Options->SDK -> Android : which Compiler and so on will be  used in the android SDK.
> > You may call this stupid, but I tried to change the directories from f.e. "android-ndk-r9\toolchains\arm-linux-androideabi-4.6" to "android-ndk-r9\toolchains\x86-4.6" in the hope to get it running on "Intel x86 Atom" instead of "ARM EABI".
> > 
> > I'm not confirmed with android development or android SDK and I tried this without knowing how the changes will impact or how it would interact with Delphi. But I'm absolutely shure, that somehow it must be possible (with or without changes in Delphi) to get this running and it will run faster.
> > Then -for development process only - it would be able to use HAXM and also another Android Emulators like AndroVM which is much, much faster.
> > 
> > Maybe some android SDK experts will success in get delphi and android x86 running ? - please let me know.
> > At know I will try your recommendations to start...
> > but where is the mistake in my opinion, that with x86 support most performance problems could be eliminated ?
> 
> You are missing one important point here: Android compiler is provided by Embarcadero and
> it is not part of any Android SDK/NDK. Currently there is only ARM Android compiler in Delphi and
> until Embarcadero creates x86 Android compiler no amount of tweaking will enable you to create
> x86 binaries for Android nor use x86 Android emulators. 
> 
> Dalija Prasnikar
0
Charles
9/19/2013 1:54:27 PM
Sorry, but shall this be the really true answer ?
I'm not new in compiler architecture and I already built a real compiler which is the base for one of our main application 
So, the knowledge abeout the difference of a pcode compiler running against a virtual machine and a native Compiler is the basic for that.
Ok, I got absolute no knowledge about arm or android internals, but what I read is following;
The apk's are running against a dalvik VIRTUAL machine (DVM). So - a virtual machine has nothing to do with ARM or x86, but just only the runtime engine for the virtual machine must be compiled against the native processors.
And the existance of AndroVM and HAXM tells me, that the DVM runtime engine for x86 is not a Vision - it really exists.

Maybe there are some reasons that I don't know....

But then tell me, why all apps of the market store, that I testet in x86 android emulations are running without any error and without first compiling against x86, but ONLY Delphi apps are raising an exception ???

I can't find the believable explanation in Dalijas post, why supporting x86 should not be possible at all.

For the performance problem I could make tests against real android phone and also mac with ios Emulator yesterday. With both I got really much better response times (15-20s) - good enough to start development on mac and then make final test in android emulator.
Thank you very much.


> {quote:title=Charles Stack wrote:}{quote}
> Bingo.
> 
> We are stuck using the ARM emulator...X86 Emulator is not targetted by the Delphi compiler.  Perhaps, in the future....just not today.
> 
> Me?  I would rather see them generate compiled Java byte code.  But, that is not their stated direction...at least not at this time. :-)
> 
> Good luck!
> 
> Charles
> 
> 
> > {quote:title=Dalija Prasnikar wrote:}{quote}
> > > {quote:title=Adalbert Menhofer wrote:}{quote}
> > > Thank you, Charles and Brian for your explanations.
> > > No doubt, it has been a great work to realize mobile development in XE5 and of course, embarcadero developers are restricted by other products and libraries.
> > > But to my mind, there is just a simple step missing to a really great product:
> > > 
> > > In current Version I can't compile against android on x86 Plattform. Because of that I can't start the application f.e. in AndroVM.
> > > Delphi provides a lot of Settings in Tools->Options->SDK -> Android : which Compiler and so on will be  used in the android SDK.
> > > You may call this stupid, but I tried to change the directories from f.e. "android-ndk-r9\toolchains\arm-linux-androideabi-4.6" to "android-ndk-r9\toolchains\x86-4.6" in the hope to get it running on "Intel x86 Atom" instead of "ARM EABI".
> > > 
> > > I'm not confirmed with android development or android SDK and I tried this without knowing how the changes will impact or how it would interact with Delphi. But I'm absolutely shure, that somehow it must be possible (with or without changes in Delphi) to get this running and it will run faster.
> > > Then -for development process only - it would be able to use HAXM and also another Android Emulators like AndroVM which is much, much faster.
> > > 
> > > Maybe some android SDK experts will success in get delphi and android x86 running ? - please let me know.
> > > At know I will try your recommendations to start...
> > > but where is the mistake in my opinion, that with x86 support most performance problems could be eliminated ?
> > 
> > You are missing one important point here: Android compiler is provided by Embarcadero and
> > it is not part of any Android SDK/NDK. Currently there is only ARM Android compiler in Delphi and
> > until Embarcadero creates x86 Android compiler no amount of tweaking will enable you to create
> > x86 binaries for Android nor use x86 Android emulators. 
> > 
> > Dalija Prasnikar
0
Adalbert
9/22/2013 12:24:56 AM
The compile generates NATIVE ARM binaries that rely on the presence of a GPU.  Had they generated java byte code instead of native code, it would have likely run against all android devices.  Well, except for one thing..the need for a GPU to run FM.  If the emulator simulated both the ARM and GPU well, we wouldn't be having this discussion.  It does not on Windows.

If you feel up to writing a simulator that can run the ARM binaries with GPU support that runs on Windows, I will be the first inline to grab a copy.  Until then, the version on Windows sucks and still slows a dog on Mac,


> {quote:title=Adalbert Menhofer wrote:}{quote}
> Sorry, but shall this be the really true answer ?
> I'm not new in compiler architecture and I already built a real compiler which is the base for one of our main application 
> So, the knowledge abeout the difference of a pcode compiler running against a virtual machine and a native Compiler is the basic for that.
> Ok, I got absolute no knowledge about arm or android internals, but what I read is following;
> The apk's are running against a dalvik VIRTUAL machine (DVM). So - a virtual machine has nothing to do with ARM or x86, but just only the runtime engine for the virtual machine must be compiled against the native processors.
> And the existance of AndroVM and HAXM tells me, that the DVM runtime engine for x86 is not a Vision - it really exists.
> 
> Maybe there are some reasons that I don't know....
> 
> But then tell me, why all apps of the market store, that I testet in x86 android emulations are running without any error and without first compiling against x86, but ONLY Delphi apps are raising an exception ???
> 
> I can't find the believable explanation in Dalijas post, why supporting x86 should not be possible at all.
> 
> For the performance problem I could make tests against real android phone and also mac with ios Emulator yesterday. With both I got really much better response times (15-20s) - good enough to start development on mac and then make final test in android emulator.
> Thank you very much.
> 
> 
> > {quote:title=Charles Stack wrote:}{quote}
> > Bingo.
> > 
> > We are stuck using the ARM emulator...X86 Emulator is not targetted by the Delphi compiler.  Perhaps, in the future....just not today.
> > 
> > Me?  I would rather see them generate compiled Java byte code.  But, that is not their stated direction...at least not at this time. :-)
> > 
> > Good luck!
> > 
> > Charles
> > 
> > 
> > > {quote:title=Dalija Prasnikar wrote:}{quote}
> > > > {quote:title=Adalbert Menhofer wrote:}{quote}
> > > > Thank you, Charles and Brian for your explanations.
> > > > No doubt, it has been a great work to realize mobile development in XE5 and of course, embarcadero developers are restricted by other products and libraries.
> > > > But to my mind, there is just a simple step missing to a really great product:
> > > > 
> > > > In current Version I can't compile against android on x86 Plattform. Because of that I can't start the application f.e. in AndroVM.
> > > > Delphi provides a lot of Settings in Tools->Options->SDK -> Android : which Compiler and so on will be  used in the android SDK.
> > > > You may call this stupid, but I tried to change the directories from f.e. "android-ndk-r9\toolchains\arm-linux-androideabi-4.6" to "android-ndk-r9\toolchains\x86-4.6" in the hope to get it running on "Intel x86 Atom" instead of "ARM EABI".
> > > > 
> > > > I'm not confirmed with android development or android SDK and I tried this without knowing how the changes will impact or how it would interact with Delphi. But I'm absolutely shure, that somehow it must be possible (with or without changes in Delphi) to get this running and it will run faster.
> > > > Then -for development process only - it would be able to use HAXM and also another Android Emulators like AndroVM which is much, much faster.
> > > > 
> > > > Maybe some android SDK experts will success in get delphi and android x86 running ? - please let me know.
> > > > At know I will try your recommendations to start...
> > > > but where is the mistake in my opinion, that with x86 support most performance problems could be eliminated ?
> > > 
> > > You are missing one important point here: Android compiler is provided by Embarcadero and
> > > it is not part of any Android SDK/NDK. Currently there is only ARM Android compiler in Delphi and
> > > until Embarcadero creates x86 Android compiler no amount of tweaking will enable you to create
> > > x86 binaries for Android nor use x86 Android emulators. 
> > > 
> > > Dalija Prasnikar
0
Charles
9/22/2013 1:04:38 AM
Hi guys,

I had the same problem. My app would run on my device, but in the emulator I got just a black screen. The emulator itself did run the Android environment, but when I selected the app from the installed apps, same thing: black screen.

I was able to solve this by setting hw.gpu.enabled=yes in the following way:

Windows Start -> All Programs -> Embarcadero RAD Studio XE5 -> Android Tools
From the menu, select Tools -> Manage AVDs. Select the rsex5_android VM, then Edit.

Then under Hardware, click New, select "GPU Emulation", OK

This will add an entry "GPU emulation" that is default "no"; set it to "yes" and click "Edit AVD".
Then restart the Android emulator.

After this, my app worked.

Regards
Oscar
0
Oscar
9/30/2013 11:28:46 AM
> {quote:title=Brian Hamilton wrote:}{quote}
> > {quote:title=Gilbert Padilla wrote:}{quote}
> > The emulator is by it self a VM. It might help to install the android native 
> > windows version http://www.android-x86.org/ in the virtual machine instead.
> 
> problem with that is that it wont run an app compiled for ARM CPU
> it will only run apps compiled for x86 cpu type (which XE5 cant do (yet))
> 
> but it does run much faster that emulator on windows thats for sure

I did what Gilbert Padilla said, installing android for x86 CPU. I got APK generated from Delphi XE5 installed, but couldn't run, so I agree with Brian.
I used XE5 on Win7 VM (Virtualbox) running on Mac host. Would this be a problem?
0
Joko
10/10/2013 11:25:25 AM
> {quote:title=Dave Nottage wrote:}{quote}
> The issue notwithstanding, I wouldn't call that a hello-world app. I started with a blank form and a label. Haven't
> tried the emulator yet (apparently it is dog slow), however the app doesn't "respond" on my device (Samsung Galaxy
> Mini), so not sure if it's the device; I'd be interested in whether others make something work on it.
> Dave Nottage [TeamB]

I had a very disappointing experience with XE5 and Android too. I started the same way: blank form + label, copied the APK on my Galaxy S2, it's very slow to start, first with a completely black screen and finally the form show up with the label.
But when I tried with a slightly more complex application with a REST client and a ListView it hung.

Christophe
0
Christophe
10/12/2013 7:12:59 PM
Sres.
         Quería consultares, yo se que salgo de lo que Embarcadero da de ejemplo, pero, estoy utilizando el Cuarteto para grabar en el Android, donde me graba en formato chino, accedí a el SqlIte y también esta guardado ahí de esa manera, probé con el SimpleDataSet también y la misma cosa, por favor alguien sabe del por que de esto ????
         Saludos atentamente y en espera de alguna respuesta.

Messrs.
          Consultares wanted, I know what I get out of Embarcadero gives an example, but I am using the Quartet to record on the Android, which I recorded in Chinese format agreed on SQLite and there is also recorded that way, tried the SimpleDataSet also and the same thing, please someone that knows of this??
          Greetings carefully and awaiting a response.
0
Joaquin
12/19/2013 3:31:54 PM
Sres.
         Quería consultares, yo se que salgo de lo que Embarcadero da de ejemplo, pero, estoy utilizando el Cuarteto para grabar en el Android, donde me graba en formato chino, accedí a el SqlIte y también esta guardado ahí de esa manera, probé con el SimpleDataSet también y la misma cosa, por favor alguien sabe del por que de esto ????
         Saludos atentamente y en espera de alguna respuesta.

Messrs.
          Consultares wanted, I know what I get out of Embarcadero gives an example, but I am using the Quartet to record on the Android, which I recorded in Chinese format agreed on SQLite and there is also recorded that way, tried the SimpleDataSet also and the same thing, please someone that knows of this??
          Greetings carefully and awaiting a response.

Edited by: Joaquin Pardo on Dec 19, 2013 7:32 AM
0
Joaquin
12/19/2013 3:33:03 PM
Reply: