Lint generally doesn't report errors it encounters in libraries. There are very exceptions to this; invalid package is the only one I can think of. The reason there is that you typically don't run into invalid package in your own code (you're compiling against android.jar), but if you grab a random .jar from somewhere, which may not be a proper Android library, you may end up calling code which relies on parts of APIs that are not part of Android. For that reason, that specific check looks at the classes found in library .jar files.
I'm not sure what the best way to fix this is. I've been thinking about adding more metadata to lint rules, such that you can have parameters used by the checks, as part of your android.lintOptions configuration data. This might be better than a lint.xml in this case. Let me think about it. (I've also been thinking of just whitelisting some known popular cases; for example, several people have been trying to suppress annotations classes used by butterknife. I was thinking I should just whitelist those specifically.) On Thu, Apr 3, 2014 at 5:05 AM, Daniel Lew <[email protected]> wrote: > Hello, > Someone just ran into this problem in a library I wrote: > https://github.com/dlew/joda-time-android/issues/6 > > IMO, the most proper solution is proguard to remove the offending classes. > However, it does make me curious if it's possible to include a lint.xml in > an AAR for known problems that should be ignored. > > -Daniel > > -- > 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.
