ProGuard build failure when importing androidx.window

[Daniel Libby]

Hi java@ - I'm trying to track down a build error that appears to only repro with ProGuard. In this prototype CL - https://chromium-review.googlesource.com/c/chromium/src/+/2427156 - I'm trying to integrate usage of androidx.window. This builds fine locally, and on some bots (e.g. android-lollipop-arm-rel), but is failing on other bots due to the following error:

 

Warning: Missing class: androidx.window.sidecar.SidecarInterface$SidecarCallback

Warning: Missing class: androidx.window.extensions.ExtensionInterface$ExtensionCallback

Error: com.android.tools.r8.errors.CompilationError: Compilation can't be completed because `androidx.window.sidecar.SidecarInterface$SidecarCallback` and 1 other classes are missing.

 

https://ci.chromium.org/p/chromium/builders/try/android-binary-size/621785?

https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8868233277944922736/+/steps/compile__with_patch_/0/logs/raw_io.output_failure_summary_/0

 

I looked at the aar/jar associated with this jetpack library, and sure enough those classes are not present. Yet I can build and deploy chrome_public_apk (and webview as well). Is this indicative of a missing dependency, me holding the build tools wrong, or perhaps something else?

 

I'm not a Java developer, so any assistance you could provide would be greatly appreciated!

 

dlibby@dlibby-build1:~/cr/src$ jar tvf  ../.cipd/pkgs/159/_current/window-1.0.0-

alpha01.aar

     0 Fri Feb 01 00:00:00 PST 1980 R.txt

  1112 Fri Feb 01 00:00:00 PST 1980 AndroidManifest.xml

   654 Fri Feb 01 00:00:00 PST 1980 annotations.zip

30652 Fri Feb 01 00:00:00 PST 1980 classes.jar

dlibby@dlibby-build1:~/cr/src$ jar xf  ../.cipd/pkgs/159/_current/window-1.0.0-a

lpha01.aar

 

dlibby@dlibby-build1:~/cr/src$ jar tf classes.jar

androidx/window/DeviceState$Builder.class

androidx/window/DeviceState.class

androidx/window/DisplayFeature$Builder.class

androidx/window/DisplayFeature.class

androidx/window/ExtensionCompat$1.class

androidx/window/ExtensionCompat.class

androidx/window/ExtensionHelper.class

androidx/window/ExtensionInterfaceCompat$ExtensionCallbackInterface.class

androidx/window/ExtensionInterfaceCompat.class

androidx/window/ExtensionWindowBackend$1.class

androidx/window/ExtensionWindowBackend$DeviceStateChangeCallbackWrapper.class

androidx/window/ExtensionWindowBackend$ExtensionListenerImpl$1.class

androidx/window/ExtensionWindowBackend$ExtensionListenerImpl$2.class

androidx/window/ExtensionWindowBackend$ExtensionListenerImpl.class

androidx/window/ExtensionWindowBackend$WindowLayoutChangeCallbackWrapper.class

androidx/window/ExtensionWindowBackend.class

androidx/window/SidecarCompat$1.class

androidx/window/SidecarCompat.class

androidx/window/Version.class

androidx/window/WindowBackend.class

androidx/window/WindowLayoutInfo$Builder.class

androidx/window/WindowLayoutInfo.class

androidx/window/WindowManager.class

META-INF/androidx.window_window.version

[Andrew Grieve]

Looks like you've done all the steps to investigate properly. I think the conclusion here is that the 1.0.0-alpha versions of androidx.window is missing .class files :(.

You can probably get past the proguard error by adding to the proguard configs "-dontwarn androidx.window.*", but if the code referencing these missing class files is needed at runtime, you'll just end up hitting runtime errors.

--
You received this message because you are subscribed to the Google Groups "java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/java/SN6PR00MB044696B154154F9D023F3272D9371%40SN6PR00MB0446.namprd00.prod.outlook.com.

[Daniel Libby]

