Android Testing - API levels to test - android

I have 2 AVDs – one for API level 19 and API level 8. If I test my app on both version, does that mean it will work with everything in between?

Yes. API levels are backward compatible which means if you write a code for
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="20" />
That means your code will run on all devices in between.

The probability is high that it will work for frameworks in between if is is working on 19 and 8 both. But there are constant changes in some methods that may change the behavior in some cases.

Related

How to use higher sdk if needed else use lower

I'm developing a android SMS App.
Currently i am using 2.2 API and it needs to stay that way.
With the new KitKat framework to send/receive sms messages i got a problem to know if to use the KitKat SMS or the lower API SMS Framework but i want to be able to use the lower sdk all the time except for times when the device is KitKat and he would use the KitKat api instead.
I saw the solution to use android.os package to check what kind of os u got but if i write in a class KitKat sms functions , wouldn't it make my app 4.4 api?
Thanks headds up
While creating your project you should target the lowest API level possible. Because if you are not using any KitKat features you should not target KitKat. Because all those people using Gingerbread (2.3–2.3.7), Honeycomb (3.0–3.2.6), Ice Cream Sandwich (4.0–4.0.4), Jelly Bean (4.1–4.3.1) will not be able to get your application even though it runs fine on their devices.
You can specify your target api in AndroidManifest.xml :
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="10"
android:maxSdkVersion="19" /> //example only
Take a look at the documentation in android website : uses-sdk
You can encounter some method that is deprecated in lower version when using lower version API that is not currently used in Upper Version
Use this structure:
if (Build.VERSION.SDK_INT == Build.VERSION_CODES.KIT_KAT)
// for kit kat devices
else
// all other devices
minSdkVersion determines the minimum Android version the app will run on. So you can set the targetSdkVersion in manifest to the API 19 to get access to Kit Kat functions and still have you app work on lower versions.
You have to target with the lowest API level. If your API level 10 will work for API level 11, 12, etc but it can't support API level 9, 8 (Lower API comparing with your current API). It support all higher versions.

define the targetSdkVersion depending on the device

I have defined in my manifest android:targetSdkVersion="15" and I would like to test with a device with API level equal to 17.
The minSdkVersion is set to 15.
<uses-sdk
android:minSdkVersion="15"
android:targetSdkVersion="15" />
I know it will work since minSdkVersion is set to a lower version than the device's one but my question is should I change the targetVersion whenever I change the device ? Isn't the targetSdkVersion supposed to be always equal to the one of the device I am testing with as it is said in the reference
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html ?
You shouldn't change the target version with every device, but with every new API level that is released.
As the webpage that you've already posted states:
As Android evolves with each new version, some behaviors and even
appearances might change. However, if the API level of the platform is
higher than the version declared by your app's targetSdkVersion, the
system may enable compatibility behaviors to ensure that your app
continues to work the way you expect.
and a few lines further:
To maintain your application along with each Android release, you
should increase the value of this attribute to match the latest API
level, then thoroughly test your application on the corresponding
platform version.
Every new API contains new features, but will also deprecate old ones; some may even get removed completely! So devices running with a higher API level might not support the same features anymore that you used in your app, which forces them to enable compatibility mode to once again be able to run the app properly.
In short, no, your targetSdkVersion should just be as high as the highest API goes. The minSdkVersion should of course be as low as possible, and you should try to avoid using maxSdkVersion, as that one will decrease the mobility of your app over time.
Even if your minSdkVersion is 1 and the targetSdkVersion is 19, new devices won't have to enable compatibility mode to run the app.

How to make android app available for both tablets and pre 11 sdk?

