Use the new information available in @PermissionMethod to raise an ERROR level incident if we are confident that migrating to @EnforcePermission is not behavior changing: - the called PermissionMethod returns void, indicating it *enforces* that PackageManager.PERMISSION_GRANTED is true - the called PermissionMethod is annotated orSelf = true, meaning it passes of the calling process OR the current process has the permission Bug: 232058525 Test: SimpleManualPermissionEnforcementDetectorTest Change-Id: Ic4be3d06d6b6446ee81560a6eda7bf9249db1f4c
Android Framework Lint Checker
Custom lint checks written here are going to be executed for modules that opt in to those (e.g. any
services.XXX module) and results will be automatically reported on CLs on gerrit.
How to add new lint checks
- Write your detector with its issues and put it into
checks/src/main/java/com/google/android/lint. - Add your detector's issues into
AndroidFrameworkIssueRegistry'sissuesfield. - Write unit tests for your detector in one file and put it into
checks/test/java/com/google/android/lint. - Done! Your lint checks should be applied in lint report builds for modules that include
AndroidFrameworkLintChecker.
How to run lint against your module
- Add the following
lintattribute to the module definition, e.g.services.autofill:
java_library_static {
name: "services.autofill",
...
lint: {
extra_check_modules: ["AndroidFrameworkLintChecker"],
},
}
- Run the following command to verify that the report is being correctly built:
m out/soong/.intermediates/frameworks/base/services/autofill/services.autofill/android_common/lint/lint-report.html
(Lint report can be found in the same path, i.e. out/../lint-report.html)
- Now lint issues should appear on gerrit!
Notes:
- Lint report will not be produced if you just build the module, i.e.
m services.autofillwill not build the lint report. - If you want to build lint reports for more than 1 module and they include a common module in their
defaultsfield, e.g.platform_service_defaults, you can add thelintproperty to that common module instead of adding it in every module. - If you want to run a single lint type, use the
ANDROID_LINT_CHECKenvironment variable with the id of the lint. For example:ANDROID_LINT_CHECK=UnusedTokenOfOriginalCallingIdentity m out/[...]/lint-report.html
How to apply automatic fixes suggested by lint
See lint_fix
Create or update a baseline
Baseline files can be used to silence known errors (and warnings) that are deemed to be safe. When there is a lint-baseline.xml file in the root folder of the java library, soong will automatically use it. You can override the file using lint properties too.
java_library {
lint: {
baseline_filename: "my-baseline.xml", // default: lint-baseline.xml;
}
}
When using soong to create a lint report (as described above), it also creates a reference baseline file. This contains all lint errors and warnings that were found. So the next time you run lint, if you use this baseline file, there should be 0 findings.
After the previous invocation, you can find the baseline here:
out/soong/.intermediates/frameworks/base/services/autofill/services.autofill/android_common/lint/lint-baseline.xml
As noted above, this baseline file contains warnings too, which might be undesirable. For example,
CI tools might surface these warnings in code reviews. In order to create this file without
warnings, we need to pass another flag to lint: --nowarn. The easiest way to do this is to
locally change the soong code in
lint.go
adding cmd.Flag("--nowarn") and running lint again.