Obviously, there will be minor differences between the emulator and hardware, but I'm running across major issues and wondering if others have found any solutions.
I have an .apk of my application, which loads and starts fine on the 2 pieces of hardware I have on hand (both OS 4.1.2). It then freezes up on a screen switch inside the application. This has happened before and it was due to that exact version of the OS having a particular bug (which should be worked around). Anyways, those details are not terribly important, that's simply how I got to thinking I'd test other versions via the emulator. However, here's what I hit:
Newer versions (5+) of the OS have an "Intel" option and my .apk crashes immediately on start on those versions.
Newer versions (5+) the Google version and 4.x generic (including the very same 4.1.2 I have on 2 hardware devices) starts my .apk fine, except that all the graphics are missing!
No difference between architectures on any given OS/class (32/64 bit, mips, arm)
What's the difference between Intel and Google versions of Android that would cause such a huge difference? Also, why does my app have graphics on hardware, but graphics vanish on the very same OS on the emulator? Are there options I need to change somewhere?
First update your SDK.
Then install emulator system image you need.
In SDK Manager you can find that Intel/ARM Android images start from 4.0.3 . Google Intel/ARM start from 4.4.2 instead .
Make sure you have hardware virtualization enabled in PC BIOS because Intel images need that and they are much faster for that.
Try to reinstall Intel HAXM . You can find setup in <Android SDK Path>/extras/intel\Hardware_Accelerated_Execution_Manager
Intel/ARM images use different CPU architecture. Instead Google/Android images have only a different software configuration. Google images include Google services like Play,Maps,ecc. Android images haven't them
It appears to be due to timeouts. Differing versions and "equipment levels" of Android devices take varying times to respond. The difference is especially large in the emulator. By bumping up all the system timeouts in the code I'm able to avoid all of the avoid weird issues.
Related
How can I find out the latest version of Chrome that I can run on KitKat Android (4.4x) please? Is it possible to grab the most recent versions APK from a newer OS install and copy to my KitKat device?
I need to determine the best way to run to run fullscreen without user intervention and there are varying supports for "fullscreen apis".
You can grab the latest version of Chrome from Google Play, but it's backwards-compatible with KitKat and it won't change a single thing you're currently seeing on KitKat.
Here is the future bleeding-edge version of Chrome, but this too won't solve your immediate testing problem.
Since you don't seem to have a Lollipop device with the right specs for what you're testing, you'll need to create a Lollipop Intel-based emulator for it and run it on your computer (an ARM-based emulator won't be sufficient, because it will be too slow).
If you need to simulate a slower cell phone internet connection with higher latency, you'll need to make that explicit when you configure your emulator, because one thing that developers forget is that their development machine usually has a very fast internet connection despite the fact that the emulator itself runs slower.
I am new to Android development and just installed the new Android sdk with Eclipse and ADT bundle. From this question, I knew about installing Intel X86 system image.But, I have one confusion about installing intel x86 for which I coudn't find any solution on internet.
In SDK manager, Intel x86 system image installation options are shown for each API level as in the picture.
image is here (since I have no privileges. Hope someone will correct it)
So, my question is that Do we need to have intel x86 system image for all API levels?
(I am making an application which will support from Android ICs to kitkat.)
Short answer: no, you don't need to. When I am actively developing an application, I'll pick a target API level and just use the emulator for that API. It's just like only having one phone to develop on - while you're working, you can only really use one at a time, anyway.
When it comes time to test, however, my advice is to run your app on as many different configurations as you can get your hands on - including different API levels. Now, one thing to keep in mind is that even though the emulator images are all official and provided by Google, they're not a replacement for testing on actual devices. Your app will have different performance characteristics in the emulator, and there are often device-specific bugs (industry term "quirks") that you won't find with the emulator (and some bugs that you'll find only on the emulator).
So, my overall answer is no, not really. Download and use whatever emulator is your target API, maybe download and also develop occasionally on the emulator for your min API, and then try as much as you can to do final testing on real devices, only falling back to emulators whenever you're unable to get a real device with a specific configuration.
If you dod't develop the Intel x86 system device, you don't need to install it.
I'm about ready to release 6 apps on the Google Play market, and a guy at work brought in a new phone that was running a version of android that the manifest file stated was supported and it didn't work as expected even though it did work on the emulator. This brought up the question of
Short of buying every device, how can we ensure that our apps will work on all devices that run the versions of android that the manifest file says it supports?
Is there a suggested way to do this? The combinations of different screen sizes, densities, and android versions can make development for android a real pain.
Edit:
The part that "didn't work as expected" was some of the javascript calls. Especially calls like window.width and window.height, the width was reported as the height and the height was reported as the width on 2.3.4, but not 2.1, or 3+. Another issue, also with 2.3.4 and javascript was the window.open(url, target) call would only call the shouldOverrideUrlLoading on my WebViewClient the first time for each target rather than every time. Again, it worked with 2.1 and 3+.
Currently, I test on devices running 2.3.4, 2.3.5, 4.0.3, and 4.0.4. I also test on emulators running 2.1, 2.2, 2.3.3, 3.0, 3.1, 3.2, and 4.1 with various screen sizes and densities. The javascript bugs are not present on the 2.3.3 or any of the other emulators, which is why I would rather test on devices, they give me a more accurate feel of what the user will run into
To start, here is a presentation that discusses how to potentially address the problem. This is obviously not easy, but here is another similar SO post.
I don't exactly what you exactly mean by "didn't work as expected" but this can help you quite a lot:
In my opinion, the best way to test your Android application is to install a Jenkins Continuous Integration Server, and use the Android Emulator plugin to execute the application on your application builds on emulators with various settings (screen density, OS version, etc.). The plugin can take automatically screenshots so you can see afterwards how your application looks on each configuration. Also, builds and testing can be trigerred daily, or each time you commit some code on your SCM (Git, SVN, you name it).
The configuration of the plugin is detailed on the official page: https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin
I have run my android app against the new build target provided by the add-on mentioned here. This appears to be working correctly in the emulator, but now I am very unsure as to the implications of using this build target when delivering an app to the marketplace.
It would appear that I have to use this build target to get the emulator to work. Is this true of the device in general? (i.e.) could I build against the standard android/google APIs and have it run correctly on the actual Galaxy Tab?
If I deploy an app with this build target to the Android market, will this adversely affect other (smaller screen) devices that I already run on? (I.e. is the galaxy tab "special sauce" a superset of Android functionality? I see grumbles about the Google APIs for maps not working in it, etc.)
Will i have to have two versions of my app in the market? One for "standard" devices and one for "large" screen devices? One for the Galaxy Tab specifically?
When Android Tablet vNext (whatever that may be) comes out and has its own custom add-on and build target, will I have to clone my repository and publish/maintain a device specific version of that (presuming that any add-on special sauce for the galaxy tab will not be in vNext's add on and will not be "compatible")
What I am driving at is that I can't find reliable documentation on how an add-on like this will affect the fragmentation of my app deployment and maintenance. I want to be able to support new Android devices like the Galaxy Tab, but I don't want to be building a bunch of one-off device-specific app implementations. Isn't the point to be able to have one app work on the gamut of devices?
Thanks in advance for any insight you might have on the situation.
It's not the case that you need to use the Samsung-provided build target to deploy your app on the Galaxy Tab (definitely not the real device, and for me the emulator works fine).
I build all my projects with a target SDK of 4 (Android 1.6) and they run fine on the Tab AVD.
One implication of the advice from Samsung that needs consideration is that they want min SDK (not the same as target SDK) set to 4, which will exclude Android 1.5 devices. You probably do not really need to do this but should test to be certain.
In general with hardware vendors (Motorola, Samsung):
- do take advantage of the AVDs, especially if you don't have the budget for the real device or it's not yet available
- do not use the custom dev environment, stick with the Google standard tools.
My two cents.
It would appear that I have to use
this build target to get the
emulator to work. Is this true of
the device in general? (i.e.) could
I build against the standard
android/google APIs and have it run
correctly on the actual Galaxy Tab?
This shouldn't be required. After all, most market apps run just fine on the galaxy tab. The only problem seems to be that the GT emulator doesn't have the Google APIs installed, though AFAIR the actual device does. But I might want to check on that as soon as I get back to office.
If I deploy an app with this build
target to the Android market, will
this adversely affect other (smaller
screen) devices that I already run
on? (I.e. is the galaxy tab "special
sauce" a superset of Android
functionality? I see grumbles about
the Google APIs for maps not working
in it, etc.)
Well, I don't think so, but you should probably use one of the regular build targets anyway. The GT plugin only helps you by specifying the API version and the devices parameters, there is no special sauce involved.
Will i have to have two versions of
my app in the market? One for
"standard" devices and one for
"large" screen devices? One for the
Galaxy Tab specifically?
No, you shouldn't need to. You actually don't have to change anything in your app to make it run decently on the GT, since Android handles most of the heavy lifting. Android won't help you provide a different layout for tablets though, since they are not officially supported yet. But by looking at screen size and density, you can still choose to do so manually.
When Android Tablet vNext (whatever
that may be) comes out and has its
own custom add-on and build target,
will I have to clone my repository
and publish/maintain a device
specific version of that (presuming
that any add-on special sauce for
the galaxy tab will not be in
vNext's add on and will not be
"compatible")
Simply put, no. In the future, tablets will most likely be supported directly by Android, and, if the current state of affairs is any indication, it will provide numerous ways to help you adopt your application for all kinds of tablet devices as well, without having to fork your code.
My boss recently gave me an HTC Wildfire phone for doing an Android version of one of our mobile apps, which is all fine and good, except that the app requires API level 8 (ie Android 2.2), and the phone itself only has Android 2.1 installed. After much googling, I discovered that this phone does support Android 2.2, and carriers will be rolling out updates over the air for this model phone "in the near future".
Since I'm not entirely certain what our lazy carrier's definition of "near future" is, it would be nice if I could download images for particular releases and install them on my phone. Coming from the world of the iPhone, it seems that this should be something rather necessary in order to successfully develop an Android app.
Yet, it doesn't seem that Google offers any Android OS updates themselves. Have I no choice but to wait for the carrier to release an update?
Edit: Thanks for the suggestions regarding the emulator, but I'm asking about testing on hardware only. I already have a working 2.2 emulator image, but I need to test on hardware now, since the emulator does a very poor job of things like video playback and audio processing.
There's a few ways you can test your application on Android 2.2:
1) You can use the Emulator provided by Google in the SDK. It is possible to create a virtual machine of any version of Android with various hardware options. However, the emulator does have some limitations such as not supporting certain hardware options (such as bluetooth) and it's also dreadfully slow to boot.
2) If you have to use an actual phone with 2.2, you can root your phone and flash a custom ROM. I'm not particularly familiar with how to root the Wildfire, or what custom ROMs are available for that specific phone, but Cyanogen Mod has pretty good ROM support for HTC phones, as well as an active forum with tutorials.
No, it's not possible to download images before OTA. You could check CyanogemMod from time to time - they're working on Wildfire support. Also you could use an emulator.
If you are wanting to bounce around with newer versions, I recommend the Nexus One as a dev phone if you can get your hands on one. Or, if you can deal with the constraints, start with a built-in AVD emulator with API 8 until your phone gets the OTA update.
The Motorola Droid is also getting/has 2.2 on it. At least in the States, in seems that most of the phones on Verizon already have it (non-scientific, just from talking to people I know). So if that phone is available, it may be a decent choice.