Thanks for the pointers (also to smaier@ who replied in the CL)! I’ll give those a try and report this to the Android folks working on the support library.

[Daniel Libby]

To follow up here, I was able to repro locally by setting `is_java_debug = false`, then add the exceptions to produce an APK. However, as was raised as a possibility, this resulted in a runtime exception.

 

What I’m having a hard time understanding is how this works for builds without ProGuard? I also played around with various `-keep` directives but didn’t have any luck. Is there a way to workaround this without requiring a republish of the jetpack library?

 

FWIW it does look like the library authors have already been making changes related to this:

655d1f908cc45c4e1e5bcd8ab1ee48b823cedf55 - platform/frameworks/support - Git at Google (googlesource.com)

c592db9944cc0531079eb2f91183febc629b20aa - platform/frameworks/support - Git at Google (googlesource.com)

b6a13c5c6c2d93b6f40bfd5208d2f7e52916a6fd - platform/frameworks/support - Git at Google (googlesource.com)

 

I’m following up with contacts to make sure this is known and correctly reported.

[Sam Maier]

To be clear here, this code runs and executes just fine in debug mode? What's the runtime exception you get in release mode?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/java/MW2PR00MB0444596CB486BCA6D98773D0D9331%40MW2PR00MB0444.namprd00.prod.outlook.com.

[Daniel Libby]

I did rebase in between, but I don’t _think_ that would be related (but good point, let me doublecheck). The runtime exception looked directly related to the interface/class being warned about so perhaps I jumped to conclusions.

 

09-29 13:55:01.382  5067  5067 D MicrosoftSurfaceExt: onServiceConnected

09-29 13:55:01.382  1792  2089 D VLMService: addLayoutChangeListener: 102170999

09-29 13:55:01.385  1792  2089 D VLMService: addWindowExtensionCallback: 91965005

09-29 13:55:01.386  5067  5083 E JavaBinder: *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)

09-29 13:55:01.386  5067  5083 E JavaBinder: java.lang.AbstractMethodError: abstract method "void androidx.window.sidecar.SidecarInterface$SidecarCallback.onDeviceStateChanged(androidx.window.sidecar.SidecarDeviceState)"

09-29 13:55:01.386  5067  5083 E JavaBinder:    at androidx.window.sidecar.MicrosoftSurfaceSidecar.updateDeviceState(MicrosoftSurfaceSidecar.java:158)

09-29 13:55:01.386  5067  5083 E JavaBinder:    at androidx.window.sidecar.MicrosoftSurfaceSidecar$1.deviceStateChanged(MicrosoftSurfaceSidecar.java:193)

09-29 13:55:01.386  5067  5083 E JavaBinder:    at android.vendor.screenlayout.service.IWindowExtensionCallbackInterface$Stub.onTransact(IWindowExtensionCallbackInterface.java:94)

09-29 13:55:01.386  5067  5083 E JavaBinder:    at android.os.Binder.execTransactInternal(Binder.java:1021)

09-29 13:55:01.386  5067  5083 E JavaBinder:    at android.os.Binder.execTransact(Binder.java:994)

09-29 13:55:01.387  5067  5083 E AndroidRuntime: FATAL EXCEPTION: Binder:5067_2

09-29 13:55:01.387  5067  5083 E AndroidRuntime: Process: org.chromium.chrome, PID: 5067

09-29 13:55:01.387  5067  5083 E AndroidRuntime: java.lang.AbstractMethodError: abstract method "void androidx.window.sidecar.SidecarInterface$SidecarCallback.onDeviceStateChanged(androidx.window.sidecar.SidecarDeviceState)"

09-29 13:55:01.387  5067  5083 E AndroidRuntime:        at androidx.window.sidecar.MicrosoftSurfaceSidecar.updateDeviceState(MicrosoftSurfaceSidecar.java:158)

09-29 13:55:01.387  5067  5083 E AndroidRuntime:        at androidx.window.sidecar.MicrosoftSurfaceSidecar$1.deviceStateChanged(MicrosoftSurfaceSidecar.java:193)

