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.
Related
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.
I'm currently designing a digital menu application for Android tablets.
Here's how we are currently working: each restaurant receives a number of Android devices with our application installed (mostly 7 inches tablets) - they are low-end devices of various unknown and weird brands. They are all 4.0+, though.
We tried our best to optimize the interface based on a 7" 1024x600 testing device, using dp and sp units. Unfortunately, there are a lot of models that behave differently from this one despite the fact that they have exactly the same physical size and resolution! Actually, I did not find any device to behave the same as another... how is this possible?
Another great issue is instability. Even after exhausted testing on some models (some low-end, some high-end - such as Samsung's latest models) showing no exceptions or errors at all, we find some tablets randomly crashing with no apparent reason - same setup, same app, different tablets. Many times it is impossible to know what caused the crash, since it won't happen on a developing environment and there's no log; also, reproducing the steps that led into the crash won't result on any problem whatsoever.
My question is: are those problems sitting on the low-end tablets manufacturers' hands or is this somehow related to the way we are developing? Are those issues manageable at all?
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.
Recently myself and a small group of friends became interested in developing a game for a mobile platform. Originally we considered the iPhone but none of us use macs, so we decided Android would be a more realistic platform to use. Before we get started, I was hoping that I might find some answers to a couple questions so we don't waste our time if this project isn't feasible. Any help is appreciated!
I can't seem to find out how many programming languages Android supports. Java is obvious, but what about C+? It seems that Android supports C and C++ through Eclipse, but is that it? (I'm not the programmer for the project which is why I'm asking this. He's comfortable in C+).
Our game involves the use of two digital analog sticks (it's not a twin-stick shooter but it's a similar concept). It would seem that most Droid devices unfortunately don't use multi-touch though... Are there many devices out there right now which support this functionality and I'm just not seeing them, or should we possibly consider the development of a different game that would only use a single input?
Assuming there's no snags following those first two questions, what would you consider the best screen resolution to develop in? It seems like there are a variety of resolutions out there right now and we can't decide which is the best to use.
Again, any answers are appreciated!
You will have to use at least some Java, though you can call C++ with the newly released NDK.
To my knowledge at least the Droid and Nexus One support multitouch. Not sure about the newer ones.
I would develop for multiple screen sizes.
Chris Pruett did two very good presentations on writing real time games for android you may want to look into, they were a huge help for me.He also lightly touches on the NDK in the second one, linked below. I can only post one link since I'm a new member, but a google search for "writing real-time games for android" should turn it up.
http://bit.ly/checYY
1) Java is the language of the SDK. The majority of apps are and should be written in Java. The only reason for the NDK is for apps previously written in C++ that are to be ported to Android. There are downsides - it only supports compiling to 2 different CPUs (one is the Nexus one's CPU, can't remember what the other is). So if you do use C/C++ in the NDK, you are seriously limiting the number of devices you can ship to.
2) If you want to use dual analog sticks, why not display the sticks in the corners of the screen and allow the user to place their thumbs on them? You don't need hardware support.
3) Android SDK supports multiple screen resolutions so you don't necessarily need to worry about it immediately. I would aim for WVGA to start with (800x480 - Nexus One / HTC Desire).
Your first question has been answered by others already. The SDK is based on Dalvik, you're going to have to speak Java to the Android framework to do things like set up your activity, handle events, etc. You can call into a native code module built with the NDK for other things.
The multitouch situation on Android is dependent on hardware. Android >= 2.0 supports it in the framework, and you can use the PackageManager to query for what kind of multitouch functionality the device supports. The two you care about are FEATURE_TOUCHSCREEN_MULTITOUCH and FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT. Some screens that only offer FEATURE_TOUCHSCREEN_MULTITOUCH have problems distinguishing precise movement when both fingers are along or near the same X or Y coordinate. This is fine for things like zoom gestures, but you might have problems doing dual-analog style controls on a device without FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT.
Plan on supporting multiple resolutions. If you provide low and high resolution assets the resource system can select the appropriate ones for you automatically at runtime. More details on this here. You will still need to deal with different resolutions that do not necessarily share an aspect ratio. For example, the Droid is 480x854 while the Nexus One is 480x800.
I have a G1 and an HTC Hero handset. All the applications that I've written were tested only on these devices; come new SDK and Android handsets with (support for) different screen resolutions, densities and capabilities I have been asked to estimate the efforts required to port some of the application to new Android handsets such as Droid, Nexus One etc.
I know that making such an estimation would depend a lot on the application that is being ported, what device capabilities it uses and assumes and the way it is written.
This question is an effort to highlight all the things that a developer needs to consider(in general) when making such estimates. Please help.
Thanks.
In general, you're going to want to consider the following issues:
Resolution - different resolutions will cause your UI to look different than the original.
Input methods - not all phones have keyboards, some might be missing some other keys, etc. Think about the different possible configurations and how the user would interact with your application in each of them.
Performance - on some devices you might have performance issues that you do not see on the G1.
Device specific bugs/issues - this isn't really something you can "estimate", but it's definitely something to consider.
Of course, some of these may not be relevant for your application or the devices you intend to target, or you may decide that they aren't important enough to change.
EDIT: Another thing I forgot - if you're using native code in your application (don't remember what it was called, NDK?) it may not run on all devices.