Status Update
Comments
ch...@google.com <ch...@google.com>
ch...@google.com <ch...@google.com> #2
I have not seen any information about it so just asking here to avoid opening another issue. It also seems that when generating APK with alpha 8 the dex is no more compressed in the APK and stored as is. Leading to way bigger APKs.
While this is not an issue when distributing via Play Store, this could have impact for all the other distribution channels. Is this a normal wanted change and we'll have to deal with it? Or is there some new parameter to control this?
ap...@google.com <ap...@google.com> #3
I can reproduce the originally reported issue of missing Baseline Profiles with AGP 8.0.0-alpha08.
To verify, check out the
ap...@google.com <ap...@google.com> #5
Created
ap...@google.com <ap...@google.com> #6
the location of the baseline profile has changed, it is now in dexopt folder instead of com.android.tools.build.profiles
please file a different bug for other issues so we can assign them correctly for each issue.
ap...@google.com <ap...@google.com> #7
There is no dexopt or any baseline profile related file in the generated aab. There is also nothing related to baseline profile in APK generated with AGP 8.0.
Can you please verify, keep the issue opened and provide a solution?
ap...@google.com <ap...@google.com> #8
As a side note I do use:
android.experimental.enableNewResourceShrinker.preciseShrinking=true
And
<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:tools="http://schemas.android.com/tools"
tools:shrinkMode="strict" />
So maybe depending on when the baseline is packaged it's removed, but in all case it's not working currently so not really WAI.
ap...@google.com <ap...@google.com> #9
It's not working either for me. And I don't have android.experimental.enableNewResourceShrinker.preciseShrinking=true
and tools:shrinkMode='strict'
ap...@google.com <ap...@google.com> #10
Still happening with AGP 8.0.0-alpha09. Release build apk don't include baseline profile in assets/dexopt/
ap...@google.com <ap...@google.com> #11
When they quickly close like that without checking on most part of the tracker anything written after is just plain ignored..
Need to reopen an issue, since no access to proper category hope again that triage put it in the proper place then hope that this time it's properly read.
If only all the parts could be like the R8/D8 part of this issue tracker.
ap...@google.com <ap...@google.com> #12
Scott, can you have a look if modifying an app according to
ap...@google.com <ap...@google.com> #13
I'm not able to reproduce.
Ben, the link to the repro project from
ap...@google.com <ap...@google.com> #14
Is there any logs I can provide from the build to help figure out?
ap...@google.com <ap...@google.com> #15
For the record also tested with A9 and there's the result on Windows.
Image is content of the aab (res and BUNDLE-METADATA)
And the result of a search on all the app folder including all the build dirs after the build
PS D:\_Gradle\Symfonik> Get-Childitem -Include *baseline* -Recurse
Directory: D:\_Gradle\Symfonik\app\src\main
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 29/11/2022 10:58 2114655 baseline-prof.txt
Directory: D:\_Gradle\Symfonik\benchmark\src\main\java\app\symfonik\benchmark
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 29/11/2022 10:48 baselineprofile
Directory: D:\_Gradle\Symfonik\benchmark\src\main\java\app\symfonik\benchmark\baselineprofile
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 29/11/2022 10:48 1231 BaselineProfileGenerator.kt
Reverting to A7 generates an aab that is 15k larger (the size of the baseline)
And the search after the build gives:
PS D:\_Gradle\Symfonik> Get-Childitem -Include *baseline* -Recurse
Directory: D:\_Gradle\Symfonik\app\build\intermediates\binary_art_profile\release
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 02/12/2022 20:17 14796 baseline.prof
Directory: D:\_Gradle\Symfonik\app\build\intermediates\binary_art_profile_metadata\release
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 02/12/2022 20:17 1805 baseline.profm
Directory: D:\_Gradle\Symfonik\app\build\intermediates\merged_art_profile\release
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 02/12/2022 20:12 2303810 baseline-prof.txt
Directory: D:\_Gradle\Symfonik\app\src\main
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 29/11/2022 10:58 2114655 baseline-prof.txt
Directory: D:\_Gradle\Symfonik\benchmark\src\main\java\app\symfonik\benchmark
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 29/11/2022 10:48 baselineprofile
Directory: D:\_Gradle\Symfonik\benchmark\src\main\java\app\symfonik\benchmark\baselineprofile
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 29/11/2022 10:48 1231 BaselineProfileGenerator.kt
So the files are properly generated in binary_art_profile
for A7 and completely missing in A8 / A9. This does not sound like a packaging issue (Same behavior without the options from #8) but more a missing generation step.
This is a full compose app, no jetifier, minsdk 28, no png generation, ultra optimized everywhere I can, so maybe the build step depends on a step that is missing now?
ap...@google.com <ap...@google.com> #16
Thanks. I'm able to repro now with the correct link
ch...@google.com <ch...@google.com> #17
It looks like this was caused by Change-Id: I68ab3a6f342327cfb4c5477f85941fa3a6434a81. When I revert that change, the issue goes away. Working on a fix...
Description
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 here .
This project contains a copy of the BitCode class that's generated by Renderscript
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.