AGP 8.3.0-alpha02 cannot install release profiles on Windows hosts [299506174]

Fixed

Bug

Status Update

No update yet.

Description

ch...@gmail.com

created issue #1

Sep 8, 2023 04:26AM

####################################################

Please provide all of the following information, otherwise we may not be able to route your bug report.

####################################################

Describe the bug or issue that you're seeing.

Change I8d90b4becee1dcc29c5467439b5cf51eed4a20c2 caused a breakage on Windows hosts per this line.

On Windows, the generated file that's tested here is broken, because the file paths generate as 0\.dm, since \ is the Window path separator.

Per Oracle documentation, here, \ is reserved for newline, and in order to parse a real \, you need to escape it by doubling it.

The backslash character must be escaped as a double backslash. For example:

path=c:\docs\doc1

Attach log files from Android Studio
2A. In the IDE, select the Help..Collect Logs and Diagnostic Data menu option.
2B. Create a diagnostic report and save it to your local computer.
2C. Attach the report to this bug using the Add attachments button.

The above seems pretty clear cut, so this doesn't seem necessary.

If you know what they are, write the steps to reproduce:

3A. Use AGP 8.3.0-alpha02 to build an app on a Windows host
3B. Add a signing keystore for the release variant (can just be the debug keystore) to unlock the installRelease task
3C. ./gradlew :app:installRelease
3D. Execution failed for task ':app:installRelease'. > java.util.concurrent.ExecutionException: java.nio.file.NoSuchFileException: ...\app\build\intermediates\dex_metadata_directory\release\0.dm

In addition to logs, please attach a screenshot or recording that illustrates the problem.

For more information on how to get your bug routed quickly, see https://developer.android.com/studio/report-bugs.html

Build: AI-232.9559.62.2321.10749089, 202308312303

AI-232.9559.62.2321.10749089, JRE 17.0.8+0--10699129x64 JetBrains s.r.o., OS Windows 11(amd64) v10.0 , screens 3440.0x1440.0, 2400.0x1350.0

AS: Iguana | 2023.2.1 Canary 2
Kotlin plugin: 232-1.9.0-release-358-AS9559.62.2321.10749089
Android Gradle Plugin: 8.3.0-alpha02
Gradle: 8.3
Gradle JDK: JetBrains Runtime version 17.0.8
NDK: from local.properties: (not specified), latest from SDK: 25.1.8937393
CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)

Comments

er...@google.com <er...@google.com> Sep 8, 2023 09:55PM

Assigned to an...@google.com.

je...@google.com <je...@google.com> Sep 11, 2023 04:03PM

Reassigned to mi...@google.com.

mi...@google.com <mi...@google.com> #2Sep 13, 2023 08:10PM

I can reproduce this (thanks for the repro project!)

It looks like the problem is that the desugared api list from r8 contains this entry:

java/util/Collection#removeIf(Ljava/util/function/Predicate;)Z

but the bytecode here doesn't match -- it's java/util/ArrayList. Collection isn't a directly implemented interface or a direct super class, it's an interface on the super super class. The most efficient thing runtime wise would be for the signature list to inline this method on all implemented subclasses. But I should probably at least for now go and make the desugared API lookup do something similar to what it does for API lookup -- search through all super classes and interfaces as well. This isn't a new problem, so I'm very surprised this hasn't come up before (or it has, and I've forgotten).

ch...@gmail.com <ch...@gmail.com> #3Sep 13, 2023 08:46PM

(I have a pending CL that was working to improve the handling of fields now that r8 handles desugaring fields, I'll try to dust that off and combine the fix in there.)

mi...@google.com <mi...@google.com> Sep 19, 2023 02:01AM

Marked as fixed.

an...@google.com <an...@google.com> #4Sep 21, 2023 09:04PM

I went to implement this, and hooked up inheritance search when analyzing the source file containing the call.

However, lint also handles the case where the library being analyzed is not using core library desugaring (for example, it may be a plain Java library). But when that library is consumed in a downstream app module, where library desugaring is turned on, lint then processes the partial results from the library and filters each violation through the desugaring allowlist.

At this point, it's tricky to do the inheritance search -- this happens when we no longer have a compilation environment and can do class inheritance lookups. So there are three possible solutions.

First, we pay the cost up front -- even when you're not using core library desugaring, we record whether the method is potentially library desugared if turned on. (This is also tricky because at this point we don't know which exact desugaring library version is used, which determines the exact list of APIs).

Or, more expensively, for every API violation of this type we store all the potential super class and interface names for each result...

Or, we handle this in the code which generates the desugaring API list, inlining all subclasses affected. This could be quite a long list, but on the other hand this list is really only intended to be machine readable.

Issue 299506174