Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

android-interop-testing: include android interop testing in main build #6829

Merged

Conversation

voidzcy
Copy link
Contributor

@voidzcy voidzcy commented Mar 13, 2020

For #6775.

TODO: temporarily disabled code shrinking for release buildType, need to fix proguard rules to before being able to do code shrinking.
The problem was caused by pulling in org.apache.httpcomponents.htttpcore by google auth2 lib. According to Proguard:

In Android development, sloppy libraries may contain duplicates of classes that are already present in the Android run-time (notably org.w3c.dom, org.xml.sax, org.xmlpull.v1, org.apache.commons.logging.Log, org.apache.http, and org.json). You must remove these classes from your libraries, since they are possibly inconsistent, and the run-time libraries would get precedence anyway.

TODO: there are tons of errorprone warnings and Proguard notes. Although they do not cause build fail, it would be better to fix/suppress them.
Proguard notes seem to be fine. There are some compiler warnings coming from javalite generated code, nothing can be done to fix that. A couple of errorprone warnings left, but unclear if it is necessary to fix them.

After the change, generated code will be checked in. So this PR contains generated code. Reviewers should only need to review .gradle, .md files, proguard-rules.pro, InteropTask.java and TesterActivity.java.

@voidzcy voidzcy marked this pull request as ready for review March 16, 2020 09:17
@voidzcy voidzcy force-pushed the build/add_android_interop_testing_into_main_build branch from a6b2739 to c9956a2 Compare March 16, 2020 18:49
Copy link
Contributor

@creamsoup creamsoup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not fully reviewed, sending what i have now
i ran ./gradlew :grpc-android-interop-testing:{test,checkStyleMain} those tasks don't work.

RELEASING.md Show resolved Hide resolved
@voidzcy
Copy link
Contributor Author

voidzcy commented Mar 16, 2020

not fully reviewed, sending what i have now
i ran ./gradlew :grpc-android-interop-testing:{test,checkStyleMain} those tasks don't work.

You should be able to run ./gradlew :grpc-android-interop-testing:test. checkStyle tasks do not exist in android modules (same for grpc-android and grpc-cronet). They are only added to modules with java plugin. We could add checkStyle tasks (if we are able to) for android modules either manually in each modules buildscript (like what we are currently doing for javadoc tasks) or find a solution to configure globally in grpc's main buildscript. Anyway, checkStyle issue would be addressed separately, together with grpc-android and grpc-cronet.

@creamsoup
Copy link
Contributor

You should be able to run ./gradlew :grpc-android-interop-testing:test.

yes, it turns out that it was my local environmental issue.

Copy link
Contributor

@creamsoup creamsoup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dapengzhang0
Copy link
Member

dapengzhang0 commented Mar 17, 2020

@voidzcy My local run of ./gradlew grpc-android-interop-testing:build -PskipAndroid=false fails as follows

> Task :grpc-android-interop-testing:transformClassesAndResourcesWithProguardForRelease
Request to incrementing alive workforce from 0. Current workforce (dead or alive) 0
thread-pool size=4

