Android private libraries added by adt22 causes classnotfoundexception of Third-Party Jar packages.

These three Android private libraries have been overwhelmed by these problems over the past few days. At last, we know that we should keep these three items. If there are other redundant packages, check whether there are repeated packages, or add the libs jar package
To build path. The following is a detailed description.

Recently, a colleague complained to me about the classnotfoundexception error that will always be reported when the compiled Android APK runs after eclipse is reinstalled with the new adt22. How can this problem be solved? How can it be caused by something from a company as big as Google. If he doesn't believe it, try it. If I say yes, try it. I used adt21 before, and the result was moved to adt22 after the operation, dizzy, do not accept, it is really classnotfound.

Next, I changed several projects for compilation and running, and found that not necessarily all projects are wrong, but some APK that uses a third-party jar package or library project will make an error, that is, the notfound class is in the referenced jar package.

The next step is to find a solution on the Internet and finally find the solution. to Com. android. IDE. eclipse. ADT. libraries plus exported = true, or select Android private libraries in order and export of the Java build path in the project attribute to export the relevant libraries to the APK.

The problem is solved, but why? Why didn't adt21 need it? I used adt21 on the other machine, so I compared the engineering properties of the two versions of ADT and found that they were actually different. Below is the adt21:

The corresponding packages and source code are connected with red lines for analysis. Below is the adt22:

Obviously, adt21 classifies all referenced jar packages as Android dependencies, while adt22 automatically divides the jar packages into Android private libraries and Android dependencies. Adt21 can automatically export and package all referenced jar packages to APK without selecting the export check, while adt22 selects permissions for developers, let developers decide which packages to export to the APK. For example, if the program is targeting a later Android system, you can select some support packages that do not need to be exported.

Obviously, adt22 is more reasonable than adt21, and you should not export unselected packages. However, in most cases, we need to export the package to the project. To achieve the export effect of adt21, you only need to check the last two items, such:

In this way, the ADT will package the classes in the corresponding jar package into the APK, and then run the package without finding the class.

In fact, to address the classnotfound issue, Android Developers should not have encountered this problem for the first time. They had already encountered this problem when upgrading from adt16 to adt17. Before adt17, as long as the jar in the build path of the project is in place, ADT will be automatically compiled into the APK; however, in adt17, you have to put all the packages to be exported under the libs directory. For this reason, I have also translated an article from a foreigner. For more information, see http://blog.csdn.net/huzgd/article/details/7604069.

From automatic export of any jar, to export only the jar of the libs directory, to export only the selected jar, it should be said that ADT is being improved, but it also brings the trouble of upgrading. In general, adt22 is not a problem, but the compilation tools before adt21 are not standardized. adt22 is only more standard. That's to say, Google won't be so easy to disappoint, but it will be tough.