"Lint fails with 'Obsolete custom lint check' " resurfacing

[tir38]

Is it possible that latest AGP is triggering #284 again? On com.android.tools.build:gradle:3.3.0-alpha04:

timber-4.7.1.aar/.../lint.jar: Lint found an issue registry (timber.lint.TimberIssueRegistry) which is older than the current API level; these checks may not work correctly.

[JakeWharton]

Tor told me how to fix this a couple months ago but I forget what it was. I think there's a second callback we need to override.

[tnorbye]

Override these two attributes in your IssueRegistry then recompile (note that in the next 3.3 canary I've bumped the API level for 3.3 again):

/**
 * The Lint API version this issue registry's checks were compiled.
 * You should return [CURRENT_API].
 */
open val api: Int = -1

/**
 * The minimum API version this issue registry works with. Normally the
 * same as [api], but if you have tested it with older version and it
 * works, you can return that level.
 */
open val minApi: Int
    get() {
        return api
    }

From Java this would look like:
@OverRide
public int getApi() {
return com.android.tools.lint.detector.api.ApiKt.CURRENT_API;
}

@Override
public int getMinApi() {
    return 1; // Tested with 3.1 and above - see ApiKt for constants.
}

[egek92]

@tnorbye this issue exist in 26.3.0-alpha12

[jakubvimn]

@tnorbye Could you make a pull request with your change?

[ovestoerholt]

Present in com.android.tools.build:gradle:3.6.0-beta03

[vmadalin]

Present in com.android.tools.build:gradle:3.6.0-beta03

Also present on com.android.tools.build:gradle:4.0.0-alpha06

[drindt]

Also present on com.android.tools.build:gradle:4.0.0-alpha06

Also present on com.android.tools.build:gradle:4.0.1

[batadamnjanovic]

Also present on com.android.tools.build:gradle:4.1.1
Gradle 6.5

../../../../../../../../.gradle/caches/transforms-2/files-2.1/bd95de4fc12c777c78ecb9bb730027e3/jetified-timber-4.7.1/jars/lint.jar: 
Lint found an issue registry (timber.lint.TimberIssueRegistry) which is older than the current API level; these checks may not work correctly.

Recompile the checks against the latest version. Custom check API version is 1 (3.1), current lint API level is 8 (4.1+)

[tnorbye]

FYI -- we're working on a facility to make this problem go away in 99.9% of cases (and in the remaining cases the lint check doesn't work so has to be disabled).

It's not checked in yet but it's planned for 7.0/AF; here's the commit message (pending code review):

181271645: Automatic verification of 3rd party lint.jar files

When lint finds lint.jar files associated with a library, it will load
them, and compare the version of the lint API the lint checks were
compiled with the current API.  If the lint check was compiled against
an earlier version of lint (which is likely, since we release new
versions of lint multiple times per year, and once a library with lint
check is stable, it may be used for a long time), then lint issues a
warning that this lint check has not been tested with the new API, and
may therefore not work correctly.

That's true, but in 99.9% of cases, not an issue; most lint checks use a
pretty small part of the API surface which has not changed and probably
won't for the foreseeable future.

This CL improves this situation. If the API is older than the current
API version, it will run the jar file through a bytecode verifier,
which looks at all the Lint API usages, and accesses those API
references via reflection to confirm that the signatures are the same
now as they were when the lint check was compiled.

For API compatibility purposes, this isn't just checking lint's own API,
but key APIs that it also depends on that changes regularly, such as
UAST and PSI, but not APIs like org.w3c.dom or org.xmlpull.

This change also makes lint handle *future* versions of lint jars as
well (lint.jars compiled against a more recent version of the API than
the older version of lint currently trying to load the lint jar for the
library). It performs the same bytecode checks, but issues a different
warning and recommendation.

At first I thought we should perform this verification only once per jar
and store the result persistently in lint's cache. However, it turns out
that this verification is *very* fast, so that's simply not necessary.

I downloaded all AAR libraries from maven.google.com, found all the
lint.jar files, and ran the verifier on them. There was only a single
library using an incompatible version (which not the current version
of the library):
    androidx.activity:activity:1.2.0-alpha07: Not compatible
      (com/android/tools/lint/detector/api/Project#getCurrentVariant())

This is automated by the test LintJarVerifierTest#checkMavenJars (off by
default). After finding all the lint jars, it verifies all of them,
which takes < 1s, or just 8ms per library:

    Checking compatibility for 137 jar files from 12 distinct libraries:
    Total jar files combined size is 2805K
    Verified 21,908 API elements, and found 1 incompatible libraries (0 in the most recent version)
    Total time was 1038ms (1s)

Therefore, no caching is necessary; lint will run this verification on
each library on every load.

(This CL also fixes a few things around compiled test sources, used by
the new lint tests, as well as a couple of other minor tweaks.)

Test: Existing tests and several new unit tests
Fixes: 181271645
Change-Id: I4d1c5e57460669df6cb1f4809f07413f749d95fa

[JakeWharton]

We have updated to AGP 7 and its associated lint. Here's hoping this manifests less moving forward!