09-29 13:55:01.387  5067  5083 E AndroidRuntime:        at android.vendor.screenlayout.service.IWindowExtensionCallbackInterface$Stub.onTransact(IWindowExtensionCallbackInterface.java:94)

09-29 13:55:01.387  5067  5083 E AndroidRuntime:        at android.os.Binder.execTransactInternal(Binder.java:1021)

09-29 13:55:01.387  5067  5083 E AndroidRuntime:        at android.os.Binder.execTransact(Binder.java:994)

09-29 13:55:01.387  5067  5067 D ApplicationBarView-A11y: Invoke updateAccessibilityServicesState

09-29 13:55:01.388  5067  5067 D ApplicationBarView-A11y: setAccessibilityButtonState v = false, longClickable = false

09-29 13:55:01.396  1792  2089 W ActivityTaskManager:   Force finishing activity org.chromium.chrome/com.google.android.apps.chrome.Main

[Daniel Libby]

Yes, verified that setting is_java_debug = true results in an APK that doesn’t crash.

 

For more context, the crash is on the Surface Duo emulator, where an implementation of the Sidecar interface comes into play. I’m pretty sure it won’t crash on devices where the vendor doesn’t implement that (or the androidx.window.extension.Extension interface). Though TBF seems like my mental model is not too sound w.r.t. all this stuff since I cannot explain the debug build working where non-debug doesn’t.

[Sam Maier]

There's a chance that R8 (our ProGuard-like optimizer) is subtly changing the code here. I think this will be easiest to investigate if you look at the dexdump of the debug and release code, and compare what's different, and perhaps then we can understand if R8 is making a valid optimization given the semi-broken inputs, or if there's a bug in R8.

[Andrew Grieve]

If there's a fixed version via https://androidx.dev/ snapshot, then it wouldn't be too hard to drop one from there in instead.

[Daniel Libby]

I tried the latest from the snapshots, but got the same result. Specifically, based on the contents of

https://androidx.dev/snapshots/builds/6888068/artifacts/BUILD_INFO

 

Dropped this aar on top of the one in my local .cipd directory:

https://androidx.dev/snapshots/builds/6888068/artifacts/repository/androidx/window/window/1.0.0-SNAPSHOT/window-1.0.0-20201006.235333-1.aar

 

 

For dexdump, I grabbed the tool by `sudo apt install dexdump`, unpacked the locally built apk, and ran dexdump to output xml (there were 5 .dex files for debug, 1 for non-debug). I’m having trouble making sense of the dexdump, mainly because of the obfuscation of the optimized build.

 

I’ve attached a no-proguard -dex.xml that contains the entire section for androidx.window package.

 

One thing I noticed is that the class that implements one of the missing interfaces/classes does look different, but I can’t tell if this is relevant or not. Am I looking in the right spot? Maybe I should rerun a build with obfuscation off but shrinking on?

 

Proguard:

<class name="cl"

extends="java.lang.Object"

interface="false"

abstract="false"

static="false"

final="false"

visibility="public"

> 

<implements name="androidx.window.sidecar.SidecarInterface.SidecarCallback">

</implements>

<constructor name="cl"

type="cl"

static="false"

final="false"

visibility="public"

> 

<parameter name="arg0" type="dl">

</parameter>

<parameter name="arg1" type="Xk">

</parameter>

</constructor>

</class>

 

Vs. no Proguard:

 

<class name="SidecarCompat.1"

extends="java.lang.Object"

interface="false"

abstract="false"

static="false"

final="false"

visibility="package"

> 

<implements name="androidx.window.sidecar.SidecarInterface.SidecarCallback">

</implements>

<field name="this$0"

type="androidx.window.SidecarCompat"

transient="false"

volatile="false"

static="false"

final="true"

visibility="package"

> 

</field>

<field name="val$extensionCallback"

type="androidx.window.ExtensionInterfaceCompat.ExtensionCallbackInterface"

