The why is the main point of my question.
I know there's a filtering system using the requirements and features specified in the AndroidManifest.xml and that furthermore one can manually exclude devices.
But, is there a way to find out, which specific requirements or features lead to the exclusion?
In the Google Developer Console the devices just show up as "unsupported", but without any further information about why they are not supported. I'm sure they were rejected for a good reason. But how to find out for what reason? I would really prefer a more generic method, than comparing each requirement and feature with the manifest file.
This is just an example screen shot, and does not indicate the devices I wish to find out why they're excluded.
Any help is highly appreciated!
Thanks in advance.
There might be some methods in your app that don't meet up minimum requirements(Hardware or Software, ex. RAM,Processor, API Level or something else) with those devices.
In my case i was using some third party libraries that didn't support some devices(on API Level Basis).
There is (at least at the moment) no general method to find out, what exactly leads to an exclusion. So, one has to try and error to find it out.
Thanks go to Neal Ahluvalia for driving me in the right direction.
However, in my case the problem was that the devices did not match the android:screenDensity in <compatible-screens>. Which is really weird as I had everything from mdpi up to 640 in there, for any android:screenSize from normal to xlarge.
According to this page it looks like going from mdpi up to xxxhdpi (= 640) leaves no gap between the ranges covered by those.
But there is (at least) definitely one gap, where tvdpi comes in (which btw is considered for TV screens.. 0_o).
Somehow those devices fall under this weird tvdpi not mentioned on that page, until you scroll all the way down to a table where you can find it.
That's not yet the end of the story.. you'll have to add this tvdpi not by its name, but rather by its dpi value => android:screenDensity="213", like you also have to do for dpi values larger than xhdpi.
At this point there's a big "WTF" in my head. Thanks Google for creating the worst understandable system one can imagine of.
Related
i am suffering from last few days but i am not getting any perfect answer for that
android developer website
i
and apart from that i am also study lot of website but most of the website say's use dimen and used it for
small
normal
large
and x-large
but it is not giving me the perfect solution because most of the device which i am testing they all target normal dime such like that device start from 3.7 to 5 inch and because of that my card get moved up according to device i want the perfect appearance on each device there is a image attached to it
actually i want the perfect apperance on each device i found one method which is work fine to make a dimens xml according to the dimension of screen but it is not reliable i have to make more then 25 xml and if another device will come i have to make for these also this is image Url
If you want to support all devices then I think under my opinion You need make a check up on several points. These points are given below:
first you should make it sure that you are using right sizes in all drawable bucket. I am saying this because I think You are looking it perfect in some device but not looking good in other devices.
Do not make multiple xmls it is deprecated.
TO give margins for all devices you need to make different values folder or Dimens folder for different devices.
This is new way of supporting multiple devices , multiple xml is deprecated.
Here I am posting 2 links , this and this , check them out. I think that this is good for you to learn , just give it a try. And Up vote if this helps.
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.
TOPIC Solved: Answer below.
Some users have been reporting border alignment issues on some android components such as the alert popup or the editTexts. This is happening on the Samsung Galaxy Apollo (200x400) and the HTC Pro Touch (480x640) devices. I cannot replicate that because i don't own those devices and in the Samsung Galaxy S and emulator everything looks just right.
I think that the problem is the dpi or resolution of the device (because the edittext background is a single .9.png so image should look ok); however I am not sure if the supports-screens tag is the solution. Also, application was developed using Api 3 (v1.5) and supports-screens was not yet supported, nor the screen-size resource qualifier.
The style used for the alerts and editText is the phone default. Could the problem be something related with the theme applied to the phone by the user?
Thanks in advance!, I show some images given to me showing the problem:
It might actually be the display density causing this. If you don't provide assets in the appropriate density, the framework will try to rescale your images, including 9patches. Unfortunately there's no real perfect way of resizing 9patches and it can sometimes lead to artifacts, although I would be very surprised if it caused the type of artifact you are seeing.
I've had the same problem and the solution was changing the font size of the TextView from 16px to 17px (or any other odd number).
Well it really was the resolution/density. I managed to create an emulator with the WQVGA density (which needed > Android 1.6) and replicate the error.
The solution is seen on the Supporting Legacy Applications section of the Android Developers webpage: http://developer.android.com/guide/practices/screens_support.html. So a newer version of the API is needed in the project but it still holds support for the 1.5 version.
Thanks.
I am looking for a list of Android devices that has the following info (at least):
Device Name
User Agent String
Screen Format (of the three supported Android screen sizes)
Touch Enabled?
Maximum HTML5 Database Size
There are some lists online (like the one on Wikipedia), but it does not have all of this data.
Unfortunately, I think you'll have to compile a list of this information yourself. That list you mentioned is a great place to start. The problem is that there are so many manufacturers and so many different models, I don't know that anyone has bothered to catalog all of them with all of their particular specs in one easy-to-read place.
Finding the maximum HTML5 DB size for each device will probably be the most difficult thing. If you're looking for an upper bound on space usage, just go with the lowest you find.
If you do end up finding or compiling this list, be sure to post it here... there's a lot of Android devs who would be interested in seeing it.
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.