Changes in library projects in Android SDK Tools, r14

Last week we launched the Android 4.0 SDK and a new set of development tools, now in revision 14. The updated tools include many of the changes to build, many performance-enhancing construction. Also included under the hood of a change in how libraries are used by major projects - a first step to better support the library and code reuse. While the change should have little impact on existing projects, some developers have had problems when migrating to the updated tools. Please see below for more information about changes to library projects and how to resolve migration issues.


Previously, library projects are treated as additional resources and source folders used to compile the resources and the application source, respectively. While this worked well for most cases, there are two issues.

1. Developers asked us the ability to distribute a library as a jar file that includes both the compiled code and resources. The nature of the resources of Android, with their identity documents compiled prevented this.

2. The implementation of library projects in Eclipse was extremely fragile. Add additional source folder outside the project folder is not trivial when it needs to be handled automatically, so you do not expose a user's path on the local installation (which is required for people who work together through a source code control, such as SVN or GIT).

For r14, we decided to fix both issues at once, moving to a mechanism-based library compiled code. This solves the fragility of the execution in Eclipse and allow us to then allow the distribution of libraries as a jar file.

As you may have seen in the release notes, the shift to this new mechanism may affect existing projects, in some cases, but there are simple solutions.

The first impact of this change is that the new library project requires the ID of the resources generated by the libraries that are not final. This prevents the Java compiler inlining of values ​​in the library code, and therefore avoids the use of the switch statement in the code of the library. To cope with these events in your code, Eclipse provides refactoring action to make change statements if / else (see here).

Secondly, some projects have been successfully migrated to the new mechanism, resulting in projects that are not compiled with errors such as duplicate classes were added in step dex build. ADT 14 should have migrated older projects that the new mechanism, but the fragility of the mechanisms of old may have prevented that from happening. This project makes reference to the library twice, using the old and new mechanisms, which triggers the class libraries that are packaged on two occasions. If you see this in your projects, look in the Package Explorer home folder with strange name pattern _src. The screenshot at right shows an example of this.

To correct the project, you must remove the foreign source folders with the following steps:

Right-click the source folder and select Build Path> Remove build path
A dialog box will pop up. In it, be sure to check "also unlink the project folder" to completely remove the folder.

With this shift in library projects, which will pave the way for better support for reusable components. We will continue working to make components easier to create, work and manage. Our goal is to enable developers to create applications with great user experiences that adapt easily to all form factors.

Some developers have also told us that only used internally by the library project, which is not necessary to distribute binary versions and prefer to continue with a mechanism based on the source. We are investigating how they might support is next to the new mechanism.

Finally, I note that we are following some known problems (and solution to them) in the current R14 tools on this page: http://tools.android.com/knownissues
Komentar Facebook
0 Komentar untuk "Changes in library projects in Android SDK Tools, r14"

Back To Top