Status Update
No update yet.
Comments
sl...@google.com
Which version of R8 are you using?
nk...@google.com
pa...@mv-nordic.com
In order to diagnose this we would probably need to be able to reproduce this issue.
Would it be possible for you to share a compiler dump file that contains the inputs to R8 (i.e., the Java class files and the keep rules going into R8)? That way we should be able to reproduce the build. You can generate this as below and could share this privately with
./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.dumpinputtodirectory=/path/to/dumps
Do you know if the class ViewEventSinkImpl is instantiated using reflection? If so, do you know if there is a corresponding keep rule for the class?
Can you try if the following rule "fixes" the issue:
-keep,allowobfuscation,allowshrinking class org.chromium.content.browser.ViewEventSinkImpl
When this rule is present, R8 should account for the fact that ViewEventSinkImpl may be instantiated by reflection, which I suspect may fix the issue you are seeing.
sl...@google.com
nk...@google.com
Hi! I have also encountered a problem with r8 in --classfile mode incorrectly removing a null check, and curiously enough it also happened in and around ViewEventSinkImpl. I tried with the R8 version in Chromium and also with latest main branch local build from the repo which was be29229a110ce06989f6f3a63b0a83015ed3fefe.
The issue I'm seeing is from code which effectively does
public final class ViewEventSinkImpl ... {
private @Nullable Boolean mHasViewFocus; // not written to anywhere else
public void onViewFocusChanged(boolean gainFocus) {
if (mHasViewFocus != null && mHasViewFocus == gainFocus) return;
mHasViewFocus = gainFocus;
....
}
}
and after r8 with --classfile, the null check gets removed and the code is guaranteed to crash. Without --classfile, the null check remains in the dex. Note: for me, the code (with or without the check) was inlined at the only callsite to onViewFocusChanged.
Adding
-keep,allowobfuscation,allowshrinking class org.chromium.content.browser.ViewEventSinkImpl
works around the issue for me. I believe there is some reflection going on as one part of the code that affects that bug is the presence of
public static ViewEventSinkImpl from(WebContents webContents) {
ViewEventSinkImpl ret =
((WebContentsImpl) webContents)
.getOrSetUserData(
ViewEventSinkImpl.class, UserDataFactoryLazyHolder.INSTANCE);
return ret;
}
I hope the advice to send the repro case directly is still valid, I should have it down to a manageable size soon.
Description
// classpath 'com.android.tools.build:gradle:2.0.0-alpha9'
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:23.1.1'
androidTestCompile('com.android.support.test:runner:0.4.1') {
exclude module: 'support-annotations'
}
androidTestCompile('com.android.support.test:rules:0.4.1') {
exclude module: 'support-annotations'
}
What steps will reproduce the problem?
1. Setup example project with a FooService that returns itself via its LocalBinder (see attached sample project for easy setup).
2. Setup a test case using a ServiceTestRule that has 5 methods. Each of these methods call activityRule.bindService() and get the service via the returned 'LocalBinder.getService()' method.
3. Run the androidTest. First test will pass, 4 next tests will fail.
How are you running your tests (via Android Studio, Gradle, adb, etc.)?
Results are the same when running via Android Studio as well as `./gradlew connectedAndroidTest`.
What is the expected output? What do you see instead?
Expected: All 5 tests green. The service should always be shutdown at the end of each test by the ServiceTestRule.
Actual: First test green, other tests red - caused by a NullPointerException at LocalBinder.getService()).
Overall, this means we can't write more than one @Test method for a single service, because all following tests might fail.