IssueTracker

Thanks!

Other notes: I think this is technically a regression, because Lint checks are prepared during generateDebugSources and that used to run during Gradle sync(?)

comment #11 Lint IDE integration is broken in Canary 8, see https://issuetracker.google.com/155315443#comment5

In 4.1, "Make Project" should now again make the lint checks and make them available to Lint. This is because we stop "preparing" them (which is fancy word for moving them somewhere to be consumed).

However, deploying the app will not build the lint checks. We want this action to be exclusively focused on deploying the app and we don't want to do extra build actions.

Right now you can manually trigger building the lint checks via the Build > Run Generate Source Gradle tasks menu action. This is not a great place for it but it's a good temp work around. In 4.2 we will create a custom action to rebuild just the lint checks. I have created Issue 157134768 to track this.

(Note that you can assign a keyboard shortcut to that action.)

Xav's fixes will be included in 4.1 Canary 11 (canary 9 is still the current version; we're testing canary 10 at the moment but these fixes went in after the cutoff for that build).

Yes there will be some extra steps.

We could do a post sync/project open action to build theses in the background, but it's going to be hard to fully automate this I think. It would be nice to just rebuild them as they change, but I think we really don't want to make building them part of the deploy build.

Maybe a notification bubble that lint checks seems to be out of sync and a nudge to rebuild them? Tor, what do you think?

IMO, readying Lint checks seems sensible to do upon sync. It should be fast since building those modules will often be up-to-date, and syncing is already what many people consider to be the "make my IDE understand the project" button, the IDE's behavior is directly affected by lint checks.

How do you actually run Lint? I'm guessing you don't rely on lint highlights in the editor.

We should definitively hook into the Analyze > Inspect Code... action (And others like Run Inspection by Name...) and force a build before running this. I've filed Issue 157146850 to track this.

Comment #21: The issue is that we don't want to do a build during sync. There are edge cases that makes it difficult to handle (And this is the reason we stopped doing source generation during sync). This means we need to do a build after sync which means reconfiguring the projects and resolving (some) dependencies. This may become really fast with Gradle Configuration Caching (formerly Instant Execution) but this is not there yet.

ok, so my comment about also building before running full code analysis is not helpful.

I just realized that we also run source generation about a clean (Build > Clean Project) so we should add building lint checks as part of that action as well. I'm amended Issue 157134768 for this.

We will discuss how we can nudge users to rebuild lint checks when something happens. The IDE keeps track of file states, so as long as we can internal flag these projects as producer of lint checks (because there are referenced by another project via lintChecks) this should be doable.

The reason timber works is that lint checks that are associated with AARs should always be picked up no matter what -- they don't require any "building" from AGP's perspective. They're just there next to the other library resources -- classes.jar, res, lint.jar, etc. Locally bundled rules (as source code) are different, and require work to get built and wired in.

Xav, do I understand correctly that the problem here is with projects that use the "lintChecks" and/or "lintPublish" configurations? And if that's the case, we see those as part of the sync results, right? If so, I think it should be straightforward to trigger a generate sources build right there as part of sync. Yes, that will make sync slower, but I don't think anyone who has a setup which includes locally built lint rules would NOT want those built at least once.

Also, is there some easy workaround for Colton here? Could he just make the assembleDebug task depend on this generate task (what is the task name?). If so, then pressing Ctrl/Cmd - F9 in the IDE would not just build the the code for the app but also the lint rules. Once we have Gradle instant execution on there would be almost zero overhead for this, right?

Yes the problem is only for sub-projects that contribute lint checks. As you mention, AAR-provided lint checks are not impacted.

Right now the model does not contain the projects that contribute lint checks, only their jar output location, so we need to change this (Issue 157134768 which is about having a custom build task for them)

I've filed Issue 157148185 to track a nudge mechanism when a lint checks source code is changed somehow.

In the mean time, yes you can manually make the task depend on it. In 4.1 (canary 11) we've introduced a new task called compileLintChecks, so you can make your assembleDebug depend on it. This is not great as it'll slow down your deploy build but it's a good workaround for now.

My app includes lint checks that come from an external jar dependency and we also hit this issue. The lint checks are not created in a subproject and not do not come from an AAR.

E.g. lintChecks 'com.custom.lint:checks:1.0.0

We should also make sure these are always picked up by the IDE. I don't think https://issuetracker.google.com/issues/157148185 covers this use case.

This should work in canary 11. Please do check and let me know if it does not work.

Making a dependency on prepareLintJar would work. but this task disappeared in 4.1 so it'll fail to build/sync once you update.

Xav said it should be fixed in 4.1 canary 11 so that means it should be in 4.1 beta as well; is it not working for you?

We are looking at better ways to integrate lint checks into the flow.

There are currently two issues that track various works

• Issue 157134768 - New Build action to build lint checks sub-projects
• Issue 157148185 - Monitor changes to Custom lint check source code and nudge user to rebuild them

Building them automatically during a deployment is something we can look into. We are a bit wary of doing any extra work during deployment since we want this to be as fast as possible but it's possible we will enable this anyway (especially once we have file watching). I've filed Issue 158750975 to track this.

Can you say more about (2) -- why do you clean consistently throughout the day? Clean deletes all the built artifacts. That would include any locally built lint rules too, right?

In my multimodule project I tried both options:

1. :app (lintCheck(":checks"))
2. :app (implementation(":checks-publisher); :checks-publisher (lintPublish(":checks")

Another words I tried to add checks directly to the app and through the library module. Both options lead to my check fire during the ./gradlew :app:lint task execution. However neither of the implementations made the highlighting in Android Studio work.

My Android Studio version is 4.1.3, Gradle 6.8.2, AGP 4.0.1, Lint 27.0.1.

However, if I apply the same versions to this project - https://github.com/googlesamples/android-custom-lint-rules - the same rules within it work fine.