更改 dalvik/libcore 会导致重建整个框架
我向 Dalvik libcore 方法添加了一些拦截例程（例如 libcore/luni/src/main/java/org/apache/harmony/luni/platform/OSFileSystem.java 中的文件打开方法），我认为这只会更改基本共享库。但令我惊讶的是，每次修改后运行 make 时，它都会重建框架的几乎所有内容，例如计算器应用程序、W3C DOM 解析器等。在经过一小段时间后构建框架确实需要时间修改。我想知道修改 dalvik libcore 后是否可以减少重建组件的数量？谢谢。
I'm adding some interception routines to Dalvik libcore methods (e.g. file open method in libcore/luni/src/main/java/org/apache/harmony/luni/platform/OSFileSystem.java), which I think only changes basic sharing libraries. But to my surprise, every time I run make after modifications, it rebuilds nearly everything of the framework, such as Calculator application, W3C DOM parser, etc. It really takes time to build the framework after a small modification. I'm wondering if it is possible to reduce number of rebuilt components after modifying dalvik libcore? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实上，更改 core.jar 会导致许多内容需要重建，这并不奇怪。 core.jar 包含许多/所有核心 java 类，例如 Object、String 等。因此，构建的每个其他 jar/apk 实际上都依赖于 core.jar。
从 makefile 的角度来看，它不知道您在 core.jar 中更改了什么，以及重建依赖于 core.jar 的所有其他内容是否安全。它只是看到 core.jar 上的最后修改时间比依赖它的所有其他 jar/apk 更新，因此它会重建它们。
然而，诀窍是明确告诉 make 您想要构建什么，而不是告诉它构建所有内容。
假设您之前已经完成了完整的构建，您可以简单地执行
Core 目标将根据您的更改专门构建一个新的 core.jar，而无需重建任何依赖于 core.jar 的内容。
snod 目标（systemimage-nodeps 的缩写）将导致它将 out/target/product//system 中的所有内容重新打包到新的 system.img 中。这是在 build/core/Makefile 中声明的“特殊”目标。
一般来说，特定 jar/apk 的目标只是该 jar/apk 的名称，不带扩展名。或者，您可以查看该模块的 Android.mk 文件，并找到模块名称，通常类似于
LOCAL_PACKAGE_NAME或LOCAL_MODULE，具体取决于模块的类型。对于 core.jar（至少在姜饼中），模块名称位于 libcore/JavaLibrary.mk 中（实际上包含在 libcore/Android.mk 中）。该文件包含许多不同模块的定义，但第一个带有
LOCAL_MODULE := core的模块负责构建 core.jar。其余的似乎主要是测试相关的模块。It actually isn't too surprising that changing core.jar causes many things to be rebuilt. core.jar contains many/all of the core java classes, like Object, String etc. So that every other jar/apk that gets built actually depends on core.jar.
From a makefile perspective, it has no clue what you changed in core.jar, and whether it is safe to not rebuild all these other things that depend on core.jar. It simply sees that the last modified time on core.jar is newer than on all of the other jars/apk that depend on it, so it rebuilds them all.
The trick, however, is to tell make specifically what you want to build, instead of telling it to build everything.
Assuming that you have already done a full build previously, you can simply do
The core target will specifically build a new core.jar with your changes, without rebuilding anything that depends on core.jar.
And the snod target (short for systemimage-nodeps) will cause it to repackage everything from out/target/product//system into a new system.img. This is a "special" target that is declared in build/core/Makefile.
In general, the target for a particular jar/apk is simply the name of that jar/apk, without the extension. Alternatively, you can look at the Android.mk file for that module, and find the module name, which is typically something like
LOCAL_PACKAGE_NAMEorLOCAL_MODULE, depending on the type of module.For core.jar (in gingerbread at least), the module name is in libcore/JavaLibrary.mk (which is actually included by libcore/Android.mk). This file contains definitions for a number of different modules, but the first one, with
LOCAL_MODULE := coreis the one resposible for building core.jar. The rest seem to mostly be test related modules.