| 12d4581faa6438941e65a9dc83213be34c6ca970 |
|
13-Sep-2012 |
Tor Norbye <tnorbye@google.com> |
Constants refactoring.
This changeset moves most constants into the SdkConstants
class, and gets rid of AndroidConstants and LintConstants.
It also migrates all non-ADT specific constants from
AdtConstants into SdkConstants. It furthermore moves various
other constants (such as those in XmlUtils and ValuesDescriptors)
into the constants class. It also fixes the modifier order
to be the canonical modifier order (JLS 8.x).
Finally, it removes redundancy and combines various constant
aliases such that we don't have both NAME_ATTR and ATTR_NAME
pointing to "name", etc.
Change-Id: Ifd1755016f62ce2dd80e5c76130d6de4b0e32161
|
| 7dd444ea0125e50a5e88604afb6de43e80b7c270 |
|
08-May-2012 |
Tor Norbye <tnorbye@google.com> |
New Template Wizard support
This changeset adds several new templates, to create a new project, a
new activity, a new custom view, etc.
More importantly, it contains support for these wizards (and the
corresponding code generation) to be driven by templates.
A wizard contains metadata which provides a name, description and icon
for the template, as well as a list of parameters, along with type and
constraint metadata for those parameters. When a wizard is created for
this template, it automatically adds UI elements to input the
parameters and to validate the input. Parameters can also specify
their default values as templated expressions using the other
variables on the page, so in the New Blank Activity wizard for
example, editing the activity name automatically updates the suggested
layout name, by repeatedly evaluating a template expression to compute
a layout name from an activity name.
There's a recipe file for each template which states what actions to
take to create the template. In addition to obviously copying
resources (such as icons and jar files) and instantiating templates
(to rewrite text using variables and FreeMarker logic), it can also
merge XML contents (to for example insert activity registration
metadata into the manifest file, or add string definitions to the
strings.xml file), and it can cause files to be opened when the
template is created.
Tne new wizards also use JFace's decorator support to provide help and
to mark text fields that contain errors, when one or more of the page
fields do not validate, as well as to show tip text along the bottom
of the page. One example of this is that it explains what a "package
name" is when the package field has focus.
This changeset also contains a "Template Development Wizard" which
lets you point to a local directory containing a template definition,
and run a test wizard from there. This is useful for developing,
debugging and testing templates.
Change-Id: I08e7d2464a1ef00d09517f0154c42681249a7ff6
|
| d02dad911cea4f854e32cc99e10cdd31ab89a795 |
|
07-May-2012 |
Tor Norbye <tnorbye@google.com> |
Run lint on save in Java files, checking .java and .class files
This changeset adds support for per-save file checking in Java source
files. It will run both source file and bytecode based checks,
possibly at different times (since they are updated at different
times). This required some changes to the incremental lint runner,
since now incremental checking means possibly touching more than one
file (multiple inner classes for a single source), as well as
distinguishing between the source files containing markers (the .java
file) and the actual files being analyzed (the .class files).
This changeset also formalizes incremental lint checking a bit: it now
distinguishes between the affected scope of an issue (all the various
file types that can affect an issue), as well as the scope sets that
are capable of analyzing the issue independently.
Take the API check for example. Its affected scope includes both XML
files and Java class files, since both can contain API references (in
the case of XML, a <GridLayout> reference is an invocation of a
constructor of the GridLayout class for example). However, we can
analyze a standalone class file, or a standalone XML file, and
incrementally update issues found in the file, without regard for the
other. Therefore, the API detector has two separate analysis scopes:
classes, and XML resources. The manifest registration detector on the
other hand needs to look at both the manifest file and the class
files; it cannot look at just a subset of these.
Change-Id: Ibf5ca8a90846256e0817b419908ee53f8354412a
|
| d6124a176326169bc87cb29823ca2dc906689680 |
|
03-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
A few simple name changes
This changeset contains no semantic changes, just a couple of simple
refactorings:
(1) Rename the "Lint" class to "LintDriver". "Lint" is a bit generic
(there's already LintClient for example), and this object was
already referred to as a driver from various other API's, such as
Context.getDriver().
(2) Rename LintRunner in Eclipse to EclipseLintRunner, similar to the
other EclipseLintClient in the same package - and to avoid
confusion with LintDriver.
(3) Move all the lint fix inner classes inside the LintFix class out
as top level classes. The class was getting really large and
there's really no good reason to keep all the individual fixes as
inner classes; there's already a separate lint package for them.
Change-Id: Ifc0004bfb38f8e11e33e9ddc477b6cf07ca319f2
|
| 4c68f3dc9f10b76f1a32ff9c86587adca385a6d7 |
|
14-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Lint Library Support
This changeset adds support for library projects to lint. Lint now
checks all the library projects for errors as well, and projects that
depend on global analysis (such as the unused resource detector) will
properly handle resource declarations and references across projects.
This changeset also cleans up the multi-project handling for the Lint
window in Eclipse. The "Run Lint" toolbar action, in addition to
operating on multiple selection, now has a dropdown menu for choosing
which projects to check (and there are also actions for checking all
projects, the current file, and clearing markers). Running lint on a
project will also automatically include dependent library projects.
Finally, some misc UI improvements: The Lint preference dialog
includes buttons for quickly enabling and disabling all the checks;
the Lint View includes a Project column which is shown when more than
one project is checked, and the file and linenumber columns are now
blank when the location does not correspond to a specific file.
Change-Id: I733f5258102dfb0aebbc2b75cb02b9ba6ef974e8
|
| ab36f4e7488358dea4ab6b54ee2b7bef3da0232b |
|
21-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Update SDK codebase to JDK 6
This changeset makes the SDK codebase compile with source=1.6 (which
means it also requires JDK 6). This means that methods implementing an
interface requires @Override's. It also means we can start using APIs
like the ArrayDeque class and methods like String#isEmpty().
This changeset looks big but the change is trivial: it's basically
adding @Override in all the places that need it, along with some other
automatic Eclipse cleanup in certain files (such as reordering imports
where they were incorrectly ordered (because older versions of Eclipse
didn't always handle inner classes right)), as well as cleaning up
trailing whitespace and removing some $NON-NLS-1$ markers on lines
where there aren't any string literals anymore.
This changeset also sets the source and target JDK level to 6 in the
Eclipse compiler .settings file, and synchronizes this file to all the
other Eclipse SDK projects.
Change-Id: I6a9585aa44c3dee9a5c00739ab22fbdbcb9f8275
|
| bc32af8dc9e20135c29ba7444ae162761774cdb5 |
|
15-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Fix Run Lint toolbar action to pick up more selection contexts
You currently have to select a project in the package explorer before
you click on the Run Lint toolbar action. This changeset makes the
action look harder for which project to run lint for:
- As before, look for the current selection and check whether it
provides a selection
- If there's an active editor, use its project.
- If not, if there's just one available Android project, use it.
- If not, if there's just one non-library Android project, use it.
Finally, display a warning dialog if no project can be found, or if
the selected project is not an Android project, such that it's
apparent why nothing happens.
Change-Id: I92daa080db0bd815bc3d51fe9e458df12e6cc50f
|
| c1a2b096df38e7b9e6bcac0cc217357f95d0dd3f |
|
10-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
Minor lint tweaks
First, replace tabs with spaces in the quoted error lines in the
command line output, since otherwise the column marker (^) which is
space based may not line up with the part of the line it is supposed
to point to.
Second, make the code which looks up the project corresponding to a
selection able to find a project when you click on something *in* a
project, such as a Java file within a Java project.
Third, don't print "skipping file because it contains parser errors"
in the CLI output; there's no need to since the parser themselves
report parsing errors now.
Change-Id: I57fd8a783c422a287cf9529caa1f858d7cff52d1
|
| 229581314076be1b6f82fe1efed2bd00da340899 |
|
07-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
Lint Architecture Changes: Configurations, Categories, etc.
This changeset makes various architectural changes to lint:
(1) Add configurations, which are basically user preferences for lint
in a given project, such as providing a custom severity for an
issue, or disabling a specific warning in a specific file.
In Eclipse, there is a project configuration (stored in lint.xml
in each project), as well as a global configuration (stored using
Eclipse preference data). Project configurations inherit from the
global configuration.
The options dialog now shows up both as a project property page
(showing the issue state for the project configuration), as well
as a normal preference page (showing the global or "fallback"
configuraiton). I also changed the Options UI for issues from a
Table to a TreeViewer to add in category nodes, and changed the
checkbox UI to have a custom severity toggle instead.
The lint quickfixes also now have 3 suppression options:
* Ignore in this file
* Ignore in this project
* Disable check
(2) Change detectors to be registered by class and instantiated for
each lint run rather than having a fixed list of detectors get
reused over and over. Turns out that since some detectors store
state, this prevented lints from running concurrently since the
two runs could stomp each other's state.
To do this effectively I've also switched from a DetectorRegistry
to an IssueRegistry, which contains the global list of available
issues and each issue can point to the class detecting the issue
(and these are created on the fly based on parameters like scope.)
(3) Explicit Categories. Categories used to just be a string property
on issues; now it's an explicit class with both a name and an
explanation, with parents to allow nesting (such that for example
the Usability category has an Icons sub category), and finally the
category class provides sorting. Categories also show up in the
HTML Report now as separate sections.
(4) Other API changes:
* I changed the package containing APIs for lint clients to an
explicit "client" package
* Moved the LintConstants class up from lint-checks to lint-api
and added a LintUtils class which contains many generic methods
that were spread around in specific detectors.
* The detectors are now talking to a wrapper client rather than
directly to lint clients, such that the wrapper client can
filter out results on disabled checks etc, which means that
tools can assume they always get correct reports and don't have
to worry about improperly written detectors.
* I renamed ToolContext to LintClient.
* I got rid of the "isEnabled" state, which was a bit redundant
with the severity since severity has a Severity.IGNORE value.
* I added a LintListener interface, which notifies about progress
(and the CLI tool will print "."'s for each processed file
unless suppressed with -q).
* A new dispose method on the parser interface to for example
allow IDEs to lock/unlock read models on underlying data.
(5) I added a toolbar action for running Lint on the currently
selected project. I also added an --xml export option intended
for use with CI plugins.
Change-Id: Icadd9b2d14d075234d97b31398806111af747b7b
|
| 27ed098e750ee9463dfa7a36cef68d219de9eb50 |
|
31-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
Lint infrastructure fixes
This changeset makes a number of infrastructure fixes to lint. It also
has some user visible aspects:
(1) The "run lint on export" option, which aborts Export APK if fatal
errors are found, now only checks for fatal issues, which should
be significantly faster (since it skips expensive detectors like
the unused resource detector).
(2) The command line lint tool lets you specify not just issue ids,
but categories to enable or disable as well. In addition to the
--enable and --disable flags to add or remove checks, there is
also a --check flag which runs the exact specified checks. Thus
you can for example run "lint --check Security" to run the
security related lint checks. When using --show to display the
available id's, they are organized and described under category
labels.
I also cleaned up the categories a bit; "Layout" isn't a category
anymore, and instead the layoutopt options are placed in other
categories like "Performance" or "Usability".
(3) From the command line you can now also specify multiple projects
or even search a directory for projects contained recursively
within it. This required a bunch of infrastructure changes to
handle partitioning up the arguments into related projects (since
checks have before-project and after-project hooks that need to
run properly).
(4) On the infrastructure side the "scope" concept was changed to
become a scope set, and a detector can declare that an issue
requires analysis of any of {manifest, resource file, java source
file, resource folder, ...} etc. When lint runs it determines
which detectors are applicable (for example, for a single-file
lint run it will ignore detectors which require a wider
scope). And when applicable, a detector will be called for all the
various scopes it requires. Therefore, the unused resource
detector, which used to have to manually scan the manifest file on
its own, now automatically gets called as part of the manifest
file parse, the resource file parses, and the java file scan.
Single-file linting is still only supported for XML files.
Change-Id: I49a5e2b27f8f6da22904085089aa0c4d2eee67f6
|
| 7b08b8258cffcb3085a90d32e02da95fafbfdeaf |
|
25-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
New Lint Window
This changeset adds a new Lint View in Eclipse (available under Show
View in the Android category), which is a specialized view to view
lint warning markers.
This view opens automatically when you run Lint on a project. (The
view code is also shared with the single-file view shown when you
bring up the lint warnings from the layout editor.)
The lint view is similar to the Problems View (where lint markers also
show up), but with the following advantages:
(1) When you run lint, this view shows *only* lint warnings for the
project, rather than being mixed in with Java warnings etc from
this and other projects.
(2) The issue sorting is different here than in the Problems view: the
results normally sort in order of priority, category, issue type,
file and line number.
(3) The view contains a text area which displays more information for
the currently selected issue, such as the detector summary and
issue full explanation.
(4) The view toolbar has dedicated lint actions, such as a Fix
lightbulb to run the associated fix (if any), an Ignore Type
button for suppressing the selected type of issue, and Remove and
Remove All buttons for clearing markers. And of course a "Refresh"
button for re-running the analysis.
Change-Id: If58462d3eea198c07330ed9847f00925f346abaa
|
| a85107f7d763276a5a040cf68e2046ac54202015 |
|
06-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
Static analyzer
This changeset adds a static analyzer, "lint", which looks for various
potential bugs in Android projects. It has 3 parts:
(1) A library which performs the actual static checks.
This library is standalone: it does not depend on Eclipse.
(Technically the library has two halves: an API half, for use
by third party developers to write additional detectors, and
an actual implementation of a bunch of built-in checks.)
(2) A command line driver, "lint", which runs the static checks and
emits any warnings to standard out. This can be thought of as
a replacement for the layoutopt tool.
(3) Eclipse integration. Lint errors are added to the Problems view as
well as shown as editor annotations. There's an options panel for
controlling which detectors are enabled. There's also a quickfix
for disabling errors directly within the editor and a marker
resolution for disabling them via the Problems view.
The static checks are run on an XML file right after it has been
saved. (This is optional via a toggle on the same preference page
as the detector list.)
The static checks are also run when you export an APK, and if any
fatal errors are found the export is abandoned. (This is also
optional via an option).
Finally you can run a full lint through the Android Tools menu,
and there's also an action to clear all the lint markers there.
There's also a new indicator on the layout editor which shows
whether there are lint errors on the associated file, and when
clicked brings up a dialog listing the specific errors.
This changeset also includes a number of checks:
* An accessibility detector which warns about images missing
contentDescriptions
* A drawable selector detector which warns about state lists where not
all states are reachable (e.g. it is not the case that only the last
item in the list omits a state qualifier)
* A detector finding duplicate ids, not just in the current layout but
across included layouts (transitively) as well
* All the layoutopt ones ported to Java + DOM
* Unit tests for the above.
The focus here is on getting the infrastructure in place, and it
currently focuses on XML resource files and analyzing them
efficiently. See the comment in XmlVisitor for details on that.
Change-Id: Ic5f5f37d92bfb96ff901b959aaac24db33552ff7
|