On Android, there is a race between making new RPCs and reconnecting after network comes back. If the former happens first, RPCs fail immediately. This is because resetConnectBackoff() does not update the picker before trying to reconnect and new RPCs are sent with the old picker, which fails RPCs immediately.
In this change, we move to use enterIdle(), which updates the channel picker to cause new RPCs being buffered (while subchannels are in reconnecting), at the moment network recovers. Hopefully, this can avoid RPCs being dropped prematurely in network recovery.
- Use gradle configuration `api` for dependencies that are part of grpc public api signatures.
- Replace deprecated gradle configurations `compile`, `testCompile`, `runtime` and `testRuntime`.
- With minimal change in dependencies: If we need dep X and Y to compile our code, and if X transitively depends on Y, then our build would still pass even if we only include X as `compile`/`implementation` dependency for our project. Ideally we should include both X and Y explicitly as `implementation` dependency for our project, but in this PR we don't add the missing Y if it is previously missing.
For Android version 28, some constants in ConnectivityManager have been deprecated such as ConnectivityManager. CONNECTIVITY_ACTION, ConnectivityManager. TYPE_WIFI, ConnectivityManager. TYPE_MOBILE, etc. In grpc-android, they are used for supporting legacy SDK connectivity state monitoring (and its unit tests). They work as intended for legacy SDK versions. So we suppress those warnings for the target SDK version 28.
Add grpc-android into main build. grpc-android will be built if Gradle option skipAndroid is false. This change also migrates deprecated Robolectric methods to androidx.test methods.
* Added missing Javadoc for public methods, deprecate fromBuilder and replace with usingBuilder.
* Removed unnecessary final keyword for static methods.
* call usingBuilder in deprecated fromBuilder
* Changed Javadoc description for usingBuilder method.
* android: fix Javadoc symbol/class not found errors
* Removed redundant join, files API can already handle list.
* Replace usage of javaCompile with javaCompileProvider
* Avoid afterEvaluate by filling javadocs.classpath in android configuration.
* Construct FileCollection via files(Closure), which delays the file resolution.
This fixes the following warning when building grpc-android:
WARNING: API 'variant.getJavaCompiler()' is obsolete and has been replaced with 'variant.getJavaCompileProvider()'.
It will be removed at the end of 2019.
For more information, see https://d.android.com/r/tools/task-configuration-avoidance.
To determine what is calling variant.getJavaCompiler(), use -Pandroid.debug.obsoleteApi=true on the command line to display a stack trace.
com.github.dcendents:android-maven-gradle-plugin is incompatible with
Gradle 5 and the project hasn't seen any activity in over a year, so it
seems unlikely to get fixed.
We want to use maven-publish anyway, since that's what we use elsewhere.
This resolves#5523
While bumping `com.android.tools.build:gradle:3.1.2` to `3.3.0`, some other plugins/artifacts/maven repo/buildscripts have to be updated:
- gradle (wrapper) need to upgrade to 4.10.x
- protobuf gradle plugin need to bump a version compatible with gradle version.
- need add `google()` and `jcenter()` repos for android (otherwise `com.android.tools.build:aapt2:3.3.0x` and `trove4j` will not be found resp.)
- need to accept license for Android "build-tools;28.0.3" in kokoro env.
This PR adds an automatic gradle format checker and reformats all the *.gradle files. After this, new changes to *.gradle files will fail to build if not in good format, just like checkStyle failure.
The new jmh plugin fixes a warning for the newer version of Gradle.
The new AppEngine plugin still produces a warning, but updating it
anyway so people know that upgrading the plugin doesn't fix the problem.
The new android-maven plugin fixes a build problem with the newer
Gradle.
The Visual Studio fixes were necessary starting ~4.4.
https://github.com/gradle/gradle-native/issues/34#issuecomment-335222096
describes the change in behavior.
There's nothing immediately being used as part of this update. It's just
to keep us current and to get us over that Visual Studio change hump.