When using the new Android widgets CardView and RecyclerView I've noticed that they require minSdkVersion L. So if your project uses for example minSdkVersion 14, you will get an error like this:
> Manifest merger failed : uses-sdk:minSdkVersion 14 cannot be smaller than version L declared in library com.android.support:cardview-v7:21.0.0-rc1
I know there is a workaround that is telling Gradle to ignore the minSdkVersion of the library and use the one of the project instead.
<uses-sdk tools:node="replace" />
However if the library requires Android L, is it safe to ignore this error and use it anyway with older versions? and why did Google decided to not make them work with pre-L versions? I assume it's because it's not the final version?
All of the APIs Google released at I/O (including CardView and RecyclerView) are currently only intended as previews and should not be used for production applications.
This is Google's method of preventing these libraries from showing up in production applications before they are completed and released.
If you do want to use either of these with earlier versions of Android right now it's really easy. Just add RecyclerViewLib as a dependency in your build.gradle file.
compile 'com.twotoasters.RecyclerViewLib:library:1.0.+#aar'
The author talks about it in his blog post. All code depending on L has been removed so this is safe to use. Good luck!
Related
When I try to create Google Admob banner on my project, I receive an error like this below. I want to ask that, is there a solution without changing the minSDKVersion from 14 to 17? Maybe using an old release version of google ads dependency implementation on build.gradle file? If yes, is there any drawback doing this?
Thanks..
Manifest merger failed : uses-sdk:minSdkVersion 14 cannot be smaller than version 16 declared in library [com.google.android.gms:play-services-ads:19.1.0] C:\Users\SAMSUNG\.gradle\caches\transforms-2\files-2.1\3f183cf0518755adc969c4fb4eee168a\jetified-play-services-ads-19.1.0\AndroidManifest.xml as the library might be using APIs not available in 14
Suggestion: use a compatible library with a minSdk of at most 14,
or increase this project's minSdk version to at least 16,
or use tools:overrideLibrary="com.google.android.gms.ads.impl" to force usage (may lead to runtime failures)
I am trying to use RecyclerView & CardView in existing Android version. They said it is in support library. So, I should be able to use those with put "compileSdkVersion" to "Android-L". Right ?
I am trying to use those widgets without Android L Preview device or emulator.I have checked other questions on this matter. But, seems they all are trying Android-L with Android-L version.
Here is my dependencies.
compile 'com.android.support:support-v4:13.0.+'
compile 'com.android.support:recyclerview-v7:+'
Here is my target config
minSdkVersion 15
targetSdkVersion 20
Thanks in advance for any idea.
I just found the solution.
The reason why I can't build the App with RecyclerView & CardView while the targetSdkVersion and minSdkVersion is not "Android-L" is because internally Google designed to treat the preview version of OS differently comparing with original releases.
When I compile the App which contains the components from Android-L, the build tools locked minSdkVersion and targetSdkVersion to same level. The new supports libraries (RecyclerView, CardView, Palette, etc) are also locked into the L API level.
This behaviour is only happening on this Android-L preview release.
The fix for it is to put the following in AndroidManifest.xml.I didn't need to change anything on my gradle script.
<uses-sdk
tools:node="replace" />
Since version 0.11 of Android Gradle Plugin, it turned on a new Manifest Merger by default. It allows us to do some niffy stuffs. This specific configuration tells the manifest processor to replace any attributes from uses-sdk nodes in lower-priority manifest (such as library manifest in this case) with this attributes.
Since Gradle also inserts minSdkVersion and targetSdkVersion from your build.gradle into this uses-sdk node, that's all we really need to add.
Check here for more information related to this issue.
Check here for the info related to Manifest Merger.
The best solution is RecyclerViewLib. The support library has been pulled into a repo and published on maven central. It'll be safe even after L is released as all L dependent code has been removed. The author explains it here in his blog post.
To use it in your project just add the following line in your build.gradle dependencies:
compile 'com.twotoasters.RecyclerViewLib:library:1.0.+#aar'
Good luck!
No you must set targetSdkVersion above 7. You can use android support library v7 with project that support android above 7 api level.
And one more. Android L has api level 'android-L', not 20. Under the hood it has api level 21 (20 is 4.4W, KitKat for wearables).
Having issues with appcompat-v7 and compileSdkVersion, the app build target is API 10 so I set compileSdkVersion 10 to compile the code safely, as expected it works well with support-v4: the app compiles and runs on API 10 devices.
Then I want to add appcompat-v7 to dependencies (or replace v4 with it) and perform clean re-build of the app without any changes at the code or resources, build fails at the R generation stage unless the compileSdkVersion is set to a higher value.
I understand it as the v7 library is using some values unavailable at API 10. It raises the question of how someone can continue to write safe code and use v7 without need to manually check API level of each variable and method. Is there a way to keep using v7 (that is claimed to be "designed to be used with Android 2.1 (API level 7)") and compileSdkVersion 10 ?
Apparently at the newest Intellij version Lint produces errors if the methods form the API above minSdkVersion is used (can be enabled/disabled at Preferences-Inspections, expand Android Lint at the list, look for Calling new methods on older versions or use "NewApi" annotation to suppress the error if needed).
That'll have to do until some kind of dynamic resources compilation is introduced. I'm going to leave the question here for a future reference.
My app has a minSdkVersion of 8. I would like to use a library with a minSdkVersion of 14 on devices that support it and fallback to a different component if not. Theoretically, this might be possible using the new manifest merger, but it looks like there's a special case for minSdkVersion:
Defaults to 1.
The higher priority document's version will be used but importing a library with a more recent version will generate an error.
Is there a way to force gradle to include the library dependency so that I can deal with the SDK version issues?
Thanks to #CommonsWare's suggestion, I found the proper incantation. Everything works fine if I add this line to the AndroidManifest.xml:
<uses-sdk tools:node="replace" />
I have a gradle project that uses a library with a minSdkVersion set to api level 11. My application has a minSdkVersion of 9. When compiling I get the following error.
Main manifest has <uses-sdk android:minSdkVersion='9'> but library uses minSdkVersion='11'
I have seen a similar question titled manifest-merging-failed-android-studio but the solution was to change the library to have the same minSdk version. If you dont have control over the library that isnt possible.
The library is only used in situations where the minSdkVersion is higher than 11 so actual use isnt an issue.
Is there anyway to get the advantages manifest merging and let the library have a higher minSdk than your main project?
Workarounds that I have thought of but havent found a way to do.
Set priority if manifests conflict
Ignore minsdk for library projects
Remove minSdk from arr before merging starts