Android animation lag - android

I have a fairly simple app that requires a total of about 10 animations for various objects on the screen. The animations are fairly simple - rotate, scale etc, all described in the anim/*.xml resources.
A thing that has been puzzling me is the fact that these animations are smooth on all my test devices EXCEPT for large screen/high density screens. For example, the animations are showing terrible lag on the Galaxy Note and the Galaxy S5. I am finding it very difficult to pinpoint the cause of this issue.
On the other hand, the animations are just fine on the Samsung Galaxy 10' tablet.
Any ideas?

Related

Low framerate with near objects on Tegra device

I'm working on a small game using OpenGL ES2 on Android.
The game is running at 60FPS on many devices except one for the moment: A Wiko Highway 4G (A powerful smartphone with a Tegra 4i processor).
So, I've downloaded the "NVidia Tegra Android Development Pack" to find the bottleneck. The tools show me that my game take something like 40% on the processor, so I don't understand why the framerate was so low (20-25 FPS).
With some tests, I saw that I've got 20FPS. I've tried with a smaller scene (one box without texture or effects): same results.
Finally, after two days I've got a little idea but I don't understand how I can fix it: When objects are far, the framerate is ok, when there are near the camera, the framerate slow down. So, I think there is something with number of pixels draw on the screen (his resolution is 1920×1080).
Where the problem should come from? I've already lost three days on this problem :/
I'm using:
Android NDK R10D
OpenGL ES2
A custom engine
I've tried on the following devices: Nexus 4 (ARM), iPad 2 (PowerVR), Nexus 7 (ARM), iPhone 6 (PowerVR), Samsung Galaxy S2 (And the Wiko highway 4G, the only one with a slow framerate, and the most recent device I think)

Can't emulate large screen size

I have a publicated app in Google Play for a year now.
A bug has been spotted, some of the layouts are showing not so well in really large screens like Samsung Galaxy S5's (1080x1920)
I tried to make an emulator with this screen size but my computer just loaded and loaded (black screen on emulator) and hours later nothing really happened.
(Pc: i7, 4GB RAM)
Could anybody suggest me a way to emulate a screen size like this?
Sadly, i cannot have a real device like that.

Difficulty in replicating Screen layout issue

I have a settings tab page in my application. It works perfectly for all users, except one with HTC WildFire phone.
I have implemented all good practices suggested by Android to have multiple assets for different screen sizes and screen densities.
But still for this user, when he opens Settings tab page, the tab takes most the screen with a big box and very less space left for actual settings to appear at the bottom.
I don't have a HTC Wildfire phone. Is there a way, I can create emulator that would match exactly to HTC Wildfire screen and replicate this issue ?
Expert opinions are appreciated.
Namely that device was our worst case platform. No matter what we tried, we couldn't overcome some of its quirks. I remember weird ListView separators, borders around images - and there was something else as well.
So it may be just the device. But we also did manage to adjust a lot on an emulator with the corresponding (low) resolution. Yes, you should create one.

Framerate issue on galaxy nexus

I'm working on my first android game. It involves drawing lines, bitmaps, rectangles, and text to a canvas. On my phone (HTC G2), I get 58-60fps constantly. I had 3 Galaxy Nexus users try the app. One reported 55-60fps and the other two only saw about 30fps.
My question is: What could cause such a huge difference in framerate, especially when the Nexus is a fast phone? Toggling "Force GPU Rendering" did nothing. Also, I don't think the high resolution is to blame because the app runs at a smooth 60fps on my tablet.

What hardware devices do you test your Android apps on?

The emulator that comes with ADK for use under Eclipse is fine for testing basic Android application functionality, but:
it's not very performant
it doesn't reflect real-world hardware and software configurations
it doesn't support varying input devices such as d-pads, touch screens, trackballs or even Bluetooth/USB controllers.
Android Developer posts some very helpful rolling graphs of Platform versions, Screen sizes and densities, and OpenGL ES versions as extracted from Android Market:
http://developer.android.com/resources/dashboard/platform-versions.html
http://developer.android.com/resources/dashboard/screens.html
http://developer.android.com/resources/dashboard/opengl.html
Those really help to narrow the scope of some of the choices, but I find myself really wanting to know what the proportions of input methods various devices support are... is touch represented by 90% of the market, or only 5%? What proportion of those support multi-touch?
For example... anyone who has played the free and open source game Replica Island ( http://replicaisland.net/ ) will know that how you control the game varies between devices because it supports multiple input methods. I think Chris and Genki have done a fantastic job here, but if you use touch screens you know that the game is much more playable on 5-7 inch devices than it is on 10+ inch devices. This is because the left-right slide control doesn't maintain the same physical size as the screen size increases - meaning that you have to move too far on large touch screen devices (such as Honeycomb tablets) to be comfortable.
These are the sorts of issues you only find out when you start using various hardware devices to do your testing on. Or you can wait until users do your testing for you and start bringing your app ratings down.
So after my long introduction, here are my questions to you:
What collection of hardware devices have you bought to use in your software development and have you found those choices to have been beneficial or detrimental?
Do you instead use 3rd party testing services and just tolerate the long turnaround times between test reports (hours/days instead of instant gratification)?
For me test devices are sort of like pickup trucks: I'll make friends just to get access to their phones ;-)
Seriously, I do tap friends and family as resources. I'm a small shop and can't afford to buy a lot of test devices. Yet even with this limited pool of resources I've go the following devices available and it seems to have served me well:
Original Moto DROID (seems like such a dog now).
DROID Pro (broken screen but still good for testing).
Asus eTransformer
Samsung Galaxy Tab (7")
HTC Rezound (my personal phone--it rocks)
Samsung Charge (my wife's phone)
DROID X (son-in-law)
HTC-something I can't remember right now (daughter & son)
Amazon Kindle Fire (father).
So, as you can see, without spending a fortune I've got a pretty good set of test devices, not counting all the friends I press into service as beta-testers. With all those I really haven't had many problems with platform specific issues. I hear a lot of grumbling about fragmentation (perhaps mostly from iOS developers), but if you develop your app intelligently it isn't a huge issue.
At this stage I'm just testing with two phones:
HTC Magic (3.5" touchscreen)
Samsung Galaxy S II (4.3" touchscreen)
There's a pretty big difference in the perceived density between these phones, so it's been helpful for comparison in testing my own games. The major omission at this stage is a tablet - just haven't been able to justify the cost yet.
I'm also playing around at the moment with LCDDensity for Root which allows you to change the screen resolution on-the-fly. Interesting to see what the same sized screen would look like with more pixels stuffed in (i.e. closer to Retina display)
I have own collection of devices:
tablet with 10" screen (Motorola Xoom);
Nexus S as reference smartphone;
device with hardware keyboard (Motorola Droid);
one device from HTC (HTC Desire HD). I need it because it has slightly different UI (HTC Sense) and HTC phones are quite popular in my country. It is the least useful device in the collection;
a pair of devices with non standard screen resolutions.

Categories

Resources