3

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?

mmBs
  • 8,421
  • 6
  • 38
  • 46
ertyu
  • 47
  • 6

1 Answers1

3

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.

Sam Dozor
  • 40,335
  • 6
  • 42
  • 42
  • Thanks for the comments, they reaffirm my understanding. The confusing part is why Google's documentation suggests doing something that isn't a best practice and is in fact problematic. – ertyu Sep 12 '14 at 18:37