transient="false"

volatile="false"

static="false"

final="true"

visibility="package"

> 

</field>

<constructor name="SidecarCompat.1"

type="androidx.window.SidecarCompat.1"

static="false"

final="false"

visibility="package"

> 

<parameter name="arg0" type="androidx.window.SidecarCompat">

</parameter>

<parameter name="arg1" type="androidx.window.ExtensionInterfaceCompat.ExtensionCallbackInterface">

</parameter>

</constructor>

<method name="onDeviceStateChanged"

return="void"

abstract="false"

native="false"

synchronized="false"

static="false"

final="false"

visibility="public"

> 

<parameter name="arg0" type="androidx.window.sidecar.SidecarDeviceState">

</parameter>

</method>

<method name="onWindowLayoutChanged"

return="void"

abstract="false"

native="false"

synchronized="false"

static="false"

final="false"

visibility="public"

> 

<parameter name="arg0" type="android.os.IBinder">

</parameter>

<parameter name="arg1" type="androidx.window.sidecar.SidecarWindowLayoutInfo">

</parameter>

</method>

</class>

[Andrew Grieve]

On Tue, Oct 6, 2020 at 9:51 PM Daniel Libby <dli...@microsoft.com> wrote:

I tried the latest from the snapshots, but got the same result. Specifically, based on the contents of

https://androidx.dev/snapshots/builds/6888068/artifacts/BUILD_INFO

 

Dropped this aar on top of the one in my local .cipd directory:

https://androidx.dev/snapshots/builds/6888068/artifacts/repository/androidx/window/window/1.0.0-SNAPSHOT/window-1.0.0-20201006.235333-1.aar

