strict_updatability_linting imposes requirements on all of a module's
transitive dependencies. So you may start getting errors on a module
due to some random other module that is hard to track down. Print out
the modules that caused the current module to use strict updatability
linting so that these errors are easier to debug.
Ignore-AOSP-First: The lint code in internal has diverged from AOSP quite a bit now
Bug: 323366771
Test: m lint-check
Change-Id: I43f2b1adb1ffa5b6e9516694c2bb87c7f94fed7d
strict_updatability_linting currently only checks that updatability
checks aren't disabled via disabled_checks / warning_checks, you could
get around it using the `flags` property. Only allow controlling checks
via the *_checks properties.
Bug: 322802379
Test: m nothing --no-skip-soong-tests
Change-Id: Ia311622e1409f9cc201ab55f8749f2d13fccf551
Now that all use cases where it would've errored on are removed.
Ignore-AOSP-First: the properties were only removed in internal main to make the LSC smaller
Bug: 320698986
Test: m nothing --no-skip-soong-tests, and also locally edited soong to add a quick build that runs all the strict updatability checks in the tree and ran that
Change-Id: If9e23327a3c0944cc8c6849914fe51dc48bdb626
Now that all existing cases have been baselined.
Ignore-AOSP-First: Requires a LSC that is difficult to do across branches.
Bug: 268261262
Test: m lint-check
Change-Id: I413f86ff7a1f33564465f3ba9cd52924a4242901
lintable modules currently pick up files named "lint-baseline.xml" to
use as the lint baseline implicitly. This is confusing because you could
end up using the baseline files in more modules than intended. Lint also
has a feature where it requests you remove unnecessary findings from the
baseline file, so something could be necessary for one module, but
unnecessary for another that accidentally picked up the baseline.
All modules that used to pick up the baseline implicitly have been
fixed to specify it explicitly already.
Fixes: 272769514
Test: Presubmits
Change-Id: Id17202e2d119b87ab82c18cb35410b93ed8d5071
The next CL will need a TestContext parameter in
ContentFromFileRuleForTests in order to retrieve the file rule contents
from the Config. Add it and update all the tests that use it in order
to simply review of the next CL.
Bug: 306029038
Test: go test ./...
Change-Id: Ia4b4c9854017ea3472fa2f8ba42cf7f72720496e
Before this change, lint was always working off of the public
api database. Now, it will have the system, module-lib, or
system-server databases if the current module is compiling
against those SDKs.
This means that a lot more methods are going to start being
checked for NewApi issues.
Bug: 193460475
Test: Errorprone presubmit
Change-Id: I3eb2c617cd61554cd2a3f9d15fd40b3ec91f961d
strict_updatability_linting currently only makes it so
that NewApi can't be added to the lint baseline.
However, since we're updating NewApi to work on a lot
more apis than before, we need to baseline many issues
across the android tree. Temporarily disable
strict_updatability_linting so that we can add these
baselines.
Bug: 193460475
Test: Presubmits
Change-Id: I8d92df95a46e9b903f0cc0e3be56f17722c50430
Lint's NewApi checks currently produce a lot of false positive findings.
The filtered lint database removes information of classes defined by
mainline modules which are the cases that might become a false positive.
This commit updates soong to use this database instead of the normal one
when linting mainline modules.
Test: m lint-check
Fixes: 186478867
Change-Id: Ica646081b9189303c393b36b2f02914d69eee291
Propagate strict_updatability_linting to transitive dependencies using a
top-down mutator.
Test: lint_test.go
Bug: 182349282
Change-Id: Ifc9e58f1a597e3c7725ee49b4027afb6f42f45cb
The flag prevents developers from skipping updatability lint checks with
baseline files
Test: lint_test.go & manual
Bug: 182349282
Change-Id: Ia74a2b83c7ef686124128bdf16f7b85a919d9e8d
