Support packaging and extracting protos in Android aar

[voidzcy]

Adds support for packaging proto files into the aar for Android library projects and extracting proto files from aar dependencies.

---

The CI failure should be fixed by #441.

Fixes #435

[voidzcy]

I am highly suspecting this chunk of code is redundant and can be deleted:

protobuf-gradle-plugin/src/main/groovy/com/google/protobuf/gradle/ProtobufPlugin.groovy

Lines 403 to 423 in 7f96483

	// TL; DR: Make protos in 'test' sourceSet able to import protos from the 'main'
	// sourceSet. Sub-configurations, e.g., 'testCompile' that extends 'compile', don't
	// depend on the their super configurations. As a result, 'testCompile' doesn't depend on
	// 'compile' and it cannot get the proto files from 'main' sourceSet through the
	// configuration. However,
	if (Utils.isAndroidProject(project)) {
	// TODO(zhangkun83): Android sourceSet doesn't have compileClasspath. If it did, we
	// haven't figured out a way to put source protos in 'resources'. For now we use an
	// ad-hoc solution that manually includes the source protos of 'main' and its
	// dependencies.
	if (Utils.isTest(sourceSetOrVariantName)) {
	inputFiles.from getSourceSets()['main'].proto
	inputFiles.from testedCompileClasspathConfiguration ?: project.configurations['compile']
	}
	} else {
	// In Java projects, the compileClasspath of the 'test' sourceSet includes all the
	// 'resources' of the output of 'main', in which the source protos are placed. This is
	// nicer than the ad-hoc solution that Android has, because it works for any extended
	// configuration, not just 'testCompile'.
	inputFiles.from getSourceSets()[sourceSetOrVariantName].compileClasspath
	}

[ejona86]

How hard would it be to have a test?

[voidzcy]

How hard would it be to have a test?

Yep, that's something still under consideration.

[voidzcy]

I found a solution for tests to cover extracting protos from Jar/Aar built with project dependencies:

We can change

protobuf-gradle-plugin/testProjectDependentApp/build.gradle

Line 18 in 5291031

implementation project(':testProjectJavaLibrary')

to

implementation(project(':testProjectJavaLibrary')) {
        attributes {
            attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE,
                    project.getObjects().named(LibraryElements, LibraryElements.JAR))
        }
 }

which mutates the attributes of the project dependency and changes its libraryelements attribute for variant selection (some docs here and here). Therefore, we can force it to pull in the Jar instead of just classes (java-library's default) and resources (what our internal compileProtoPath enforces).

By turning on the log, you can see the difference for testProjectDependentApp:extractIncludeProto task:

Extracting protos from *********************/protobuf-gradle-plugin/build/tests/testProjectDependentAppMain/testProjectJavaLibrary/build/resources/main to *********************/protobuf-gradle-plugin/build/tests/testProjectDependentAppMain/testProjectDependentApp/build/extracted-include-protos/main
Extracting protos from *********************/protobuf-gradle-plugin/build/tests/testProjectDependentAppMain/testProjectJavaLibrary/build/classes/java/main to *********************/protobuf-gradle-plugin/build/tests/testProjectDependentAppMain/testProjectDependentApp/build/extracted-include-protos/main

vs

Extracting protos from ***************/protobuf-gradle-plugin/build/tests/testProjectDependentAppMain/testProjectJavaLibrary/build/libs/testProjectJavaLibrary.jar to *********************/protobuf-gradle-plugin/build/tests/testProjectDependentAppMain/testProjectDependentApp/build/extracted-include-protos/main

Ideally we can keep both test cases (if not too verbose) as one covers the plugin works for extracting protos from project dependencies built with java-library or android-library and the other covers the case protos coming from actual Jar/Aar.