Looks like the classes are still missing here (bug doesn't seem to be fixed):

mkdir tmp && cd tmp

unzip ../window-1.0.0-20201006.235333-1.aar classes.jar

unzip classes.jar

grep -r SidecarCallback .
Binary file ./androidx/window/SidecarCompat.class matches
Binary file ./androidx/window/SidecarCompat$1.class matches

unzip -l classes.jar | grep SidecarCallback # No output

 

 

 

For dexdump, I grabbed the tool by `sudo apt install dexdump`, unpacked the locally built apk, and ran dexdump to output xml (there were 5 .dex files for debug, 1 for non-debug). I’m having trouble making sense of the dexdump, mainly because of the obfuscation of the optimized build.

 

I’ve attached a no-proguard -dex.xml that contains the entire section for androidx.window package.

 

One thing I noticed is that the class that implements one of the missing interfaces/classes does look different, but I can’t tell if this is relevant or not. Am I looking in the right spot? Maybe I should rerun a build with obfuscation off but shrinking on?

Definitely recommended for this kind of debugging. You can do this with GN arg: enable_proguard_obfuscation=false

[Daniel Libby]

Apologies for the delays, I was out of office, but finally got back to this one.

 

Turning off obfuscation helped me spot the issue. There are classes internal to the library with callbacks that are discovered by reflection at runtime. I had the wrong conceptual model of the ProGuard flags, but after reading the official documentation, keeping those callbacks around makes it so we don’t crash.

 

The warnings still need to be suppressed, which is somewhat strange since they are `interface` not class, but the implemented methods of those interfaces were indeed the ones that were missing.

 

I’ve updated the CL and have added agrieve@ as reviewer.

 

I’m also following up with the support library owners to make sure this is addressed in a future release of the library.

 

Thanks for all your time and guidance!

[Kundan Kale]

I am facing the same issues. Can anybody have a solution for this issue?

using 1.0.0  version of androidx.window:window.

getting below error while building 

java.io.IOException: proguard.ParseException: Expecting type and name instead of just 'setExtensionCallback' before '(' in line 19 of file '/Users/jenkins/.gradle/caches/transforms-2/files-2.1/4737e66a020eb21db6a9393dcbd55c8a/jetified-window-1.0.0/proguard.txt'

[Frédéric ULL]

Hi, the proguard.txt rules of androidx.window:windows:1.0.0 has a syntax error.

This causes ProGuard & DexGuard to fail when parsing the file.

On this commit : https://cs.android.com/androidx/platform/frameworks/support/+/71e9e57d565ec6f99ec5753933d79527e5e98484:window/window/proguard-rules.pro;dlc=ad745501533c7912107e1e1971a695ccf8d1c368

I see that the rules use kotlin like syntax (no return type for Unit) but Proguard & DexGuard require Java syntax.

The valid rules must specify kotlin.Unit as return type of function:

-if class androidx.window.layout.SidecarCompat {

  public kotlin.Unit setExtensionCallback(androidx.window.layout.ExtensionInterfaceCompat$ExtensionCallbackInterface);
}
-keep class androidx.window.layout.SidecarCompat$TranslatingCallback,
androidx.window.layout.SidecarCompat$DistinctSidecarElementCallback {
  public kotlin.Unit onDeviceStateChanged(androidx.window.sidecar.SidecarDeviceState);
  public kotlin.Unit onWindowLayoutChanged(android.os.IBinder, androidx.window.sidecar.SidecarWindowLayoutInfo);
}

[Kundan Kale]

Hi Frédéric ULL 

Thanks for the reply. And sorry for the delayed response from my side. 

I tried your kotlin.Unit solution, still facing the same issue. 

Thanks,

Kundan Kale

[Alessio Bianchi]

Here is a temporary, horrible workaround :D

- download the AAR of androidx.window:window:1.0.0 from the official Google Maven repo: https://maven.google.com/web/index.html?q=window#androidx.window:window:1.0.0

- unzip it

- in the file proguard.txt, replace the rules with the ones suggested by Frédéric ULL

- rezip and rename to .aar, for example: androidx_window_window_1.0.0_patched.aar

- if you directly include androidx.window:window:1.0.0 in your gradle file, remove it

- if androidx.window:window:1.0.0 is included as a transitive dependency, use the following gradle directive to exclude it:

configurations.implementation {

    exclude group: 'androidx.window', module: 'window'
}

- declare our patched AAR as a dependency:

implementation(name: 'androidx_window_window_1.0.0_patched', ext: 'aar')

- be sure to manually declare in your gradle file the transitive dependencies of the original androidx.window:window:1.0.0 (you can examine the POM file on the Maven Google link above)

If someone knows a simpler way of ignoring the bundled proguard rules for a library, I'd be happy to know.

[James Hamilton]

Hi!

For the syntax issue, in ProGuard & DexGuard we've temporarily added an exclusion for `androidx.window` rules and added the rules with return type in the default configurations. For ProGuard, that's in version 7.2.1 and for DexGuard 9.3.2

For future reference, you can also exclude consumer rules as well (since ProGuard 7.2.1 and DexGuard since many versions ago), for other similar problems:

proguard {
    configurations {
        release {
            consumerRuleFilter 'androidx.window:window', 'anotherGroupName:anotherModuleName'
        }
    }
}

For the rule syntax: the return type should be void as opposed kotlin.Unit, since when compiling Kotlin to Java bytecode the kotlin.Unit return type is compiled to void in this case.

It seems that the fix is already in androidx.window but is not yet released: https://android-review.googlesource.com/c/platform/frameworks/support/+/2005153/1/window/window/proguard-rules.pro

For ProGuard bugs, please don't hesitate to open a GitHub issue or for usage questions you can head over to the Guardsquare community where you can get tips and advice on your configuration from our team of engineers and skilled community members.

James

[Onur Koncaoğlu]

Hi James,

I catch the same error with Dexguard 9.3.4 version. Is this temporary exclusion rules for androidx.window exists on 9.3.2 only?

Also I want to ask that, after consumeRuleFilter applied, we have to add correct configs (https://android-review.googlesource.com/c/platform/frameworks/support/+/2005153/1/window/window/proguard-rules.pro) to our rules file right?

Thanks