Resource IDs cannot be used in a

写一个Library的时候当用到layout里的ID时：

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.btn_institution_refresh:
                if (activity instanceof AbstractXListView.IXListViewListener) {
                    ((AbstractXListView.IXListViewListener) activity).onRefresh();
                } else if (onReloadButtonClickListener != null) {
                    onReloadButtonClickListener.onReloadButtonClick();
                }
                break;
        }
    }

往往会被提示Resource IDs cannot be used in a switch statement in Android library modules。
Validates using resource IDs in a switch statement in Android library module. Resource IDs are non final in the library projects since SDK tools r14, means that the library code cannot treat these IDs as constants. Constant expression required
是的，SDK tools r14之后，library的R文件中的ID都不是final的。因此不能这么使用了。
但是为什么Google要这么设置？一番stackoverflow之后，找到文档：
http://tools.android.com/recent/buildchangesinrevision14

Library Project Revamp

Library projects were introduced to allow sharing of code and resources among projects.

If you are not familiar with library projects, I encourage you to read:

 [http://developer.android.com/guide/developing/projects/index.html#LibraryProjects](http://developer.android.com/guide/developing/projects/index.html#LibraryProjects)

As introduced, the library project relies on building the source code of the main project and of all library dependencies together as part of the build project for the main project. The library projects themselves don’t build anything that is used by projects using them.

Supporting Library Project is easy in Ant, but Eclipse (actually the JDT) requires that source code is located in a source folder under the project. To achieve this, ADT creates virtual source folders linking to the library source folders. Because library dependencies are controlled by the content of

 *project.properties* 

(formerly

 *default.properties*

), ADT must dynamically add and remove these virtual source folders whenever a project is opened and closed.

While this mechanism works, the Eclipse implementation has proven both fragile and cumbersome. For instance, Eclipse does not deal well with having 2 representations of the same on-disk file (one under the library project and the other under the main project). The two versions will get out of sync, requiring manual refresh and both will show compilation errors, polluting the Problems view.

Additionally, source-based library prevents distribution of re-usable components unless one is willing to include the source code.

To fix all of these issues, we have decided to move to library projects generating a jar file that is directly used by other projects.

In order to implement this, we had to change the way resource IDs are generated. In a regular projects, resource IDs are generated as

final static int

. These constants then get inlined into the classes that use them. This means the compiled classes do not access the values stored in, say,

 *R.layout.myui*

, but instead directly embed the value

 *0x000042*

.

To make the compiled classes not embed this value and instead access it from the R classes, library project will generate the resources IDs as

static int

only.

The resource IDs will still be generated as

final static int

in the final R class generated in the main project with the resources of the main projects and all required libraries.

For Ant users there are no changes in workflow. Building the main project will ensure the library project has been built and its output (a jar file) is there. Our Ant build improvements (see above) will make building the library project every time the main project is build an effective no-op.

For Eclipse users, the first time projects are opened, there will be an automated migration. The previous virtual folders (if any) will be removed, and a new classpath container is added to automatically contain the library jar files. In case the virtual source folders (named <libraryname>_src) are not removed, it is safe to remove them manually.

*Warning:* 

Generating IDs as non final in the library projects, means that the library code cannot treat these IDs as constants. This means, for example, that you can’t use res IDs in a switch statement.

At this time, library projects containing the jar file directly instead of the source code are not yet supported. We intend to add this support in r15.

To fix all of these issues, we have decided to move to library projects generating a jar file that is directly used by other projects.

In order to implement this, we had to change the way resource IDs are generated.
为了解决这些问题，我们决定把library工程生成一个可以直接被其他工程使用的jar文件。
为了实现这一点，我们不得不改变resource ID生成的方式。

TODO..