So I wrote an Android app a while ago, and I'm trying to update it. I'm wanting to build in code sections where if the phone they're on is less than 3.0, do something one way, otherwise do it another way.
My build target is set to 11 in the project.properties file, but it still seems to run on Android versions < 3.0? Is this normal? Will I see some crash at some point? Everything seems to be working... My minSDKVersion is 8, but happens when I run this app with Android 3.0 code on Android 2.3.3?
It will in general run OK on platforms as far back as API level 8, since that's what you have as your minSdkVersion. It will, however, crash on earlier (pre-11) platforms if you try to call any APIs which were introduced at level 11 or later. To avoid this, you should check the OS version at runtime before calling any such methods. See Retrieving Android API version programmatically for advice on how to do this.
It is usually best to work from lower APIs up when approaching this kind of development. Each time you've finished a working version for an API, make sure it compiles without error before moving up to the next level. The manifest will warn you if you're targetSdkVersion and your minSdkVersion are different; however, this is mostly just to make sure that you are careful not to call methods from higher APIs. A useful work around might be:
private static int getApiLevel() {
return Integer.parseInt(android.os.Build.VERSION.SDK);
}
I think I was having a dumb moment.
If I set my minSDK to 8, then anything newer than 8 should work fine.
If I set my build target to 11, and then do checks before running any code that is newer than 8 on phones with SDKs older than 11, then that should cover all the bases.
I just got a little confused when I was messing with the targetSDK and the minSDK
Thanks for the comments.
Related
I am trying to use LocationManager.FUSED_PROVIDER, which according to Android Dev documentation was added in API level 31 (Android 12)
My minSdkVersion is 26 for my app
When I put down LocationManager.FUSED_PROVIDER, Android Studio does NOT complain about my minSdkVersion. Also - my test phone on Android 11 (which I presume is API level 30) runs the app (inclusive of the location functionality) without issue
Can someone please help me understand why Android 11 can run a function making use of the FUSED_PROVIDER despite that being added on in API level 31? Does this imply that phones running down to my minSdkVersion of 26 should be able to handle as well?
Edit:
I just ran the following code on an Android 9 device (spare device I flash downgraded) and the device was able to retrieve the location without error -- not sure how this is happening since Android 9 is API v28
mLocationManager.requestLocationUpdates(LocationManager.FUSED_PROVIDER, 0, 0, mLocationListener);
When I put down LocationManager.FUSED_PROVIDER, Android Studio does NOT complain about my minSdkVersion.
Maybe you need to sync or rebuild or something. It does for me (min 19):
Can someone please help me understand why Android 11 can run a function making use of the FUSED_PROVIDER despite that being added on in API level 31?
My guess would be that it works because FUSED_PROVIDER is just a String. Once you compile, the system doesn't need or care about the name of the variable, it just cares about the string value, which obviously any version of Android handle. Prior version of Android won't understand what "fused" means, but they can certainly handle the string "fused" without exploding.
This is different from a function, like addTestProvider, which was also added in 31 which will crash your old version of Android quite decidedly.
Does this imply that phones running down to my minSdkVersion of 26 should be able to handle as well?
I would think so, yes. You can test this easily with the emulator.
I've built an app that successfully runs on all sorts of Android devices. It was compiled for Android 8, but the device it's running on is Android 9.
Every time I open it on this Huawei P20 Pro, I get a crash. The only sensible error I can see is:
No implementation found for android.content.Context md5c497ac42f3138c67aed930c79af470d4.MainApplication.n_getApplicationContext() (tried Java_md5c497ac42f3138c67aed930c79af470d4_MainApplication_n_1getApplicationContext and Java_md5c497ac42f3138c67aed930c79af470d4_MainApplication_n_1getApplicationContext__)
I never call the get Application Context at any point, so I'm really not sure what is going on here.
Any helpful tips on debugging an issue like this?
If you compiled it with SDK 27 as max API (version 8) why would you run it on SDK 28, Compile with max version available 28 or 29 and then try running
In manifest make it android:targetSdkVersion="28" and compile using latest
First of all, I believe that the issue lacks enough details to make any assumptions about the possible causes. One of the possible causes is setting the target SDK version incorrectly. You can attempt to set to a correct one for the app as Ross Vernal suggested. It may can solve your problem.
Based on what I read from the official Android documents about the targetSdkVersion property, setting the version lower than the API level of a mobile device means that some additional compatibility behavior may be required when the app runs.
But this does not mean that the app cannot run on the devices with higher API levels. Whether the compatibility behavior is required depends on the app itself.
Therefore, it's possible that a feature or something else that you have decided to use in your app caused the issue on the device.
Additionally, I tested these conditions on my Huawei device that runs on Android 9 (SDK 28) with a sample Xamarin.Forms app under a target SDK of 27.
The app launched successfully. This supports the possibility mentioned above.
I've inherited a codebase for a library project written in native android that hasn't been updated in a while, where the targetSdkVersion for the project is 27. In testing apps integrating the library that are on api 28, we haven't run into any specific issues. I want to update the targetSdkVersion 29 given that Android Q is about ready to be released out of beta, but I'm wondering if I can increment the targetSdkVersion from 27 directly to 29 without having missed any potential version bugs in 28, or if I have to increment to 28, test and then increment to 29?
There are 2 types of errors that can occur while upgrading:
1. Google removed a method or class, that you have used.
In this case you won't be able to compile your project without an lint/gradle error message. So, you will notice these kind of changes.
2. Google changed some class behaviours or introduced new access patterns
These are harder to spot, since you will probably only find out about it, when you use it. An example is the cleartext support in Android 9 (Cleartext). Your app will crash, if you target Android 9 and forget to add the necessary line in your manifest, but it will run perfectly on pre Android 9.
In the end, there are no tools for detecting this (at least I dont know them). The best would be to create a working testing procedure (multiple testing devices and user) and to scan the changenotes on the developer page for announcements.
This code is some basic code to set up tabs in Android.
final ActionBar actionBar = getActionBar();
actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS);
If you write this code in a project where targetSDK < 20 or compileSDK < 20 (I don't know what the difference is between versions of compileSDK and targetSDK) then it is fine.
However, if you have compileSDK higher, e.g. 23, then Android Studio will tell you that the code above is deprecated (and moreover is removed from SDK, I guess).
And it will crash my app if i run it on device (btw on Android level 20, though the target of project was set to 23 and compiled version too 23, so it crashes because it is deprecated and removed from SDK level 23).
Questions:
1) What happens if I compile my project with compileSDK version and
targetSDK version set to 20 (where there is no problem with being
deprecated) and try run it on Android with SDK 21 or 23 where these
functions are obviously removed from SDK? Will the app crash or work?
2) What happens if I decide to target the "high" SDK (e.g. 23)? That
is, I will leave the "old" code mentioned above and will use some
"new" code for tabs, which appeared in SDK 23 or so (which didn't
exist in lower SDK); then I will try to run the application on
Android with lower SDK, e.g. 20. Will the app crash or work?
edit:
Btw now i launched project with targetSDK and compileSDK 20 on Android with level 22 and it worked.
So it seems the only thing that really matters is the compileSDK version? Doesn't even matter on the SDK version of device but it really matters the compileSDK?
Because as i said about the two tests - project with bad HIGH SDK launched on device with good LOW SDK = crash. Project with good LOW SDK launched on devide with bad HIGH SDK = not crash.
But the logic of course say that it must also matter on android version of device (eg to access some new functions.. or really only matter on compiledSDK or at least from view of backwards-functionallity)?
Need some opinions of experts on this.
However, if you have compileSDK higher eg 23, then Android Studio will tell you, the code above is deprecated (and moreover removed from SDK i guess).
No. getActionBar() is not deprecated. setNavigationMode() is deprecated but not removed.
What happens, if i compile my project with compileSDK version and targetSDK version eg 20 (where is not problem with deprecated) and will try run it on Android with SDK eg 21 or 23 where are these functions from SDK obviously removed? Will app crash or work?
The app should work fine. "Deprecated" means "we think that there is a better solution and we would prefer that you use it".
What happens, if i decide to target the "high" SDK that means eg 23, i will leave the "old" code mentioned above and will use some "new" code for tabs, which appeared eg in SDK 23 or so (that means didn't exist in lower SDK) and i will try run the application on Android with lower SDK, eg 20? Will app crash or work?
First, I am not aware of any "'new' code for tabs, which appeared eg in SDK 23". The Design Support library has the only new tab implementation that I can think of, and it works back to API Level 7.
Second, your app should fail to compile, if you are trying to use something that is newer than your minSdkVersion without adequate checks (e.g., using Build.VERSION.SDK_INT and bypassing that code on older devices).
In the end, if you refer to a class, method, field, interface, and so on that does not exist on the older API level, your app will crash if and when that code gets executed. A typical error is VerifyError, though it depends a bit on the nature of what it is that you are trying to use that does not exist.
With respect to tabs, there are countless implementations available to you. Most come in the form of third-party libraries tied to ViewPager. In terms of the Android SDK, there the aforementioned TabLayout from the Design Support library, FragmentTabHost, and PagerTabStrip (though the latter has a bug in the 23.0.0 edition of the support-v4 library, apparently).
Deprecated API are still available, so you're free to use them - the app won't crash on neither of platforms. However, it's advised that you read the documentation to understand why the API have been deprecated: usually developers provide alternative solutions.
Here is some explanation on compile/target/minSDK.
1) What happens, if i compile my project with compileSDK version and
targetSDK version eg 20 (where is not problem with deprecated) and
will try run it on Android with SDK eg 21 or 23 where are these
functions from SDK obviously removed? Will app crash or work?
Android Studio is probably only warning you that the API has been deprecated, but not removed. If it had been removed, setting the compile SDK to 23 should break your compilation. Your application should work fine even if it is using a deprecated API, but you should update that when you have the time as it is no longer the recommended one.
2) What happens, if i decide to target the "high" SDK that means eg
23, i will leave the "old" code mentioned above and will use some
"new" code for tabs, which appeared eg in SDK 23 or so (that means
didn't exist in lower SDK) and i will try run the application on
Android with lower SDK, eg 20? Will app crash or work?
When you use an API that has been introduced in SDK 23, you will need to set compileSDK to 23 as well. In case you set your minSDK to 22, you will be able to install it on a device that is using SDK 22, however, your app will crash with a NoSuchMethodError if you try to use that method. You can however check the SDK running on the device (use Build.VERSION.SDK_INT) and not call that method in this case.
Well, I think that is not well explained and right now I'm a little bit confused. From this link:
Compile With is the platform version against which you will compile
your app. By default, this is set to the latest version of Android
available in your SDK. (It should be Android 4.1 or greater; if you
don't have such a version available, you must install one using the
SDK Manager). You can still build your app to support older versions,
but setting the build target to the latest version allows you to
enable new features and optimize your app for a great user experience
on the latest devices.
From this one instead:
When you are developing your application, you will need to choose the
platform version against which you will compile the application. In
general, you should compile your application against the lowest
possible version of the platform that your application can support.
Now, as they are contradicting themselves, here I'll explain what I've understood: let's say that we compile with api 5. It means that if I run from 1 to 5, my application works but it doesn't for versions > 5. So:
Why I need to set the minSdkVersion if compileWith is set to 5?
What is targetSdkVersion?
The point is: if compileWith is set to the latest version, is it possible to use latest APIs and still have backward compatibility? I'm sure that I'm wrong and I'm missing something. Thank you.
Edit 1
Now I understand more but anyway I'm missing something: let's say that minSdk is 9 and target is 18 (my current sdk). It means that I cannot use anything specific to api 18 unless there's some support package for older versions, right? I'm thinking different: I would compile with the lowest version possible to get forward compatibility. I mean, if you compile a Windows application on Win2000, it will run till Windows 8 but I'm limited to Win2000 apis. If I compile with Windows 8, the backward compatibility should be checked on runtime and I can use Windows 8 apis on Win2000 only with "support packages" (it's an example, obviously). Right?
Edit 2
This is what I'm asking about Android (not about the JVM). Android is mixing forward with backward and I've mixed it more using the Windows example. FIY, It seems that Windows is backward compatible, as explained in the examples here. So, what about Android? It seems that the minSdk version should be tested from the developer, I mean: I should compile with latest version and test my application behaviour till the minimum api level that doesn't change it. So it seems that I need to test the backward compatibility by testing on every api level lower than the one with wich is compiled and they assure the forward compatibility. Right?
I think that I'm mixing forward and backward compatibility definitions. Everytime I read them they seem different.
from the Documentation you can read the following:
android:minSdkVersion
An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.
and
android:targetSdkVersion
An integer designating the API Level that the application targets. If not set, the default value equals that given to minSdkVersion.
This attribute informs the system that you have tested against the target version and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to minSdkVersion).
And to answer your last question, targeting the latest API will not allow you to execute any newer method or use any newer class on old phones, for that you need to use the support packages, with that you are able to obtain a close result to what you can do in newer APIs.
Hope this gives you a more clear idead of why you have those two values and the difference between them.
UPDATE:
Well about the example of something built for windows 2000 and working on windows 8, is not guarantee that it will work, that is why on windows you have the "run with compatibility" mode, and then you select according to what operating system you want to run it.
This is because maybe both OS (or APIs in this case) have the same method or option, they do it in a different ways or need other permissions. The same happens here, so the target SDK will be the reference frame against you tested and thus it will use that behavior if you run it on newer devides than the taget SDK.
For the APIs between the min and the target they will run as normally they do, and so you can always have a weird behavior and some patching might be need it, normally is most visible on the 2.x to 3.x jump.
UPDATE 2:
Well, let me try to explain it in a different way.
The minSDK will determine which methods and options you can use throughout the application, this means that if a method is only available after that API, you will not be able to use it and instead get an error message.
The targetSDK represents the lastest version of the API that you tested and so, if the phone has a newer API than the one you specified, it will try to behave as it was on the API version you specified, take for example this, in the section Important Behavior Changes:
This inexact batching behavior applies only to updated apps. If you've set the targetSdkVersion to "18" or lower, your alarms will continue behave as they have on previous versions when running on Android 4.4.
So, as you can see there, if you set the targetSDK to a previous API (before 19), it will behave as it use to, but if you target the newest API (at this moment API 19), then it will behave differently.
Hope i was clear enough, if not, please do not hesitate and ask.