http://zhuyonghui116.blog.hexun.com/53467491_d.html
首先是這個問題如何修改。
在/frameworks/base/Android.mk中,找到如下行:
packages_to_document :=
在該變數的指派陳述式最後添加
xxxxx (這裡是你的包的名稱,比如com/sina/ui,其實這裡就是你的原始碼在/frameworks/base/<你的模組>/java/下面的一部分路徑,只要能夠唯一的匹配到你的代碼即可)
即可。
該添加的含義是使MAKE系統在製作OFF-LINE DOCUMENT時包含我們的package.
以此類推,添加其他新的package也可以這樣做。
下面簡單把android make sdk的過程寫一下來說明為什麼做這樣的修改。調查時是反過來調查的。說明還是按照MAKEFILE的產生的順序來說明吧。
首先在/frameworks/base/Android.mk中定義了進行sdk building的基本目標對象。
包括對哪些.java檔案需要產生API文檔,以及這些文檔的路徑。
然後在/build/core/droiddoc.mk中定義了最終進行build的規則和語句。
Android使用javadoc這個工具來產生所有API文檔。
Javadoc這個工具可以帶一個參數指定一個檔案,該檔案包含了所有要產生文檔的源檔案的名字(全路徑)。
該檔案的內容就是通過在/framework/base/android.mk裡的變數產生的。當然在droiddoc.mk中還添加了build過程中產生的intermediates目錄下的檔案。
另 外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)可以在除規則以外的地方列印出變數的值通過這個方法找出了實際建立要編譯的檔案清單的地方。