I've developed an application which seems to work on most tablets/phones I've tested it on (S2/S3/S4/Xoom/some emulator configurations etc)
However, I've noticed a few complaints around a "Pantech Burst" - I can't seem to find any of these phones to pick one up (possibly it's specific to the US) and thought perhaps I could simulate one.
I know its 480 x 800 pixels, and has 1GB of memory
http://www.gsmarena.com/pantech_burst-4429.php
Is it possibly to simulate this kind of phone?
Or are some phones inherently different based on hardward that you could never simulate?
(I have a gut feeling it might be related to mp3's and Soundpools, but I'd rather prove it)
Short answer: no. In my experience if you have device-specific problems really the best way to debug them is to get your hands on the specific device.
Failing that, I can recommend integrating some kind of crash-reporting framework into your app, if you haven't already. These really help in capturing, tracking, and sending errors (with stacktraces) to you and have helped me fix problems on devices I can't get my hands on.
One I use is bugsense, there is also ACRA and others.
http://www.bugsense.com/
https://github.com/ACRA/acra
If you're having a problem on one particular device, then it is likely a hardware + software bug, and simply simulating the hardware configuration will not solve your problem.
That said, you can always duplicate the hardware by setting the RAM, screen size, storage etc. to its specifications. You probably won't get the same processing speed due to the fact that you're on an emulator.
If getting device is not really an option for you, you might want to consider using the Apkudo service, assuming they have the device your app is having trouble with.
You submit your app, and they run it on their set of devices using Monkey, returning to you a logcat and a stack trace when the application crashes on a particular device.
Related
This is related to question Android Emulator vs Real Device
What is the current state of art of Android emulators and what are the differences that developers should be aware of. I'm working on an app that uses bluetooth and thinking of adding a feature related to phone calling. Since I can't afford to test on all real devices so what should be the guidelines for developer to test such apps on emulators ?
Genymotion rocks. According to the blog post of Cyril Mottier it is even much better then the hardware devices.
http://www.cyrilmottier.com/2013/06/27/a-productive-android-development-environment/
I test basically everything on several real devices. The only thing I use an emulator for is making sure layouts look good on the configurations I don't have available(I don't have a 7" tablet, for instance). This is only after just about everything else is done.
Functionality is going to be nearly the same on any real device, and the emulator is no guarantee, since it doesn't seem to act like any real device in some cases(openGL, for instance).
Testing usability on a desktop with a mouse just doesn't make sense, unless you're writing something that going to be using that input method. There's a big difference between swiping with a finger and click-dragging with a mouse.
Even if you have the fastest emulator/virtualizer in the world, how can it be any faster than just picking up the phone next to you?
I am almost done with my app..when i run it on the emulator ,at certain points,
it is very slow and what i see is undesirable..when I run the same on my phone (xperia X8)
it works fine.
I really tried understanding why this is happening but of no avail!
What should I do now? run some more tests and try optimizing or just
release it in the market?
Is what I am seeing expected? Any info will be appreciated
You really should buy as many Android phones as you can. You definitely should have one with a physical keyboard, one slate phone, and one for the lowest API you are supporting. Personally, I have G1, Droid, and Nexus S that I test my apps on. Its so much faster than the emulator and easier to use. Its also a better metric of how your app works due to it being on actual hardware.
The emulator will always be slower than a real device (most likely, slower than any real device), so don't worry too much about it.
However, due to it's slowness, it can highlight areas where you may want to spend some time optimising your code that you may not necessarily find on your hardware. This is especially true on portable devices with limited CPU power, resources, and electrical power available.
It may be worth trying to find out what is causing the slowdowns in the emulator - if it's regular enough and accompanied by (for example) high CPU usage, then while a physical device may handle it better, you may find that you are unnecessarily consuming battery power and your users may not thank you for that.
The emulator is generally much slower than a physical device, so it's not a problem with your application. As long as it runs well on your phone it should be fine.
I agree with everything dbaugh said. At least at the time of this writing, the emulator is of limited use. Google has acknowledged the limitations of the current emulator and indicated they are working to revamp it. But until that happens. Stick to hardware testing.
I am wondering is it possible to do all these on an Android phone? Example, Samsung Galaxy S phone
To automatically launch a video clip upon phone start up i.e. from off position or phone ‘reboot’/’restart’
To run the video clip while the phone is idling
To launch to a particular wap site when interrupted
To restrict user from going to other portal other than the 3 steps above
To restrict user from running other application on the phone.
1) Yes but it may be hard to completely replace the phone's own screens and animation effects thus giving the smooth experience I think you're looking for. It's also pretty user-hostile.
2) What is 'idling'? If you mean standby, absolutely not. You'd kill the battery in 20 minutes in any case.
3) You can launch a website when the phone comes out of standby but it would be really annoying for the user. As for WAP .. I have no idea if you can view WAP on Android. Probably someone has made a viewer. I wasn't aware WAP was being used by anyone since some time around 2008.
4) Not without making your own custom build of Android and flashing it (very difficult technically). Sounds pretty evil for the user.
5) Again, not without making your own custom build of Android. You're reducing the phone to a brick pretty much with this stuff.
Yes, though it is user-hostile.
I have no idea what you are talking about.
I have no idea what you are talking about.
No, except by making your own firmware. Even by replacing the home screen, the user can boot into the Android equivalent of "safe mode" and bypass a replacement home screen app. You would need to have your home screen be the only one on the device, and your apps be the only one on the device.
See #4.
I will add only to question (1), since all the questions have been already answered. If you talk about replacing the standard boot and shutdown animations, then yes, it is very possible and pretty much any custom ROM for the SGS will let you do that. It's just a matter of assembling the sequence of PNG files you want. There are two image flashes before the animation, one is built-in in the bootloader, the other is hardcoded on the kernel.
Examples: http://forum.xda-developers.com/showthread.php?t=869347
You can do all these things, however you will need to flash a custom image - I assume you want to customise in-house handsets for a specific project, rather than have this as a generic app - I can't imagine normal users installing this kind of lockdown, and it sounds similar to an approach I was looking at for a project needing cheap PDAs with GSM connectivity.
If that's the case, and volumes are low, you might be better off targeting developer handsets, which can be bought through a publisher account on Android Market. I think this limits you to 10 handsets.
Hope this helps,
Phil Lello
First off, sorry if this is too subjective, I just didnt know how else/where to ask.
Anyway, in the light of all my recent questions, I'm getting ready to release an Android app soon, and most of the testing has been done on my phone, the Droid. I really dont have the money to test on "multiple" devices, nor do I know anyone with an older phone that I could ask for help that would possibly get any kind of bug. Not to mention, when I do get a bug report, how would I go about fixing it for that particular phone without having to buy it to make sure it actually gets fixed, or that the person didnt just came across a one-time freakish accident of a glitch?
How do you guys solve these kinds of issues?
You can test the vast majority of issues via the emulator:
Check out this data on platform versions and screen sizes to get an idea of what configurations you should test for.
Based on that data, I'd test at least one configuration with API versions 1.5, 1.6 and 2.1, and versions with medium and high density resolutions.
If you wanted to test physical devices, I would guess that the G1 and the Droid would be the top two... G1 would give you the lower API versions, and Droid would give you the 2.1.
Depending on your application that may be sufficient. Applications that make heavy use of OpenGL extensions might need to test further, since that is the area where there is the most difference from device to device. I don't think that the emulator is sufficient for that. See this thread on the differences.
Other than that, I would just send out a demo version of the app to a few friends or an appropriate forum. If you find problems once you launch, collecting log data from users having problems can be very helpful. I wouldn't worry too much about device specific problems though, I don't think they are that common.
Disclaimer: I'm a Motorola employee in our developer services team. I don't speak for other OEMs.
Cover the range of devices that are enumerated in the "supports-screen" manifest element. Also, take into consideration when compatibility is mode on and off. Screen sizes and market filters seem to me to be the biggest things that trip developers up. Some of this you can test with the emulator and others you need real hardware.
OEMs provide SDK "addons" that allow you to run emulator images with the skin and screen size/density of their devices. Download addons from the OEM's developer sites. Motorola's addons are available at developer.motorola.com. HTC and Samsung do the same.
A commercial alternative is Mob4Hire. They have real people on real networks who can test your app for you.
Good luck
I have few friends wich have different android devices. Before app publishing I give it to them for tests. Sometimes any users submit bugreports to market, sometimes sends it to you by email. There is impossible to have all android devices and test own app on it. This is ok.
It might be worth having a look somewhere specialist such as http://www.xda-developers.com/
They've got a sizeable community there of reasonably knowledgeable people and its not uncommon to see people posting betas of apps there for consumption and feedback. There are also dedicated subforums for each phone which may assist when attempting to resolve problems on certain handsets.
I started developing android applications. And am testing with the android emulator. Do I really need android phone before releasing it for public usage?
Short answer No. You can test and build a android application package with the SDK and an emulator. But I would say there are usually many things which it would be wise to test on a device.
Personally I have noticed that the emulator does not give a good indication of response times for UI controls. It is usually necessary to move functionality which has long processing times into background threads to maintain user interactivity without the 'force close' pop-up. Testing the effectiveness of your UI responsiveness must be done on a phone to be meaningful.
Network connectivity is another aspect which can be vastly different on a phone, 3G or wifi.
Device sizes and Android platform versions can be tested effectively on the emulator.
Some phone allow hot-swapping of the SD card (replacing the SDcard without turning off the phone). I am not sure how to replicate this on the emulator.
There may be many more things which may only become apparent when using your application on a real device. I would strongly suggest to always test under real conditions when feasible for any commercial project.
From a technical perspective there's no reason why you can't develop purely on the emulator. You're not going to be able to test on every available device, so there's always going to be possibility of device specific bugs that you've missed.
However, I'd strongly recommend getting an actual phone to test your application on.
For me the biggest difference between an actual device and the emulator is the difference between using the interface with your fingers and using a mouse. Interactions which make sense in the emulator sometimes don't work as well when you start using touch on the screen. So if you develop purely on an emulator you'll won't lots of little improvements to your UI that would obvious when you used your app on a phone.
You can't feel a real app in your hands until you have a real phone. (I'm telling you as an Android developer)
So, developing w/o real phone is possible, but real phone gives you a lot more experience, fun & usefulness.
It depends on what type of application you're developing, for serious ones you need at least one device to test it on. For complex applications you would need a range of devices, for example with or without hardware keyboard, different navigational button etc. For basic, simple applications you'll probably do fine with just the emulator.
I would imagine with games you would definitely need to test on real devices.
Thanks to you all. I am going to get HTC Legend and test it, so that I can hope that my apps can be used by others :)
You guys suggest me HTC Desire or HTC Legend?