I'm pretty sure that works out of the box now? I swear I saw a lint error from a library's lint rule in AS the other day. Will confirm tomorrow.
On Thu, Jan 14, 2016 at 8:23 PM Jun <[email protected]> wrote: > Hi Tor, > > Are there any instructions on how to add custom lint rules to Android > Studio 1.4+ where it'd underline problematic areas within the IDE? I'm > unable to figure it out even when looking at the Analyze menu since I see > no signs of any of the custom rules' existence within the menu. > > Thanks! > > > On Monday, July 20, 2015 at 8:10:32 AM UTC-7, Tor Norbye wrote: >> >> 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. > -- 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.
