Pick layout themes from manifest registrations and target SDK

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

2 files changed, 9 insertions, 0 deletions

diff --git a/common/src/com/android/io/FileWrapper.java b/common/src/com/android/io/FileWrapper.java
index c1e8f81..2859c0d 100644
--- a/common/src/com/android/io/FileWrapper.java
+++ b/common/src/com/android/io/FileWrapper.java
@@ -137,6 +137,10 @@ public class FileWrapper extends File implements IAbstractFile {
         return isFile();
     }
 
+    public long getModificationStamp() {
+        return lastModified();
+    }
+
     public IAbstractFolder getParentFolder() {
         String p = this.getParent();
         if (p == null) {
diff --git a/common/src/com/android/io/IAbstractFile.java b/common/src/com/android/io/IAbstractFile.java
index d8d794d..6dfc8d8 100644
--- a/common/src/com/android/io/IAbstractFile.java
+++ b/common/src/com/android/io/IAbstractFile.java
@@ -50,4 +50,9 @@ public interface IAbstractFile extends IAbstractResource {
      * Returns the preferred mode to write into the file.
      */
     PreferredWriteMode getPreferredWriteMode();
+
+    /**
+     * Returns the last modification timestamp
+     */
+    long getModificationStamp();
 }