IssueTracker

Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Thanks for reporting this issue.

COARSE_LOCATION typically takes location information from the nearby cell tower. If many users are near the same cell tower, each of those users will be given the same position. Using a FINE position will give much more detailed information.

Also, in certain areas, for privacy reasons, a less-exact location will be given, and that less-exact location might be identical for many users. Again, a fine-location configuration will return more precise location data.

We believe with reference to the above comment, your query has been answered, hence closing the bug. Please feel free to re-open the issue in the future if desired.

Thanks for the info.

I think the main underlying problem here is that the lint analysis task caches its output even when there is a LintError, and I think the right fix is for AGP to throw an exception from the lint analysis task when there is a LintError... This was discussed previously in the context of Issue 297095583, and it was implemented in the case of OOMs; previously we decided not to throw an exception in cases other than OOMs, but we didn't consider the case of rare exceptions getting cached as LintErrors in the build cache.

I think in your case, there is occasionally a NoSuchFileException during lint analysis, and then the corresponding LintError keeps showing up in subsequent builds because it gets cached in the build cache.

As far as what's causing the LintError, I wonder if it's because of "gradle-home-cache-cleanup: true" from #8... I'm not sure how that's implemented, but if it just cleans the Gradle home caches after each build, then it could cause that NoSuchFileException if there is another build running simultaneously on the same machine.

Re: #9, I don't think the Gradle cache directory path is causing the issue because that file is not consumed by the lint analysis task.

Regarding gradle-home-cache-cleanup: true I can say with confidence that it has nothing to do with the issue, as it was occurring for a long time before we started using this feature. The feature itself cleans Gradle home artifacts that were not used during build before saving the cache to Github Actions cache.

I think the right fix is for AGP to throw an exception from the lint analysis task when there is a LintError

This has been implemented and will be included in AGP 8.7.0-alpha08.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Ladybug | 2024.2.1 Canary 8
• Android Gradle Plugin 8.7.0-alpha08

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Further fixes for this issue are now available in:

• Android Studio Ladybug | 2024.2.1 Canary 9
• Android Gradle Plugin 8.7.0-alpha09

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

For the record, I think this has now removed the ability:

• to observe LintError in the report XML/HTML/TXT/SARIF (i.e. no tooling can detect it), report task doesn't run because dependency fails.
  • Knock-on: if there's a LintError, it has to be fixed BEFORE we can see and fix any other problems, even if there's just one rogue rule.
  • Knock-on: can't see the formatted clear stack trace, LINT_PRINT_STACKTRACE=true has no effect any more
  • Knock-on: users have to read the logs of CI to understand the failure, even when there are artifacts/PR annotations are used.
• to suppress LintError in lint.xml (e.g. a check that only fails in one specific case, and otherwise useful)
• to baseline LintErrors (e.g. a check that only fails in one specific case, and otherwise useful)

Reported https://issuetracker.google.com/issues/381887323 to track.