Lint intermediate files is breaking gradle remote cache - lint-definite.xml [349534809]

Fixed

Bug

Status Update

No update yet.

Description

eb...@netflix.com

created issue #1

Jun 26, 2024 01:52PM

DESCRIBE THE ISSUE IN DETAIL:

Lint intermediate files is breaking gradle remote cache because the file ordering in build/intermediates/lint_partial_results/debug/lintAnalyzeDebug/out/lint-definite.xml isn't deterministic (Linux vs MacOS). We noticed it on the IconLocation lint rule.

STEPS TO REPRODUCE:

Build a project with 2 lint warnings on the IconLocation rule
Execute lintDebug on a Mac
Execute lintDebug on a Linux
Compare the files lint-definite.xml from build/intermediates/lint_partial_results/debug/lintAnalyzeDebug/out. In our experience the 2 warnings are swapped.

FILE CONTENT ON MAC

<incident
    id="IconLocation"
    severity="warning"
    message="Found bitmap drawable `res/drawable/internal_hk_modal_preview_asset_1.webp` in densityless folder">
    <location
        file="${:hk-components*debug*MAIN*sourceProvider*0*resDir*0}/drawable/internal_hk_modal_preview_asset_1.webp"/>
</incident>

<incident
    id="IconLocation"
    severity="warning"
    message="Found bitmap drawable `res/drawable/internal_hk_modal_asset_wide_1.webp` in densityless folder">
    <location
        file="${:hk-components*debug*MAIN*sourceProvider*0*resDir*0}/drawable/internal_hk_modal_asset_wide_1.webp"/>
</incident>

FILE CONTENT ON LINUS

<incident
    id="IconLocation"
    severity="warning"
    message="Found bitmap drawable `res/drawable/internal_hk_modal_asset_wide_1.webp` in densityless folder">
    <location
        file="${:hk-components*debug*MAIN*sourceProvider*0*resDir*0}/drawable/internal_hk_modal_asset_wide_1.webp"/>
</incident>

<incident
    id="IconLocation"
    severity="warning"
    message="Found bitmap drawable `res/drawable/internal_hk_modal_preview_asset_1.webp` in densityless folder">
    <location
        file="${:hk-components*debug*MAIN*sourceProvider*0*resDir*0}/drawable/internal_hk_modal_preview_asset_1.webp"/>
</incident>

RESULT

This break gradle remote build cache for CI vs Mac scenario.

IMPORTANT: Please read https://developer.android.com/studio/report-bugs.html carefully and supply all required information.

Studio Build: Android Studio Koala Feature Drop | 2024.1.2 Canary 7 (irrelevant since happen in CI too)
Version of Gradle Plugin: AGP 8.5.0
Version of Gradle: Gradle 8.8
Version of Java: 17.0.11-zulu
OS: Mac Sonoma 14.4.1 (23E224) vs Linux 6.5.0-1020-aws (amd64)

Screenshot 2024-06-26 at 6.21.38 AM.png

17 KB

View

Download

Comments

rp...@google.com <rp...@google.com> Jun 26, 2024 01:59PM

Assigned to an...@google.com.

pa...@google.com <pa...@google.com> Jun 26, 2024 04:01PM

Status: New

tn...@google.com <tn...@google.com> Jul 2, 2024 11:43PM

Assigned to tn...@google.com.

pa...@google.com <pa...@google.com> #2Jul 3, 2024 10:45AM

It seems the print is benign so I'll remove it; Could be worth it to find out how the message carrying information about "cb 0" (0 is not a valid color buffer handle) ever arrives to that line though

Message last modified on Jul 3, 2024 10:47AM

tn...@google.com <tn...@google.com> #3Jul 8, 2024 02:45PM

I don't think we should necessarily remove these messages from the emulator code since at least some of them may point to real problems. I'm going to make sure that they are not treated as errors in Studio.

pa...@google.com <pa...@google.com> Jul 8, 2024 05:49PM

Reassigned to pa...@google.com.

pa...@google.com <pa...@google.com> #4Jul 18, 2024 01:12PM

Marked as fixed.

I agree with Sergey -- while I think it's fine to remove some logging messages that aren't necessary, the root problem here is that Studio shows everything emitted as if they are errors, with one notification bubble per message. We don't do that for other tools that Studio launches, and in particular, this isn't specific to the "cb 0" message I showed here; there were earlier (different) error messages during the boot as well.

an...@google.com <an...@google.com> #5Jul 22, 2024 04:32PM

This behavior was requested specifically by the emulator team (vharron@ iirc, so at least 3-4 years ago). Let me see if I have any more details on why this was requested.