My application uses an old google play version that contains a class that I need,
unfortunately it's not possible to upgrade right now (due to time limitations)
A library that my application depends on, requires a newer version of google play, that does not longer hold that class.
My question is:
Is there a way to compile the library with a newer version, while compiling my application with the older one?
the current behaviour by gradle is to compile both of them with the newer google play version.
You can try to force use your google play version for library by excluding transitive dependency.
But is might not work. If so you can use hack way - changes package names in your version of google play as well use these "changed" classes in your app.
Related
I have a project using an old version of google play services that I need to keep otherwise it would need to be heavily rewritten. Now I have added a new library that uses a newer version of google play services and I get a duplicate class error.
How can I force android studio to use the newer version of google play services in the library for the library but also be able to use the older version in my app?
Unfortunately, this isn't possible. The classes for your app and the library are combined to form your APK, so you can only have one version of a given library. You could force it to use one of the two versions (for example, something like this), but based on your statement that it would need to be extensively rewritten, I assume that the two versions are not API compatible.
There are utilities like Jar Jar Links that can solve this in some cases, but (especially based on the embedded proguard rules, which reference classes found via reflection) I'd be surprised if it worked in the case of something as complex as Google Play Services, which is likely depending on its class names remaining unchanged.
I am trying to include a SMS feature from Google play services support libraries to improve the authentication process. The documentation around it recommends using atleast minimum of 10.2 play services in order to use it.
Prerequisites:
The SMS Retriever API is available only on Android devices with Play services version 10.2 and newer.
However, when I go to build my project specifying the 10.2.0 version of in gradle, Android studio tells me it is unable to resolve this dependency from either jcenter or google's repos.
compile 'com.google.android.gms:play-services-auth-api-phone:10.2.0'
Error:org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find com.google.android.gms:play-services-auth-api-phone:10.2.0.
I tried searching for the package, but couldn't find that version: google's maven repos only show 11.0 and above.
It would be really helpful if someone could point me to the minimum available version of play services libraries over 10.2 that can be used to make this work.
Versions of Google Play services prior to 11.0.0 are only available through the SDK Manager. Make sure you have installed the Google Play services item in the SDK Tools tab of the SDK Manager.
However, in the case of the SmsReceiverClient API, that class was only added in Google Play services 11.0.0 SDK. It may be that the underlying implementation did exist back to 10.2, but was not public.
In any case, Google Play services releases an SDK only after it is made available to all users and will automatically update the vast majority (99.5%+) of users within the first week or two of availability. Given that 11.0.0 has been available for over 6 months, it should not be any issue in relying on the 11.0.0 library.
Let's say in our project we go back in Git to a previous app version with older Google Play Services in build.gradle file and we have newer versions of Google Play Services SDK installed on our computers. So in that case, compiling either fails or succeeds but resulting app-crash in the first Google Play Services related operation.
For example the current crash message I am dealing with is starts like that:
java.lang.NoSuchMethodError: No static method zzax(Z)V in class
Lcom/google/android/gms/common/internal/c; or its super classes
(declaration of 'com.google.android.gms.common.internal.c'
and it points to this line:
GoogleAnalytics analytics = GoogleAnalytics.getInstance(context);
My question is, how one can compile an Android app with older Google Play Services dependencies while using newer SDK in it's computer?
Note:
I believe downgrading the SDK is not an option because the SDK manager doesn't show the obsolete version (while it does show for other components).
Thanks for your help.
What are the recommended practices for maintaining the widest backwards compatibility of an Android app while depending on Google Play Services?
The developer implementation documentation for using Android Studio indicate compiling against v5.+
compile 'com.google.android.gms:play-services:5.+' which with the available downloads I'm using seem to end up using version 5208000. At which point I get errors and warnings returned while testing an application:
W/GooglePlayServicesUtil Google Play services out of date. Requires 5208000 but found 5089036
E/GooglePlayServicesUtil GooglePlayServices not available due to error 2
Admob, my dependency on Google Play Services, appears to work normally however. If you follow the Google recommendation to call isGooglePlayServicesAvailable() and GooglePlayServicesUtil.getErrorDialog(), the user is told an upgrade is required for the app to work and sent to the store where there is no update available.
In other places maintaining backwards compatibility means compiling against the oldest API version that supports the features you need. So I tried with v4 compile 'com.google.android.gms:play-services:4.+' which generated another error:
E/GooglePlayServicesUtil﹕ The Google Play services resources were not found. Check your project configuration to ensure that the resources are included.
Searching around indicates this is a false report and can be ignored.
If I compile against a newer API version and it's not present on the device will things work? Or do I have to coax users into upgrading? Is it better to compile against an older API version and assume that things are properly backwards compatible with newer versions running on devices?
I'm the developer of an SDK that optionally depends on Google Play Services, and my approach has been, as you mentioned, to compile against the oldest version of Google Play Services that contains the APIs that I need, such that downstream clients won't into issues like these.
If the APIs that you need are available in v4, it's safe to compile against com.google.android.gms:play-services:4.+, and to follow Google's directions to show a prompt to a user to upgrade. Users will only see the upgrade dialog if they're running an older version of v4, or if they're somehow still on v3. In either case, the upgrade dialog should correctly lead them to the Play Store, where there will indeed be an upgrade available.
If the APIs that you need are only available in v5, do not use a wildcard version (ie 5.+). You should compile against an older version that is likely to be widespread, such as com.google.android.gms:play-services:5.0.89. Using a wildcard means you'll compile against the very latest version of Google Play Services that you've installed in the Android SDK manager, on whatever computer/environment you happen to be compiling on, which to me just feels wrong - I don't care if it's Google building the library, I like to know exactly what I'm compiling into my app.
Moreover, with a wildcard, if you always keep your SDK manager updated, whenever you compile the release version of your app and then push it to Google Play, you may have just shipped an app against a version of Play Services that isn't widespread, or worse - isn't even available for download on every device yet, in which case users will get the dialog and not be able to upgrade, as you've seen during development.
i am using google play services in my project, i am trying to use google map v2 service in my app.
For this i included play services as dependency in build.gradle file as mentioned in this thread.
for now the latest version of play services is 3.2.65 and i am pointing to it. Ok.
So my question is ,In the future when google releases newer version of play services and the device has play services version above 3.2.65 which was specified in build.gradle file, will cause any problem or not? And will my application adapts the latest feature of play services automatically or i have to release updates of my application every time google releases newer version of play services.
And if not then is there any other way or including play services in module dependency so that my application will always use updated version of play services.
Thanks
My guess is you have to recompile your project with a newer version of the library.
Various library versions are downloaded on your machine and used to compile the project.
SDK_DIRECTORY/extras/google/m2repository/com/google/android/gms
Of course Google releases things in order to preserve compatibility, so if you don't need any new feature/API you don't have to update your project.
In your build.gradle file, you can also write in this way:
compile 'com.google.android.gms:play-services:3.1.+'
So you will pick up any new 3.1.x version whatever is the latest number.
In the future when google releases newer version of play services and the device has play services version above 3.2.65 which was specified in build.gradle file, will cause any problem or not?
No, it won't cause any problems. Google Maps Android API v2 is developed in a forward-compatible way. No change will ever be made that can break older apps.
And will my application adapts the latest feature of play services automatically or i have to release updates of my application every time google releases newer version of play services.
Depends. Most of the bug fixes are made in the Google Play Services app and you don't need to update client library. Because client library has almost no code, there is low chance any bug will appear there.
If you want to use new features, you will obviously have to update the library to be able to call new APIs.