Note: the configuration refers to the unknown field 'com.google.android.gms.common.api.internal.BasePendingResult$ReleasableResultGuardian mResultGuardian' in class 'com.google.android.gms.common.api.internal.BasePendingResult'
Note: the configuration keeps the entry point 'com.google.android.gms.common.api.internal.LifecycleCallback { com.google.android.gms.common.api.internal.LifecycleFragment getChimeraLifecycleFragmentImpl(com.google.android.gms.common.api.internal.LifecycleActivity); }', but not the descriptor class 'com.google.android.gms.common.api.internal.LifecycleActivity'
Note: the configuration keeps the entry point 'com.google.android.gms.common.images.internal.LoadingImageView { void setOnImageLoadedListener(com.google.android.gms.common.images.ImageManager$OnImageLoadedListener); }', but not the descriptor class 'com.google.android.gms.common.images.ImageManager$OnImageLoadedListener'
Note: the configuration keeps the entry point 'com.google.android.gms.common.images.internal.LoadingImageView { void setClipPathProvider(com.google.android.gms.common.images.internal.LoadingImageView$ClipPathProvider); }', but not the descriptor class 'com.google.android.gms.common.images.internal.LoadingImageView$ClipPathProvider'
Note: there were 1 references to unknown classes.
      You should check your configuration for typos.
      (http://proguard.sourceforge.net/manual/troubleshooting.html#unknownclass)
Note: there were 1 references to unknown class members.
      You should check your configuration for typos.
Note: there were 3 unkept descriptor classes in kept class members.
      You should consider explicitly keeping the mentioned classes
      (using '-keep').
      (http://proguard.sourceforge.net/manual/troubleshooting.html#descriptorclass)
Note: there were 26 unresolved dynamic references to classes or interfaces.
      You should check if you need to specify additional program jars.
      (http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Warning: there were 3 unresolved references to library class members.
         You probably need to update the library versions.
         (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedlibraryclassmember)
Warning: Exception while processing task java.io.IOException: Please correct the above warnings first.
Thread(Tasks limiter_1): destruction

> Task :grpc-android-interop-testing:transformClassesAndResourcesWithProguardForRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':grpc-android-interop-testing:transformClassesAndResourcesWithProguardForRelease'.
> Job failed, see logs for details

@voidzcy
Copy link
Contributor Author

voidzcy commented Mar 17, 2020

@voidzcy My local run of ./gradlew grpc-android-interop-testing:build -PskipAndroid=false fails as follows

> Task :grpc-android-interop-testing:transformClassesAndResourcesWithProguardForRelease
Request to incrementing alive workforce from 0. Current workforce (dead or alive) 0
thread-pool size=4

Note: the configuration refers to the unknown field 'com.google.android.gms.common.api.internal.BasePendingResult$ReleasableResultGuardian mResultGuardian' in class 'com.google.android.gms.common.api.internal.BasePendingResult'
Note: the configuration keeps the entry point 'com.google.android.gms.common.api.internal.LifecycleCallback { com.google.android.gms.common.api.internal.LifecycleFragment getChimeraLifecycleFragmentImpl(com.google.android.gms.common.api.internal.LifecycleActivity); }', but not the descriptor class 'com.google.android.gms.common.api.internal.LifecycleActivity'
Note: the configuration keeps the entry point 'com.google.android.gms.common.images.internal.LoadingImageView { void setOnImageLoadedListener(com.google.android.gms.common.images.ImageManager$OnImageLoadedListener); }', but not the descriptor class 'com.google.android.gms.common.images.ImageManager$OnImageLoadedListener'
Note: the configuration keeps the entry point 'com.google.android.gms.common.images.internal.LoadingImageView { void setClipPathProvider(com.google.android.gms.common.images.internal.LoadingImageView$ClipPathProvider); }', but not the descriptor class 'com.google.android.gms.common.images.internal.LoadingImageView$ClipPathProvider'
Note: there were 1 references to unknown classes.
      You should check your configuration for typos.
      (http://proguard.sourceforge.net/manual/troubleshooting.html#unknownclass)
Note: there were 1 references to unknown class members.
      You should check your configuration for typos.
Note: there were 3 unkept descriptor classes in kept class members.
      You should consider explicitly keeping the mentioned classes
      (using '-keep').
      (http://proguard.sourceforge.net/manual/troubleshooting.html#descriptorclass)
Note: there were 26 unresolved dynamic references to classes or interfaces.
      You should check if you need to specify additional program jars.
      (http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Warning: there were 3 unresolved references to library class members.
         You probably need to update the library versions.
         (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedlibraryclassmember)
Warning: Exception while processing task java.io.IOException: Please correct the above warnings first.
Thread(Tasks limiter_1): destruction

> Task :grpc-android-interop-testing:transformClassesAndResourcesWithProguardForRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':grpc-android-interop-testing:transformClassesAndResourcesWithProguardForRelease'.
> Job failed, see logs for details

Did you pull all commits in this PR? That's caused by ProGuard and I should have fixed it in commit 61a3d75

@dapengzhang0
Copy link
Member

dapengzhang0 commented Mar 17, 2020

Yes, I pulled the PR up to f7c160c . However, I tested build in master and it failed similarly. I figured out the actual failure is

Warning: io.grpc.internal.CompositeReadableBuffer$4: can't find referenced method 'java.nio.ByteBuffer limit(int)' in library class java.nio.ByteBuffer
Warning: io.grpc.internal.ReadableBuffers$ByteReadableBufferWrapper: can't find referenced method 'java.nio.ByteBuffer position(int)' in library class java.nio.ByteBuffer
Warning: io.grpc.internal.ReadableBuffers$ByteReadableBufferWrapper: can't find referenced method 'java.nio.ByteBuffer limit(int)' in library class java.nio.ByteBuffer

I think it is because I was using jdk 11. I believe it's not a problem from your change.

@voidzcy
Copy link
Contributor Author

voidzcy commented Mar 17, 2020

Yes, I pulled the PR up to f7c160c . However, I tested build in master and it failed similarly. I figured out the actual failure is

Warning: io.grpc.internal.CompositeReadableBuffer$4: can't find referenced method 'java.nio.ByteBuffer limit(int)' in library class java.nio.ByteBuffer
Warning: io.grpc.internal.ReadableBuffers$ByteReadableBufferWrapper: can't find referenced method 'java.nio.ByteBuffer position(int)' in library class java.nio.ByteBuffer
Warning: io.grpc.internal.ReadableBuffers$ByteReadableBufferWrapper: can't find referenced method 'java.nio.ByteBuffer limit(int)' in library class java.nio.ByteBuffer

I think it is because I was using jdk 11. I believe it's not a problem from your change.

Yes yes. You need to recompile everything with jdk 8.

@ericgribkoff
Copy link
Contributor

Yes yes. You need to recompile everything with jdk 8.

I'm a little confused about the intended support for JDK versions here. Currently I can build grpc-java at master with JDK 11. With this PR, I need to use JDK 8 (JDK 11 fails) and it sounds like this is intentional. I'm not sure why this would be a desired change, but if it is, should this be explained and documented somewhere?

@dapengzhang0
Copy link
Member

Java 9 made an ABI incompatible change in java.nio.ByteBuffer See apache/felix#114

I'm a little confused about the intended support for JDK versions here. Currently I can build grpc-java at master with JDK 11. With this PR, I need to use JDK 8 (JDK 11 fails) and it sounds like this is intentional. I'm not sure why this would be a desired change, but if it is, should this be explained and documented somewhere?

@voidzcy
Copy link
Contributor Author

voidzcy commented Mar 18, 2020

Yes yes. You need to recompile everything with jdk 8.

I'm a little confused about the intended support for JDK versions here. Currently I can build grpc-java at master with JDK 11. With this PR, I need to use JDK 8 (JDK 11 fails) and it sounds like this is intentional. I'm not sure why this would be a desired change, but if it is, should this be explained and documented somewhere?

I suspect this is due to Android. You cannot use JDK 11 to build some part of the source (i.e., grpc-core, in which java.nio.ByteBuffer is used) and use Android SDK to build grpc-android-interop-testing which depends on grpc-core. This causes the method not found problem.

Do you know if there is any good solution to mitigate this?

@ericgribkoff
Copy link
Contributor

My concern was just that a user who tries to build the grpc-java project with JDK 11 will start getting a build error, the cause of which is not very obvious (at least to me, I didn't immediately think JDK incompatibility). Building with skipAndroid=true works fine with JDK 11, so maybe that's fine for most people; not sure. But that would mean that my normal workflow would have to change to using JDK 8 or keep using JDK 11 but skipping Android builds whenever I build the project. Both of those are probably fine, but this doesn't seem like it will be at all obvious to newcomers to the project.

@voidzcy
Copy link
Contributor Author

voidzcy commented Mar 18, 2020

My concern was just that a user who tries to build the grpc-java project with JDK 11 will start getting a build error, the cause of which is not very obvious (at least to me, I didn't immediately think JDK incompatibility). Building with skipAndroid=true works fine with JDK 11, so maybe that's fine for most people; not sure. But that would mean that my normal workflow would have to change to using JDK 8 or keep using JDK 11 but skipping Android builds whenever I build the project. Both of those are probably fine, but this doesn't seem like it will be at all obvious to newcomers to the project.

Alright. This is actually an issue when ProGuard is trying to remove unused code, not really bytecode incompatibility (we have sourceCompatibility = 1.7 in the main build file, so real method invocation should be fine). In this case, we could simply add -dontwarn java.nio.ByteBuffer to grpc-android-interop-testing's ProGuard rules to ignore that warning. I tried this locally and it seems to work for JDK 11.

@voidzcy
Copy link
Contributor Author

voidzcy commented Mar 18, 2020

Edited ProGuard rules, build (skipAndroid=false) should succeed for JDK 9+.

@dapengzhang0
Copy link
Member

Good point. I'm trying to fix this in general in #6839

My concern was just that a user who tries to build the grpc-java project with JDK 11 will start getting a build error, the cause of which is not very obvious (at least to me, I didn't immediately think JDK incompatibility). Building with skipAndroid=true works fine with JDK 11, so maybe that's fine for most people; not sure. But that would mean that my normal workflow would have to change to using JDK 8 or keep using JDK 11 but skipping Android builds whenever I build the project. Both of those are probably fine, but this doesn't seem like it will be at all obvious to newcomers to the project.

Copy link
Member

@dapengzhang0 dapengzhang0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

android-interop-testing/proguard-rules.pro Outdated Show resolved Hide resolved
@voidzcy voidzcy merged commit d537ade into grpc:master Mar 19, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jun 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants