Add support for Android SDK dependencies

[dlew]

Taking off from this discussion, it would be nice if this lib supported Android's support annotations.

At this point, though, we don't actually depend on any of the local repositories that the SDK uses; it's just using the few Android libs floating around in jcenter (which are rather out of date). This keeps the library simpler but limits our ability to add more recent support libraries.

Thoughts? Should we just embrace the local m2 repo?

[JakeWharton]

Yes. Related to what will be done for #74.

[JakeWharton]

This has multiple blockers. First one being nebula-plugins/gradle-rxjava-project-plugin#6.

[JakeWharton]

There's also this horrible transitive dependency on Spock which uses Groovy version-specific artifacts (cue facepalm) so we have to do gross shit like this to force the right version:

configurations.classpath.resolutionStrategy {
    // The 'nebula-test' plugin depends on Spock which is Groovy version specific (gross!). Explicitly
    // force the version which matches our Groovy version.
    eachDependency { DependencyResolveDetails details ->
        if (details.requested.name == 'spock-core') {
            details.useTarget group: details.requested.group, name: details.requested.name, version: '0.7-groovy-2.0'
        }
    }
}

[mttkay]

I'm not sure I understand how turning this into an Android library project relates to being able to use the support-library JARs. Is that because we'd have to apply the Android/Gradle plugin to the core library? Could we add the local SDK repositories to the build scripts instead to perform that lookup? At least as a temporary solution.

I don't see why the library has to be or should be an AAR. The rxandroid-framework might, because it might end up shipping Activities and stuff. Having an AndroidManifest for the main library seems pointless though, so by extension it's pointless to turn it into an AAR?

[JakeWharton]

Being an 'aar' affords us:

• Using the latest support library without incident (it's an aar, not a jar).
• Using the latest platform API without incident.
• Publishing embedded ProGuard rules and having them applied automatically.
• Publishing custom lint rules and having them show up in the IDE automatically.
• Linking against any of the 7 other support libraries for added functionality.
• Publishing a manifest with a minimum SDK that's enforced at compile time.

I said on some other issue that we can still publish the 'jar' version for legacy builds.

[mttkay]

That's good points there. Agreed then.

[JakeWharton]

Resolved by #189.