my first android game it's almost done, and I'm on the way to publish it on the play store.
Today I tested it on some friends phone and it worked on all except for a samung a5. On this phone the meshes flicker, apper and disapper and look deformed. This when playing game where I use a lot of frame buffer, in the main menu where there is a simpler animation everything look right.
The game is developed with libGdx and use some custom shader. I've tested it on 8 other different device without no issue (excepect for low frame rate on samsung galaxy tab s4).
I ask yours advise:
1) what should I start to check to find the problem with a5?
2) do you think I should delay the publication until the bug it's solved ora I should publish it excluding A5 ( or maybe all devices with similar GPU) from compatibility list?
My big problem is that at the moment I don't have the device with me (it's the personal phone of a friend of mine...) and probably I will have it for only a limited amount of time, so I want to be preparated to avoid to lock the device for too much time to my friend.
Thanks to all!
First, I'd make sure you don't have any OpenGL errors - add calls to glGetError and validate frame buffers and shader programs, you can do this without the device and adding extra asserts like this is always worthwhile (assuming you don't already have them). Next, try using the tools provided by the GPU manufacturer. In your case the snapdragon profiler. To minimize the time you'll be using your friends device, get the tools installed ahead of time and if you have access to another Qualcomm device, then use that to familiarize yourself with the software. With luck the cause of problem might become immediately obvious. If not, then it's just a binary search of disabling parts of your code until you narrow it down to a particular shader/draw call, then examine/tweak that to figure out what bit is going wrong.
That's a tough call. If it's a driver bug, then it might only occur on particular revisions. Some A5 devices might work if they're on different versions of Android from your friends device. That said, the A5 is relatively recent and Samsung/Qualcomm drivers tend to be pretty solid IME, so it's more likely an error in your code that happens to only be exposed on certain devices. Personally I would delay release unless your release strategy is timing sensitive, from the limited data you have, your game doesn't work on >10% of devices.
Related
I have a problem with Unity3D. I created a game with Unity 4.6.2f1. My problem is, game crashes after splash screen(Like trying to open itself constantly). The weird part is, game works on my phones and my tablets perfectly. I have Nexus 5(With Android 5.1.1) , Iocean X7S(With Android 4.2.2) , PolyPad tablet(Android 4.2.2) , Teclast X98(Android 4.4.4). I had some beta testers which have LG G2 , Samsung S5660 , Sony Xperia Z3 , HTC M8. From these 4 phones only Samsung make it run while others failed. I first though that this is because display bits. So I unchecked 32 and 24 bits Display buffer. Same result. Then I triend to change forcing Open GL ES version. I tried to build it with "Automatic" section - I don't know if its failed or not but It started to fade to black after a time even in my devices so I guess It's not an option for fixing. Then I tried to force it to use Open GL ES 3.0 , failed again. Then I read in somewhere that my AdMob plugin might be the reason , so I removed the components of AdMob from scenes and deleted all AdMob Plugin files. Same result. Since the crashed phones are not under my control , Its really hard to detect real problem easily because I really need to beg to my friends for every test since my testers are my friends and they have their own personal life, according to them its more important than testing my game whole day. By the way , I would like to add this too , like a month ago , everything were alright. It was running normal on my friends phone(The one who has G2). I'm getting suspicious from signing the apk. Because before signing it , while I was sending it without sign , It was working. That might be wrong idea of course. I'm not an expert so Im here for your helps. I really would like to know why this is happening and I want to fix this. Thanks!
Okay , I found the solution. It turns out that one of my script was responsible for this problem. So I deleted it and rewrite another script that do the same job. I assume, script was trying to use RAM over and over , so because of that, Adreno 330 type processors try to block the App's Open GL for preventing phone from total crash. This is only assumption of course. But If you are having a problem like I had , especially in Adreno 330 processors, try to check your codes first for any overloading.
I have faced similar issues, sometimes the problem was the memory of the device, null reference etc. also you could try forcing Open GL ES 2.0
srry can't make comments
I followed the documentation (http://docs.opencv.org/doc/tutorials/introduction/android_binary_package/dev_with_OCV_on_Android.html#application-development-with-static-initialization) to initialize opencv in static initialization and it is working well so far on my phone.
However, some of my friends who helped testing my app, says the performance is very bad when they use the 'photo enhancement' feature, where I used openCV to apply some adaptive threshold filtering to sharpen the text in the images (example here: How to use OpenCV to process image so that the text become sharp and clear?). I still couldn't figure out why is that so.
Phone models that I tried it on:
1) My phone (samsung galaxy s3) - smooth (instant)
2) friend no.1 (samsung galaxy s2) - smooth (instant)
3) friend no.2 (samsung galaxy s2) - super laggy (takes few seconds for UI to regain responsiveness)
4) friend no.3 (htc one) - super laggy (takes few seconds for UI to regain responsiveness)
5) friend no.4 (samsung galaxy s4) - super laggy (takes few seconds for UI to regain responsiveness)
I recalled that my phone and friend no.1's phone installed older version of my app before, where the app was still using async initialization method (and have to install OpenCV manager from play store in order to use) and I can't think of anything different between the phones tested above..
Does anyone has similar experience? Any advice on what to look for?
There's a number of reasons why this could be happening. To make a fair evaluation you would have to restore each device to it's factory settings and execute profiling/benchmarking tools to figure out what's going on.
For instance, the phones that were found to be super laggy:
Could have too many widgets running on your homescreen, thus causing the device’s performance to slow down;
Could be using different Android versions;
Could be using Live Wallpapers (which require extra CPU cicles to run);
Generally speaking, a device could be running other background processes that are stealing CPU processing away from your app.
There is an official document for Android developers with performance tips. It's pretty interesting to read. They recommend a few tools for measure the performance of an application:
Caliper for Java microbenchmarking;
Traceview for profiling;
Systrace to analyze how the execution of your application fits into the larger Android environment, letting you see system and applications process execution on a common timeline.
There's also a nice article on vogella.com about analyzing Android performance issues. It's a must-read!
Recently, we had released an app. Before we releasing, we tested it on Samsung Nexus S, Samsung Galaxy S and Samsung Galaxy Tab.
However, recently, we realize our app cannot detect the front camera, for users who are running HTC EVO 4G Cyanogen 7
I was wondering, how do you guys start to debug on such edge cases, without purchasing new hardware?
The joys and sorrows of platform fragmentation, especially where custom firmware is concerned. The short answer? You can't test all the edge cases, and you'll certainly never catch the CM-derived defects. It's the nature of the beast. Even independent branches of the CM baseline do their own things that may entirely break something (e.g. the front camera) or get something else working (.e.g the CPU sleep). I mean, think about it: custom firmware is by definition custom. I could have -- and do! -- my own branch of CM7 that I could do anything in the world with. I could make it so that it ignores the ldpi resources altogether and always pulls hdpi, regardless of dot pitch or anything else. And, more importantly, I could completely screw it up. Unless you run my branch, you won't see that behavior.
The best you can do is program for the largest platforms (targeting API level 7 currently nets you about 99% of the overall market) and then wait for the edge cases to be reported and handle them as quickly as possible. Acquire devices that can cover the vast majority of platforms based on your spending resources. Elect beta testers to receive early builds on esoteric devices or firmware.
Then keep your fingers crossed :).
Developed a application of size 40MB. I need to test it for all screen support but the android emulator really a bad choice(I feel... ). It gives Insufficient memory error almost every time). How developer test their application?
One more Question
I have designed app for four different layout(normal,small,large and xlarge). Will every device(In future) satisfy these layout params?
And i faced a real problem that i tested my app in Sony xperia minpro(Small screen 240*320 2.4inch) and in Samsung galaxy 5(smallscreen 240*320, 2.8inch) but the layout is overlapping in samsung device. This can be a serious problem , actually we cant check our app in every device.. that is impossible too.
TIA
40MB is way too big for an Android application. Many users will have problems installing the app on their devices. You should consider moving some resources out of the application and downloading them either on demand or on first app run.
The list of layout types (normal, small, large, xlarge) is definitely not final, for there quite possibly will be even larger screens (xxlarge) or tiny ones (xsmall?).
Developed a application of size 40MB. I need to test it for all screen
support but the android emulator really a bad choice(I feel... ). It
gives Insufficient memory error almost every time). How developer test
their application?
You can configure the emulator with any amount of memory you wish, including an emulated SD card so memory shouldn't be a problem. However, 40MB is quite big so you may be hitting the package size limit.
One more Question I have designed app for four different
layout(normal,small,large and xlarge). Will every device(In future)
satisfy these layout params?
You're asking us to predict the future - there's no way we can know what Google are planning if they haven't already announced it though I would suggest that there will never be a commitment to keep screen sizes or resolutions static - technology constantly evolves and specs that are OK for today, will not be OK for tomorrow.
I have seen dictionaries weighing in at 40Mb, best practise is to download the database as a separate file. Some graphically intensive games approach that size. If you want to emulate many Android devices make sure your PC is up to snuff and you have the latest SDK.
How developer test their application?
You do not have so many choices: you have to use as many (and different) physical devices as you can, from different vendors and technical specifications (screen, etc), to try to detect as many specific bugs as possible.
This is difficult, as you are often limiten to a few physical devices.
To give you examples, I recently struggled with the Camera, for a bug happening with Motorola Defy only. I am currently struggling with the Camera, but only for Samsung Galaxy this time.
When you find a specific bug, try to fix it "the general way": instead of detecting the vendor/version of the device to write specific code for it, try to enhance your code in a way it will work for all tested phones. So far, I never had to write anything specific to a given device. The bugs I encountered were always tied to a permissivities or particular cases that could be handled by making the common code more complete or resiliant. Let's say by "making as less assumptions as possible" knowing that we tend to make assumptions without meaning it.
On top of testing on as many physical devices as possible, create emulators. You can parameter them to have different screen layouts, different embedded hardware, memory, etc. And on top of the default emulator that comes with the Android distribution, you also have emulators provided by the devices vendors and that reproduce the specificity of these devices. For example, Samsung released a Galaxy Tab emulator. Sony Ericsson released a EDK Cellphone emulator. You can get them thru the regular android distribution update workflow.
Will every device(In future) satisfy these layout params (normal,small,large and xlarge)?
Yes, as Android distributions are backward compatible. Any of these layout will still be supported in the future, but may become 'deprecated' (so not recommended, but still working), and new layout types will certainly be created.
I'm spending considerable time in making my UI to work with keyboard input only. But in the end I'm not sure whether I can rely on the assumption that Android devices all have touch screens.
Is there a way to determine if an Android device has a touch screen?
You should research the existing devices and read the Android Compatibility Definition Document (CDD) and decide for yourself.
I have spent some considerable time trying to figure out this problem for myself. The posters above are correct that Android already powers some non-touch devices and will power Google TV in the near future, but as it currently stands, the CDD specifically requires that ALL Android devices MUST have a touchscreen.
Basically, the Android Compatibility program was created to hedge against the sort of fragmentation issues you're worrying about now. It lists a bunch of requirements, and if a device does not meet those requirements, it does not get access to Android Market. These requirements include a touchscreen, wireless communication, bluetooth, a camera, and much more.
If you research those tablets and netbooks, you will find that not a single one carries the Android Market. Augen recently tried to pull a fast one with their new GENTOUCH 78 tablet, but had to rescind their claims that the tablet would carry Android Market after being shot down by the Android Compatibility Team.
So, if you are only distributing your app through Android Market, you have nothing to worry about until Google changes the CDD. But if you'd like to offer your app on other app stores or as a direct download, then you'll have to worry about your key mode navigation issues.
If it's any consolation, I have found that many, many apps have the exact same problem; they are impossible to use without a touchscreen. Many of them also have serious issues with focus and the soft keyboard. Sometimes the keyboard stays up when it should be hidden. Sometimes you can't get the keyboard to pop up no matter how many times you click on an EditText. IMO, the Android framework does not handle these things all that well.
Given all that, it will certainly be interesting to see how Google TV fits into all this. Will they update the CDD to be compatible with their set-top boxes? Will they use a different SDK and CDD for Google TV implementations? Will they ignore the Compatibility Program altogether when it comes to Google TV? Your guess is as good as mine.
Update:
It seems that someone at Google has finally come forward and admitted that Android is not ready to run on a tablet:
http://phandroid.com/2010/09/10/shocker-google-says-android-not-meant-for-tablets-in-its-current-state/
To me, this says that Google was not prepared for the accelerated adoption of the Android OS and has not adequately roadmapped the future of the platform. Supporting screens larger than 480x800 is barely possible, and Samsung was only able to do it by working closely with Google on the Galaxy Tab. So I'm not so sure we need to worry about non-touchscreen devices in the near future. They'll be here eventually, I'm sure, but when they do arrive we may see a separate app market just for those, or some altered filtering scheme on the existing market, a new CDD, who knows.
To me, this says that Google is still playing it by ear, and we'll just have to do the same.
All the phones so far have touch screens, but there is no promise that they must.
However there are lots of netbooks, notebooks, and soon to be TVs that have no touch screen.
However these devices have mice. From what I've seen, the mouse input gets pumped through the touch system so MouseDown is ACTION_DOWN, etc... (Don't know about right click though)
Are you targetting just the phones? Android is appearing on many devices including TV's I've no idea if new libs will be released to isolate parts of the devices from each other, but if you want a broader audience I'd suggest keeping the keyboard input available if you are
Google TV (GTV) is the most popular Android notouch device (as of the time this answer is composed). However, there are several devices that will call for notouch renderings if you have "notouch" resources (e.g. a directory like res/layout-notouch/ )
To accommodate notouch devices, made sure that focus will cause a visual selection indicator, and (for GTV) that keystroke listeners are in place for the directional-pad center button. Using default widgets and themes will often accomplish much of this automatically. If you make your own buttons, you need background 9-patches for focused and focused+pressed.
Running on a GTV is a good test environment to make sure that notouch works well, and GTV has an emulator now, though it runs only on Linux/x86.