> > Hi! > > My team has been working on integration some custom rules in our build > process, and we have a few questions: > > - Is it possible to enable custom rules to run within Android Studio and > highlight errors like built-in rules do? >
Yes -- but only in Studio 1.4 which we'll put in canary as soon as 1.3 goes stable (we're at RC3 now.) The reason custom lint rules do not show up in the IDE is that the IDE, what you see running are really IntelliJ inspections. We wrap each lint rule as an IDE inspection. And IDE inspections have to be registered *statically* (in a plugin XML registration file). For all the builtin lint rules, we've done this. But we recently fixed this: https://android-review.googlesource.com/#/c/158054/ https://android-review.googlesource.com/#/c/157894/ Note that there is one limitation though: Normally, in the Analyze window, you get to see the full explanation text for the issue. That doesn't work for third party rules. For custom rules, these will all be using a common category and explanation (Third party Inspection or something like that), and the explanation says that to see each full description to run Gradle's lint target to get the HTML report with full explanations. So, it's really important that the error message itself be pretty descriptive. - Is it possible (and practical!) to run Android Lint on non Android java > projects? > It probably doesn't work, since there are a number of assumptions for example that a manifest exist. Note however that lint *should* handle the case where you are using a non-Android library module. It will still look for problems in that non-Android module. So perhaps you could just create a dummy Android app module referencing the non-Android library for this case? Note however that lint *doesn't* try to duplicate all the "general" programming checks done by most IDEs -- assignment in conditional, etc. Instead it focuses exclusively on flagging just Android-specific issues. The idea was that IDEs and CI plugins already do a pretty good job checking for general Java issues so let's not (a) duplicate effort and (b) have the user end up with 2 sets of error messages for each error. - We are generating our custom lint jar as part of the build, and declare a > dependent task to all lint tasks that makes it available to the lint tool. > ANDROID_LINT_JARS is not convenient for us, since we can't modify an env > variable from within the process, and the home directory won't work in > shared servers. Copying the jar file into ${buildDir}/lint/lint.jar works, > but it feels hacky. What is your recommendation? Also, would it be possible > to add a list of custom rule jar files to lintOptions? > The best way for this to work is for you to inject your custom rules lint jars by using the exact name "lint.jar", and then packaging this inside a library AAR file that your project depends on. When lint runs on your project, it gathers custom rules provided for any libraries your project is using, if those libraries provide custom rules (and the way to do that is to include them in the AAR payload using that exact location and name inside the AAR file (which is just a .zip). Longer term we'd like to make it easy to create lint custom rules by just having a new lint source set in your project (next to src/main/java, src/main/test, etc we'd have src/main/lint), and those lint sources would automatically be compiled with the lint API dependencies, and packaged into the AAR (or if in an app module, be used when lintint this project.) But note that none of this is automated yet; primarily because the lint API is not yet stable, and will probably change a bit more before we get there. > - I couldn't find a way to pass configuration parameters for my rules > through the Lint options and I have been using Java system properties, but > it feels ugly. It would be great to be able to configure rules in the lint > configuration file. What is your recommendation for passing configuration > into custom lint rules? > I agree, it's ugly, but there isn't a better way to do it yet. > - Lint tries to load rules from every jar file in the lint directory, > making it impossible for me to add dependent jar files. Is there a way to > use custom rule jar files that have external dependencies? > Right now you'll need to use jarjar to include your dependencies (other than lint's built-in dependencies) with your custom rule inside the same jar. That's necessary because there isn't a way to describe what jars it needs and have all the different lint-embedding contexts (studio/intellij, gradle, command line script, eclipse) find and load it with a suitable class loader. > - Your sample code doesn't include support for unit tests, which would be > really useful for debugging rules. How can I set them up? > There's a lint-tests AAR artifact now which makes this better, but sadly it depends on another library, testutils, which wasn't published right, so it doesn't work at the moment. As soon as that's republished (hopefully as part of the 1.3 push) I'll update the sample which makes it trivial to unit test lint checks. Also, I have a couple of minor questions about writing the rules themselves: > > - ResolvedClass has getMethods() but not getFields() (which would be > useful, for example, to validate immutability). Is that an intentional > omission? > No, that was not intentional! I've added it here: https://android-review.googlesource.com/160382 https://android-review.googlesource.com/160391 > - applicableSuperClasses() can't be used with generic base classes, since > the Java visitor seems to check against the full signature (which includes > type parameters). We are working around this by selecting all classes > instead and checking manually, but it seems wasteful. Would it make sense > for the visitor to look up the class name as well? > Yes - that was not intentional, it should be using the raw type there. Fixed by https://android-review.googlesource.com/160420 . > - Super minor nit: Lint only admits "//noinspection" to disable issues, > while AS will also take "// noinspection". We've been using the latter, and > it took me a while to figure out the problem! > Interesting - I think it only used to work for the //noinspection version. I guess we should make it a bit more flexible. > Sorry about the long email! > No problem, thanks for the feedback. -- Tor -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
