另外javadoc还可以指定定制的doclet（doclet是基于javadoc特定的API开发的小程序，
该程序负责实际的文档输出).android的编译系统就包含了这样一个doclet叫DroidDoc。
可以在/build/tools/DroidDoc目录下找到该工具的全部源代码。
正是该工具在生成HTML的同时
在/out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediates下
面copy（或者说重新生成了）所有将生成到android.jar中的所有源代码（.java文件）.
该工具把所有生成document的源文件重新按Package组织生成在以上目录下。
然后进行编译和打包成android.jar。
根据以上分析，其实android.jar文件是各个公布出来的 API 的源文件经过javadoc重新
组织以后再次编译产生的。 故，android.jar的内容实际上受到javadoc的notation控制
和makefile的控制。 对于android中已存在的代码比如wifi native，可以通过修改源代
码中javadoc的notation的方法重新build得到新的包含wifi native接口的android.jar
（将源文件中的@hide这个notation换成别的，然后make update-api;make sdk)。而对
于新加入的代码，则需要如上方法来修改makefile了。
下面总结一下调查过程中涉及到的知识：
1) javadoc和doclet，简单的看了一下工具的使用和参数，另外看了一下DriodDoc这个
doclet的源代码，找出哪里生成的.java源文件。
2.makefile分析，android的make showcommands命令可以和任何其他目标一起使用来察
看make过程中实际做了一些什么事情。（这点还需要调查这个showcommands如何实现的
，因为make -d这个命令给出的信息对于找到问题帮助不大）
3.在跟踪makefile build过程时，使用$(warning xxxxx)和$(error xxxx)可以在除规则
以外的地方打印出变量的值通过这个方法找出了实际建立要编译的文件列表的地方。