| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The XML DOM parser used by the lint CLI driver (which tracks
positions) is needed outside of lint, so pull it out of the lint/cli
project, and refactor it such that it does not directly reference the
lint Position APIs (but can utilize them when subclassed in lint).
In addition, handle non-UTF-8 file encodings. XML files can be encoded
in other character sets, and can specify this via the encoding
attribute in the XML prologue. Until now, the CLI lint runner would
just read the XML file contents in using the default encoding and
parse this. Now there's a new utility method which takes a byte[] and
infers the desired encoding and uses that to convert the byte[] into a
string using the correct encoding. (We can't just pass an InputStream
and let the SAX parser handle this on its own because the XML parser
needs to access the character stream in order to assign correct node
offsets.) This code now also handles the byte order mark more
cleanly.
There are some new unit tests too to check the new encoding, BOM and
offset handling.
Change-Id: Ib0badbbe72172e3408c6d5af2413be51280a7724
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset changes the way the layout editor picks themes when a
layout is opened. It used to just pick the first available theme in
the theme chooser.
Now it performs the following checks, in order:
* Does this layout have a persisted theme setting from a previous run
of the tool? If yes, use it.
* Can the activity for this layout be determined? If so, look at the
manifest registration for the corresponding activity, and if it
specifies a theme, use it.
* If not, does the manifest specify a default theme for the project?
If so, use it.
* If not, is the target SDK version (or the minimum SDK version, if
the target is not specified) at least API level 11 or higher? If so,
the default theme is "Theme.Holo"
* If not, the default theme is "Theme".
* If the file to be opened is included from some other layout, use
the no-decorations versions of the default layouts, e.g.
Theme.NoTitleBar or Theme.Holo.NoActionBar.
* At the end of this resolution, the computed theme is stored as the
persisted theme setting for this layout, so the above algorithm will
only be computed once. We might want to tweak this such that it
distinguishes between a default computation of a theme and a manual
user choice of a theme.
* If the file is opened as "Show Included In" (e.g. rendered within an
outer file) then the theme chosen is the one for the outer file.
During startup, this information will be asked for each and every
layout being reopened, so there is now a "ManifestInfo" class attached
to the project which keeps manifest information around. It checks the
timestamp of the AndroidManifest.xml file and refreshes its
information lazily if necessary.
All themes mentioned in the manifest are listed in a special section
at the top of the theme chooser (below the entry for the default
computed described above).
The code to look up the associated Activity of a layout is using a
simple heuristic: it looks for usages of the corresponding R.layout
field, and prefers references from methods called onCreate or in
classes whose superclass name ends with Activity. I tried a different
approach where I searched for usages of Activity.setContentView(int)
but this failed to identify a number of cases where the activity was
doing some simple logic and didn't pass the layout id directly as a
parameter in setContentView, so I went back to the basic approach.
Change-Id: Ibd3c0f089fefe38e6e6c607d65524990699c86d3
|
