Minifying Renderscript code: huge performance drop when upgrading AGP from 7.3.1 to 7.4.0 [267990059]

Verified

Bug

Status Update

No update yet.

Description

bv...@gmail.com

created issue #1

Feb 6, 2023 09:26AM

We're using Renderscript in one of our projects and noticed that our build times for a minified release build went up by a factor of 3 after upgrading the Android Gradle Plugin from 7.3.1 to 7.4.0: from 17 minutes to 53 minutes.

For each Renderscript file, two files are generated: a ScriptC_$name file which contains bridging functions, and a $nameBitCode file which contains a few huge byte arrays that are compiled into GPU code on the user's phone. R8 takes a very long time to process this last file.

I made a sample project here: https://github.com/bvschaik/r8-renderscript-minify-issue
This project contains a copy of the BitCode class that's generated by Renderscript here.

Using AGP 7.4.0 (uses R8 4.0.48), running assembleRelease on this project takes almost 4 minutes, with 3m40s taken up by the minifyReleaseWithR8 task.

Downgrading AGP to 7.3.1 (uses R8 3.3.83), the minifyReleaseWithR8 "only" takes 1m10s, which is still quite long for processing some static byte arrays.

For now we're forcing R8 to the last available 3.3 version to get back to acceptable build times.

What could cause this increase in build times?
Why is R8 spending so much time on relatively simple code?
What can we do to tell R8 "don't change anything in this file"? I tried various -keep rules but it didn't make a difference.

Comments

ch...@google.com <ch...@google.com> Feb 6, 2023 09:35AM

Reassigned to ch...@google.com.

ch...@google.com <ch...@google.com> #2Feb 7, 2023 07:57AM

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

ap...@google.com <ap...@google.com> #3Feb 8, 2023 11:31AM

One more detail, Data Layer event calls from the watch to the phone (running Android 13) do work on if the listener is in an Activity or Fragment.

ap...@google.com <ap...@google.com> #4Feb 8, 2023 02:53PM

Also, I'm seeing this message in the Logcat:

"2022-06-12 18:47:15.156 1841-4562/? W/PackageManager: Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER"

ap...@google.com <ap...@google.com> #5Feb 8, 2023 03:16PM

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

ap...@google.com <ap...@google.com> #6Feb 9, 2023 10:06AM

+1, can confirm it doesn't work on Android 13:=

2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver }
2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Access blocked: ComponentInfo{xxx/xxx.WatchMessageReceiver}
2022-07-15 11:26:15.023   589-5347  ActivityManager         pid-589                              W  Unable to start service Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver } U=0: not found

ap...@google.com <ap...@google.com> #7Feb 9, 2023 10:27AM

Note that I've been able to make it work by:

Adding <action android:name="com.google.android.gms.wearable.BIND_LISTENER" /> in the intent filter
Removing <data android:scheme="wear" android:host="*" />

But I feel like this is not something we should do

ap...@google.com <ap...@google.com> #8Feb 9, 2023 10:27AM

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

ap...@google.com <ap...@google.com> #9Feb 9, 2023 10:27AM

If you're not targeting API 33 you're not affected by the bug. So it's a big bug, and yes we of course expected more from Google, but you can always target the api level later when it's fixed.

But I agree this is kind of desperating that more than 1.5 month after the first report nothing has changed.

ap...@google.com <ap...@google.com> #10Feb 9, 2023 10:27AM

As an interim update on this issue: we've been already working on the fix that should be available by Android 13 release. The fix requires thorough testing, I'll keep this bug updated as soon as we have more to share. Thanks!

ap...@google.com <ap...@google.com> #11Feb 9, 2023 10:27AM

@comment#9 The Play Store will eventually require targeting API 33, then 34, etc, so accepting this regression in a customer release would be a time ticking bomb for Wear OS apps.

Thank you for the update @comment#10

ap...@google.com <ap...@google.com> #12Feb 9, 2023 10:30AM

Hey @

comment#10

, do you have any news to share?

Android 13 is out today and we still have no patch unlike what you said a month ago

ap...@google.com <ap...@google.com> #13Feb 9, 2023 10:30AM

I have no words for this. Android 13 is labeled "stable" but the Wearable API just doesn't work. Can't this issue be given higher priority? If you want to push WearOS you need to make sure it works normally.

ap...@google.com <ap...@google.com> #14Feb 9, 2023 10:30AM

This issues has been already given high priority (updated external priority on this bug to reflect internal status). The fix is on the way and going through the final rounds of testing, so the roll out is slated to next couple of weeks.

To reiterate what have been mentioned earlier on this bug: this issue affects only apps targeting Android 13, so the apps won't break unless you bump targetSDK version to 33. In case if you want to start working on app compatibility for Android 13 behaviour changes, you could use Compatibility framework to toggle on/off the changes individually for isolated testing.

ap...@google.com <ap...@google.com> #15Feb 9, 2023 10:30AM

comment#14

as much as I agree that is not a blocking bug, you need to understand that:
- The report is 2 months old
- Google chose to release Android 13 with that bug
- There's no mention of this bug on the documentation so you can totally bump your targetSdk without noticing it

So thank you guys for working on this but it's still not a valid excuse for taking that long for such an important issue. Now that being said, let us know when a fix is available

ap...@google.com <ap...@google.com> #16Feb 9, 2023 10:30AM

Google will come through. They always do!

ch...@google.com <ch...@google.com> #17Feb 9, 2023 10:34AM

Verified by ch...@google.com.

That must be some really intense testing as we are 10 days later and still nothing on sight. I don't want to be a P2 issue if that's what a P1 is.

bv...@gmail.com <bv...@gmail.com> #18Feb 9, 2023 12:15PM

Is there an update on by when can we expect a fix for this? We are blocked on the app release which is targeting Android 13. We can't roll out if it doesn't support wear os app.

ch...@google.com <ch...@google.com> #19Feb 9, 2023 02:24PM

@Google Any updates here?