Develop Reference

Android overlay window on API 26+, WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY vs TYPE_PHONE

I have an application which shows floating overlay windows and it works fine. It uses WindowManager.LayoutParams.TYPE_PHONE for the windows however and it says that it's deprecated on API level 26. Some people online said how they get errors when using TYPE_PHONE with Android 8.0 and up, but I've tested my app on phones with Android 9 and 10 and it works perfectly fine with TYPE_PHONE. Is there any benefit to changing it to TYPE_APPLICATION_OVERLAY for phones with 8.0 and up, since it works as it is? Target version is 25 currently.

As you can read in the official DOC (https://developer.android.com/reference/android/view/WindowManager.LayoutParams#TYPE_PHONE):
This constant was deprecated in API level 26.
for non-system apps. Use TYPE_APPLICATION_OVERLAY instead
It doesn't mean that that value doesn't works, but only that is DEPRECATED.
In newer Apps (targetting SDK >=26) you have to use the suggested value to be 100% compatible.
If you want to target up to 25 then you can continue to use TYPE_PHONE, but the Google Play Store doesn't more accepts Apps lower than SDK 29 ;)

Android Testing - API levels to test

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.

Android. Devices and API

I have an application that behaves differently when compiled for API 18 and 19 (behaviour of repeating alarm).
I compiled my application for API 19 (Google API). I ran it on device, and saw that the Build.VERSION.SDK_INT returned 16.
I understand that this says that 16 is the maximal API number that my device can run currently.
I just wanted to verify: In such a case, will my app run the same on such a device, regardless of whether I compiled it for API 18 or 19?

I have an application that behaves differently when compiled for API 18 and 19 (behaviour of repeating alarm).
The core behavior of AlarmManager is not dependent upon how you compile the app. It is dependent upon the OS level of the device and, more importantly, your android:targetSdkVersion.
The only difference in AlarmManager based upon how you compile the app (i.e., your build target, Project > Properties > Android in Eclipse), is whether you have direct access to additional methods (e.g., setExact()) on newer devices.
In such a case, will my app run the same on such a device, regardless of whether I compiled it for API 18 or 19?
This is impossible to answer in the abstract, even if we convert "compiled it" to "set the android:targetSdkVersion". Some behavior changes will occur on newer devices regardless of android:targetSdkVersion; some behavior changes will occur on newer devices only if your android:targetSdkVersion is set to that API level or higher.
In the particular case of AlarmManager, some of this is covered in the JavaDocs for the particular Build.VERSION_CODES value of interest, such as KITKAT:
AlarmManager.set becomes interpreted as an inexact value, to give the system more flexibility in scheduling alarms.
It is also echoed in the documentation for AlarmManager itself, such as:
Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.

Target API != your device api
For example, if you set target API to be 16, you can access all API with version <= 16
When you run on a device with newer API, it would still works as all public API should be backward compatible
But in some cases, the target API does change the app behaviour.
For example, kitkat webview has changed a lot, some old code actually have conflict with the kitkat api. But to keep backward compatibility, it would not crash with target api < kitkat. But if you set target api to be kitkat, it means you know the new api changes in kitkat, it does crash if you run those old problematic code. To keep device with old sdk working, you would need to check the sdk version of device, and run different code in different sdk.
So for your case, if you need the alarm fire exactly the time you set, here is the code:
if (Utils.isKitKatOrLater()) {
am.setExact(AlarmManager.RTC_WAKEUP, timeInMillis, pendingIntent);
} else {
am.set(AlarmManager.RTC_WAKEUP, timeInMillis, pendingIntent);
}

You should use emulators...
Set as many as you can, running devices with different OS versions.
I know they are slow, but they are an invaluable help.
Your device runs on API Level 16 because there's Jelly Bean installed (version 4.1 or version 4.1.1).
So it's backward compatible up to minSdkVersion (as defined in your Manifest).
Your targetSdkVersion should always be the latest.

What are API levels in Android?

I am starting to learn android development. I downloaded adt-bundle-windows-x86 from the android site. Now when I open the SDK manager that comes with the bundle it enlists a number of API levels. My phone has ICS. But when I saw wiki for the same it seems we can have more than one API levels for a single code name.
Which one is to be used? I want backward compatibility and also not miss on the new features that might have been introduced in ICS. what do these API levels mean and how do I decide which one to use?

Here is a link to the list of Platform Version - API Level - VERSION_CODE - Notes
This link shows data about the relative number of devices running a given version of the Android platform.
I recommend:
minimum sdk version = Android 2.3.3 - Gingerbread - Api level 10
target sdk version = Android 4.3 - JellyBean - Api level 18
NOTE the target sdk version most of the time should be the latest release which at current is JellyBean

Here you can find a list of api levels, code names and usage statistics.-
http://developer.android.com/about/dashboards/index.html
You should try making your application compatible with as much devices as possible, so I'd recommend to make sure that works fine at least on Android 2.3.3 - Gingearbread - Api level 10
Regarding new features, sadly, keeping in mind old devices sometimes means forgetting about some new cool features or apis which are included to make our lives much easier.

I think this can help you a lotclick

You should set api level as minimum as possible like 2.3.3 gingerbread. 35% of android devices still runs on Gingerbread. But as per your question it seems like you wanted to start development from 4.0.4 ICS. So set your min SDK 14. And as far as new graphical or library changes google provides support library for use.
One suggestion set max api level as high as possible. I mean 4.3 for now. hope this would help

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.