Update: Adding this to manifest solved it:
<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="14"/>
<supports-screens android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" android:xlargeScreens="true" android:anyDensity="true"/>
Looks like google silently stopped listing newly submitted apps in tablet market that don't meet their "optimization tips".
One of those "tips" is setting minSdkVersion="11", which means losing 40% of their whole userbase who still run sdk 10 (hilarious).
Can someone please suggest the least painful solution that would let me target both pre 11 SDK users and tablets, preferably without getting into multiple APK business.
If multiple APK is the way to go, then what is the best criteria to separate users on, so I can have a single version code at least.
(the app is fully compatible with all screen sizes and densities, currently targets minSdkVersion="8")
You are reading it wrong..
At a minimum, check the element to make sure that:
targetSdkVersion is declared with value 11 or higher (14 or higher is
recommended), OR minSdkVersion is declared with value 11 or
higher.
I put 'or' in bold to make sure you read it...It was already in upper case, but was not enough ;-)
Use targetSdkVersion to 17 and Support library as other people said.
Use the Android Support Library provided by Google. You can download it through the SDK manager. It requires a few changes to existing code (like using getSupportFragmentManager() instead of getFragmentManager(), but it works just fine.
Looks like google silently stopped listing newly submitted apps in tablet market that don't meet their "optimization tips".
I'd be interested to know of any proof you have which supports that statement.
One of those "tips" is setting minSdkVersion="11"
That is partially correct. Quoting the Target Android versions properly section which you linked to in your comment to Waza_Be ...
At a minimum, check the element to make sure that:
a. targetSdkVersion is declared with value 11 or higher (14 or higher is recommended), OR
b. minSdkVersion is declared with value 11 or higher.
c. If a maxSdkVersion attribute is declared, it must have a value of 11 or higher. Note that, in general, the use of maxSdkVersion is not recommended.
Note at the end of 'a' there is the word OR in capitals making 'b' unnecessary if 'a' is true (and we all know we can ignore 'c').
You need to use the support library which has most of the functionality (if not more) of all sdk's > 11
The support library can be used on any device 2.2 and up
Google play is a unified market place for both phones and tablets. When a device visits the Google Play, it reports api version and capabilities (hardware), so the market only shows apps matching the provided criteria. If your app is not compatible with a device it will not show up.
Up to version 2.x (api 10) the same code was used for both tablets and phones. Then version 3.x (api 11-13) was just for tablets and then version 4.x (api 14) was again unified.
So we have 2.x tablets, 3.x tablets and 4.x tablets. Use minSdkVersion to declare up to which version your app supports.

Different android:minSdkVersion and targetSdkVersion causing performance problems

I am currently developing an android app, testing it on my Nexus S. If I am running it, using minSdkVersion="7", targetSdkVersion="7" it performs well, but if I set targetSdkVersion (or both variables) to something higher than 13, the app starts to perform very bad.
After my custom views finished to draw, the GUI of the app hangs (no ANR is shown) for about 5 seconds, then it works perfectly.
Any ideas?
EDIT:
I would like to develop my app on API 16, but being downwards compatible to API level 7, so I thought of testing it on API 16 as well as API 7. But on level 16 it performs poorly.
IMO this does not make sense, because if my phone uses Android 4.1, apps targeting level 16 should perform better than once targeting 7.
What are the main differences between API 13 and 14 when drawing Views?
I am using some custom views, the SherlockActionbar and ViewPager from the support package.
Thanks
I had the same issue.
When you switch to targetSdkVersion=14, android:hardwareAccelerated will default to "true" instead of "false"
This will allow you to target 14 and not suffer from performance issues:
<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="14" />
<application android:hardwareAccelerated="false" >
if you set the targeted version higher than your min version, then you are allowed to use commands that the min version does not know. Its meant for things where you know that higher versions have better variants of code, so you would check what version the device runs on and then use code nr1 or code nr2.
You should only use different api versions if you are sure about how to handle it.

Android Tablet Zoom option missing

I've developed an android application whose GUI is designed for small screens. When run on a tablet it looks rubbish because I've assumed 320dp width to make my life easier - I don't have the resources to test on tablets.
People using android 3.2 were able to zoom into the app so it looks like it's running on a big phone. But after my last update that option is not available, and I don't understand why.
The change is related to the Manifest file. Here's what my orignal app had (there's nothing to do with screens in my Manifest):
<uses-sdk android:minSdkVersion="7" />
After updating my development environment, I got a warning saying I should specify a target sdk, so I did this:
<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="10" />
Using a painfully slow Android 3.2 emulator I have confirmed that this has caused the problem. I thought any target SDK below 11 wouldn't affect the zooming option?
Using the following also removed the zoom option:
<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="9" />
But this didn't:
<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="8" />
So setting my target SDK to 8 is a workaround, but it's also wrong because I use version 2.3.3 for testing.
Am I missing something here? Is there a better solution?
Thanks.
Try setting targetSdkVersion to 9 (or 10) and adding <supports-screens android:xlargeScreens="false" /> to your AndroidManifest.xml (docs for supports-screens). This tells the system that your application does not explicitly support xlarge screens and that it should offer the compatibility zoom/scale option for users that use the app on xlarge devices. Note that this will not cause the app to be hidden from xlarge devices on the Play Store (supports-screens only causes Play Store to filter apps from smaller screens if they are designed to run on larger screens, not the other way around).
The reason I think this is happening once you set targetSdkVersion to 9+ is because supports-screens xlargeScreens was added in API Level 9 and (I believe) defaults to true (for API Level 9+ at least). Once xlargeScreens is true the system will disable the compatibility zoom/scale mode.
Supporting docs (where it does say this but is fairly convoluted):
http://developer.android.com/guide/practices/screen-compat-mode.html
http://android-developers.blogspot.com/2011/07/new-mode-for-apps-on-large-screens.html
http://developer.android.com/guide/topics/manifest/supports-screens-element.html

Categories

Resources