I use the following play services library in my android project. play-services-location,play-services-auth and play-services-gcm. The library are in version 9.2.0.I have the minSdkVersion as 9.
I recently added the VerifyApps API into the project and in order to use that library properly I had to add a new dependency com.google.android.gms:play-services-safetynet:11.6.0. When I added it, android studio asked to enter some class paths in myAndroidManifest file or else I had to improve my minSdkVersion to 14. After adding it some of the functionalities provided by the authAPI started acting up throwing some runtime exceptions in devices running Android 5.0 and above.
I upgraded my Auth and GCM API to version 11.6.0. Android studio again asked me to enter some more class paths in AndroidManifest file. After this the app is working fine but I came across this doc. According to this doc if I am using a play-service version greater than 10.2, my app will not work on devices below 4.0 (Correct me if I am wrong, But a careful look at the wordings lead me to believe that only the support is stopped but existing API calls will work just fine). But I am not using the full play-service dependency in my project I am just the aforementioned 4 libraries, so by adding the suggested entries in the AndroidManifest files should let my app to work just fine in devices below version 4.0 right?
If the functionalities are not fully supported then, is there a list of functionalities that will be affected by upgrading to this version?
You can create a special flavor for older platforms, and use it with an older version of gms. You will deploy the two flavors as split APKs to Play Store.
Related
I have developed an Android Library which is still using old support libraries. Recently one of my user facing multiple issues while integrating it with their App since they are using AndroidX libraries.
I am wondering whether I should migrate to AndroidX? If so, will there be any compatibility issue with the app that havn't migrated to AndroidX?
I am wondering whether I should migrate to AndroidX?
Yes you should.
All the new libraries, as Material Components for Android, Firebase and Google Play services require androidx migration.
Sooner or later you have to migrate.
Also support libraries will not be updated, it means no fixes, no new features. In the official doc you can find:
You can continue to use the support library. Historical artifacts (those versioned 27 and earlier, and packaged as android.support.*) will remain available on Google Maven. However, all new library development will occur in the AndroidX library.
We recommend using the AndroidX libraries in all new projects. You should also consider migrating existing projects to AndroidX as well.
Here all info to migrate.
If so, will there be any compatibility issue with the app that havn't migrated to AndroidX
Yes, the same issues that you are facing, but it will happen in any case with other major libraries.
See this
When you upload an APK, it needs to meet Google Play’s target API level requirements. Starting August 1, 2019, Google Play requires that new apps target at least Android 9.0 (API level 28), and that app updates target Android 9.0 from November 1, 2019. Until these dates, new apps and app updates must target at least Android 8.0 (API level 26).
Even if your app is in lower targetVersion if you're planning for an update. Then Google will push you to increase your targetVersion which causes you to migrate from support libraries to AndroidX. Also the existing libraries which will be also updated by their authors to AndroidX. So there's no other way, and you need to push to androidx components.
It's safe to migrate, and an easy process. There won't much code change if you migrate.
I need to set the target SDK version of an Android project to API 14. But I do not have the same version available to compile the project. I know that the project can be compiled with a different version but I need to know whether it will cause any issue.
I received the error "Android manifest file is missing" even though it exists. When I cleaned and then built the project it was compiled but the application crashed. What am I doing wrong here?
These were my settings.
There should be no issues introduced when compiling with a higher version, it is even encouraged to do so. You can find more on that topic in this Medium article.
I would also like to bring your attention to the following blog, which contains some important information regarding SDK targeting in the near future.
Unfortunately I do not use Eclipse so I fear cannot provide any verified insight on that matter. However the suggestions I have found so far include:
Cleaning the project
Getting rid of characters such as ö,ë, etc.
Deleting the file and recreating it
The manifest issue was probably due to creating a project with the same name over and over again. However clean -> build the project helped me get rid of it.
Yeah. Android compile version can be higher than the target version.
Android compile version and target version do not have to be the same.
compileSdkVersion
The compileSdkVersion is the version of the API the app is compiled against. This means you can use Android API features included in that version of the API (as well as all previous versions, obviously). If you try and use API 16 features but set compileSdkVersion to 15, you will get a compilation error. If you set compileSdkVersion to 16 you can still run the app on a API 15 device as long as your app's execution paths do not attempt to invoke any APIs specific to API 16.
targetSdkVersion
The targetSdkVersion has nothing to do with how your app is compiled or what APIs you can utilize. The targetSdkVersion is supposed to indicate that you have tested your app on (presumably up to and including) the version you specify. This is more like a certification or sign off you are giving the Android OS as a hint to how it should handle your app in terms of OS features.
As for the manifest error, you could try (if you are using android studio) clicking File > Invalidate Caches / Restart or force a gradle sync
Thank you for your answers.
I think the manifest issue was due to creating a project with the same name over and over again. However clean -> build the project helped me get rid of it.
Yeah. Android compile version can be higher than the target version. Those two do not have to be the same.
I added Android TV support to an existing app. I then had to increase the min SDK version to 17 from 14. Indication was the leanback library could not support below SDK 21, however, I seem to be able to use 17 as the minimum. I did have to add the following to my Android Manifest:
<uses-sdk
xmlns:tools="http://schemas.android.com/tools"
tools:overrideLibrary="android.support.v14.preference" />
This has to be a configuration issue in the manifest. Is there any further configuration required? The app does work on phones, tablets, and Nexus Player. It just doesn't support back to Android SDK 14, which has been requested by some users.
Code is here:
https://github.com/MythTV-Clients/MythtvPlayerForAndroid
The Leanback library has a minimum SDK version of 17. If you want to add Android TV support, you will need to add another module.
Looking at your project, it seems like "domain" and "presentation" are separate modules for the project. You can add one for "TV" and put TV specific code there. When the user installs the APK the correct version will be downloaded.
You can put phone specific code in a "phone" module. Shared code can be a "shared" module which can be compiled for both platforms.
Let me know if you have any questions with using modules.
I have older version of the android studio and I am happy from that. I think in newer version of the android studio, the proguard has been updated also.
Now, I want to have the updated version of proguard in my android studio. Is it possible?
You could download a zip distribution of a newer Android release and replace files manually. However this might not work at all because of incompabilities.
I recommend you to update to the latest Version. It has improved a lot since 1.0, but it hasn't changed much (instead added) so you will be able to use it without problems. To use the newer proguard you just have to change one line per gradle script once, which is really no big deal.
Android SDK Manager does not have different proguard feature available as they have like Android support library , Android support reposatory , Google play services and many more but not proguard.
so according to me it is not possible to update only proguard in android studio.
I am not fully certain that I am not making any mistakes when setting API level when developing under Eclipse so here are some examples which I am not 100% certain about.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
Yes this practice is correct and is done to ensure support for the latest android versions.
When you set a minSdkVersion, then that's thr lowest version of Android your app will support and compiling with ant/gradle will show errors ehen you will use methods introduced in newer api levels for an older one.
Deprecated means that another method has replaced this one and that this one will spon be removed from the Android source code, so developers are encouraged not to use them. But yes they will work until they remain in the source.
The android.jar is a dependency of the methods and stuff included in the android OS, stuff that you'd be able to call and no I don't think framework.jar plays a role in this.
All external libraries are referenced and added to the apk. BUT only some of the google ones, those that are not primary. (Take a look at the gapps packages, that'll give you some specifics. Link: http://goo.im/gapps)
I hope I got this right and helped you to understand.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
Yes. That way you ensure you're always using the latest build sdk.
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
Just make sure that older devices will not get to that part of the code, using Build.Version.SDK_INT. This will give you the current SDK of the device.
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
Deprecated methods will continue to work, but better alternatives are available. When you have the option to use that better alternative, use it. When you're supporting devices that don't have this alternative yet due to older versions, continue using the deprecated method. You might have to do some if else branching based upon the Build.Version.SDK_INT value.
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
The newer devices contain the code of the older devices. Therefore it is not necessary to keep references to other versions.
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
The class files in the jar will be packaged in the .apk. The Google Play Services on the device communicates with your app using those classes.