Android编译系统分析五:system.img的生成过程

Android编译系统分析系列文章:
android编译系统分析(一)-source build/envsetup.sh与lunch
Android编译系统(二)-mm编译单个模块
android编译系统分析(三)-make
android编译系统(四)-实战:新增一个产品
Android编译系统分析(五)-system.img的生成过程


我们在完整编译android系统的时候,最终会生成几个重要的镜像文件,其中有system.img,userdata.img,ramdisk.img等。这篇文章的目的是分析system.img的生成过程。
回想下我们完整编译android系统时的动作,我们会在android源码顶级目录执行make命令,这样就会完整的编译android系统,我们没有传入任何参数(-jx等加快编译的除外),因为我们没有明确指定make的目标,所以android编译系统会执行默认的编译目标,也就是droid。因此,我们还是从droid着手,看看system.img怎么生成。
我们只关注system.img相关的部分,其他部分都忽略,因此会有如下依赖关系:
system.img生成依赖图

一.systemimage

# Rules that need to be present for the all targets, even
# if they don't do anything.
.PHONY: systemimage
systemimage:

sytemimage是一个伪目标,它并不会被生成。

systemimage: $(INSTALLED_SYSTEMIMAGE)

systemimage依赖于$(INSTALLED_SYSTEMIMAGE)

二.$(INSTALLED_SYSTEMIMAGE)

INSTALLED_SYSTEMIMAGE := $(PRODUCT_OUT)/system.img

INSTALLED_SYSTEMIMAGE变量的值就是system.img了,也就是说它就是我们最终要生成的目标。那么看看它的定义:

$(INSTALLED_SYSTEMIMAGE): $(BUILT_SYSTEMIMAGE) $(RECOVERY_FROM_BOOT_PATCH) | $(ACP)
    @echo "Install system fs image: $@"
    $(copy-file-to-target)
    $(hide) $(call assert-max-image-size,$@ $(RECOVERY_FROM_BOOT_PATCH),$(BOARD_SYSTEMIMAGE_PARTITION_SIZE))

(INSTALLEDSYSTEMIMAGE) (BUILT_SYSTEMIMAGE) 和 (RECOVERYFROMBOOTPATCH) (ACP),我们目前无法知道这三个变量是什么,当然,这里的 (ACP)readonly (ACP)发生改变时,编译器并不会重新生成system.img, (ACP)acpacp.cbuild/tools/acp/acpsystem.img使使system.img (BUILT_SYSTEMIMAGE) 和$(RECOVERY_FROM_BOOT_PATCH)代表的是什么,但是我们可以先看看system.img的生成规则,看看生成规则是怎么使用这三个依赖来生成system.img镜像文件的的。

2.1$(copy-file-to-target)

copy-file-to-target的定义如下:

# Copy a single file from one place to another,
# preserving permissions and overwriting any existing
# file.
# We disable the "-t" option for acp cannot handle
# high resolution timestamp correctly on file systems like ext4.
# Therefore copy-file-to-target is the same as copy-file-to-new-target.
define copy-file-to-target
@mkdir -p $(dir $@)
$(hide) $(ACP) -fp $< $@
endef

结合注释,这段代码的功能是拷贝文件,并且在拷贝的过程中会保留文件的权限和覆盖已有的文件。 < <script type="math/tex" id="MathJax-Element-5"> <代表的是第一个依赖,也就是这里的< script>(built_systemimage),这里首先会创建 out target product xxx 目录,其中xxx是产品名,然后把 (BUILTSYSTEMIMAGE)system.imgsystem.img (BUILT_SYSTEMIMAGE)变量所代表的文件直接拷贝而来,因此,要搞清system.img的生成过程,必须搞清$(BUILT_SYSTEMIMAGE)的生成过程。

2.2assert-max-image-size

紧随其后的assert-max-image-size函数又做了什么呢?调用它的时候传入了两个参数,分别是1.system.img 2. (RECOVERYFROMBOOTPATCH), (BOARD_SYSTEMIMAGE_PARTITION_SIZE)
(RECOVERYFROMBOOTPATCH)RECOVERYFROMBOOTPATCH:= (intermediates)/recovery_from_boot.p
$(BOARD_SYSTEMIMAGE_PARTITION_SIZE)则是一个数字,不同的产品这个数字不同:
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 1610612736
assert-max-image-size的定义如下:

# Like assert-max-file-size, but the second argument is a partition
# size, which we'll convert to a max image size before checking it
# against the files.
#
# $(1): The file(s) to check (often $@)
# $(2): The partition size.
define assert-max-image-size
$(if $(2), \
  $(call assert-max-file-size,$(1),$(call image-size-from-data-size,$(2))))
endef

image-size-from-data-size函数如下:

# Convert a partition data size (eg, as reported in /proc/mtd) to the
# size of the image used to flash that partition (which includes a
# spare area for each page).
# $(1): the partition data size
define image-size-from-data-size
$(strip $(eval _isfds_value := $$(shell echo $$$$(($(1) / $(BOARD_NAND_PAGE_SIZE) * \
  ($(BOARD_NAND_PAGE_SIZE)+$(BOARD_NAND_SPARE_SIZE))))))\
$(if $(filter 0, $(_isfds_value)),$(shell echo $$(($(BOARD_NAND_PAGE_SIZE)+$(BOARD_NAND_SPARE_SIZE)))),$(_isfds_value))\
$(eval _isfds_value :=))
endef

可以看到这个函数对分区大小做一个转换,转换为flash芯片上的分区大小。之后把转换后的结果传给assert-max-file-size作为第二个参数。
assert-max-file-size定义如下:

# $(1): The file(s) to check (often $@)
# $(2): The maximum total image size, in decimal bytes.
#    Make sure to take into account any reserved space needed for the FS.
#
# If $(2) is empty, evaluates to "true"
#
# Reserve bad blocks.  Make sure that MAX(1% of partition size, 2 blocks)
# is left over after the image has been flashed.  Round the 1% up to the
# next whole flash block size.
define assert-max-file-size
$(if $(2), \
  size=$$(for i in $(1); do $(call get-file-size,$$i); echo +; done; echo 0); \
  total=$$(( $$( echo "$$size" ) )); \
  printname=$$(echo -n "$(1)" | tr " " +); \
  img_blocksize=$(call image-size-from-data-size,$(BOARD_FLASH_BLOCK_SIZE)); \
  twoblocks=$$((img_blocksize * 2)); \
  onepct=$$((((($(2) / 100) - 1) / img_blocksize + 1) * img_blocksize)); \
  reserve=$$((twoblocks > onepct ? twoblocks : onepct)); \
  maxsize=$$(($(2) - reserve)); \
  echo "$$printname maxsize=$$maxsize blocksize=$$img_blocksize total=$$total reserve=$$reserve"; \
  if [ "$$total" -gt "$$maxsize" ]; then \
    echo "error: $$printname too large ($$total > [$(2) - $$reserve])"; \
    false; \
  elif [ "$$total" -gt $$((maxsize - 32768)) ]; then \
    echo "WARNING: $$printname approaching size limit ($$total now; limit $$maxsize)"; \
  fi \
 , \
  true \
 )
endef

这个函数对system.img的大小做一个检查,如果system.img太大,超过了flash允许的最大分区的大小,这里就会报错。
因此,assert-max-image-size函数可以理解为检查system.img的合法性。

三.$(BUILT_SYSTEMIMAGE)

我们分析system.img的生成规则发现,system.img其实是 (BUILTSYSTEMIMAGE) (BUILT_SYSTEMIMAGE)又是怎么生成的呢?
(BUILTSYSTEMIMAGE)sytem.img (systemimage_intermediates)目录下:
BUILT_SYSTEMIMAGE := (systemimageintermediates)/system.img (systemimage_intermediates) := target/product/xxx/obj/PACKAGING/systemimage_intermediates
$(BUILT_SYSTEMIMAGE)的依赖与生成规则如下:

$(BUILT_SYSTEMIMAGE): $(FULL_SYSTEMIMAGE_DEPS) $(INSTALLED_FILES_FILE)
    $(call build-systemimage-target,$@)

我们不知道它依赖的是什么,但是我们可以先看一下它的生成规则:
build-systemimage-target函数定义如下:

# $(1): output file
define build-systemimage-target
  @echo "Target system fs image: $(1)"
  $(call create-system-vendor-symlink)
  @mkdir -p $(dir $(1)) $(systemimage_intermediates) && rm -rf $(systemimage_intermediates)/system_image_info.txt
  $(call generate-userimage-prop-dictionary, $(systemimage_intermediates)/system_image_info.txt, \
      skip_fsck=true)
  $(hide) PATH=$(foreach p,$(INTERNAL_USERIMAGES_BINARY_PATHS),$(p):)$$PATH \
      ./build/tools/releasetools/build_image.py \
      $(TARGET_OUT) $(systemimage_intermediates)/system_image_info.txt $(1) $(TARGET_OUT) \
      || ( echo "Out of space? the tree size of $(TARGET_OUT) is (MB): " 1>&2 ;\
           du -sm $(TARGET_OUT) 1>&2;\
           if [ "$(INTERNAL_USERIMAGES_EXT_VARIANT)" == "ext4" ]; then \
               maxsize=$(BOARD_SYSTEMIMAGE_PARTITION_SIZE); \
               if [ "$(BOARD_HAS_EXT4_RESERVED_BLOCKS)" == "true" ]; then \
                   maxsize=$$((maxsize - 4096 * 4096)); \
               fi; \
               echo "The max is $$(( maxsize / 1048576 )) MB." 1>&2 ;\
           else \
               echo "The max is $$(( $(BOARD_SYSTEMIMAGE_PARTITION_SIZE) / 1048576 )) MB." 1>&2 ;\
           fi; \
           mkdir -p $(DIST_DIR); cp $(INSTALLED_FILES_FILE) $(DIST_DIR)/installed-files-rescued.txt; \
           exit 1 )
endef

这个函数做了四件事情:

define create-system-vendor-symlink
$(hide) if [ -d $(TARGET_OUT)/vendor ] && [ ! -h $(TARGET_OUT)/vendor ]; then \
  echo 'Non-symlink $(TARGET_OUT)/vendor detected!' 1>&2; \
  echo 'You cannot install files to $(TARGET_OUT)/vendor while building a separate vendor.img!' 1>&2; \
  exit 1; \
fi
$(hide) ln -sf /vendor $(TARGET_OUT)/vendor
endef

如果存在vendor目录,就给vendor目录创建一个软连接。

2.创建target/product/xxx/obj/PACKAGING/systemimage_intermediates目录并删除这个目录下的system_image_info.txt文件。

3.重新向system_image.info.txt中写入数据

# $(1): the path of the output dictionary file
# $(2): additional "key=value" pairs to append to the dictionary file.
define generate-userimage-prop-dictionary
$(if $(INTERNAL_USERIMAGES_EXT_VARIANT),$(hide) echo "fs_type=$(INTERNAL_USERIMAGES_EXT_VARIANT)" >> $(1))
$(if $(BOARD_SYSTEMIMAGE_PARTITION_SIZE),$(hide) echo "system_size=$(BOARD_SYSTEMIMAGE_PARTITION_SIZE)" >> $(1))
$(if $(BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE),$(hide) echo "system_fs_type=$(BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE)" >> $(1))
$(if $(BOARD_SYSTEMIMAGE_JOURNAL_SIZE),$(hide) echo "system_journal_size=$(BOARD_SYSTEMIMAGE_JOURNAL_SIZE)" >> $(1))
$(if $(BOARD_HAS_EXT4_RESERVED_BLOCKS),$(hide) echo "has_ext4_reserved_blocks=$(BOARD_HAS_EXT4_RESERVED_BLOCKS)" >> $(1))
$(if $(BOARD_SYSTEMIMAGE_SQUASHFS_COMPRESSOR),$(hide) echo "system_squashfs_compressor=$(BOARD_SYSTEMIMAGE_SQUASHFS_COMPRESSOR)" >> $(1))
$(if $(BOARD_SYSTEMIMAGE_SQUASHFS_COMPRESSOR_OPT),$(hide) echo "system_squashfs_compressor_opt=$(BOARD_SYSTEMIMAGE_SQUASHFS_COMPRESSOR_OPT)" >> $(1))
$(if $(BOARD_USERDATAIMAGE_FILE_SYSTEM_TYPE),$(hide) echo "userdata_fs_type=$(BOARD_USERDATAIMAGE_FILE_SYSTEM_TYPE)" >> $(1))
$(if $(BOARD_USERDATAIMAGE_PARTITION_SIZE),$(hide) echo "userdata_size=$(BOARD_USERDATAIMAGE_PARTITION_SIZE)" >> $(1))
$(if $(BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE),$(hide) echo "cache_fs_type=$(BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE)" >> $(1))
$(if $(BOARD_CACHEIMAGE_PARTITION_SIZE),$(hide) echo "cache_size=$(BOARD_CACHEIMAGE_PARTITION_SIZE)" >> $(1))
$(if $(BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE),$(hide) echo "vendor_fs_type=$(BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE)" >> $(1))
$(if $(BOARD_VENDORIMAGE_PARTITION_SIZE),$(hide) echo "vendor_size=$(BOARD_VENDORIMAGE_PARTITION_SIZE)" >> $(1))
$(if $(BOARD_VENDORIMAGE_JOURNAL_SIZE),$(hide) echo "vendor_journal_size=$(BOARD_VENDORIMAGE_JOURNAL_SIZE)" >> $(1))
$(if $(BOARD_OEMIMAGE_PARTITION_SIZE),$(hide) echo "oem_size=$(BOARD_OEMIMAGE_PARTITION_SIZE)" >> $(1))
$(if $(BOARD_OEMIMAGE_JOURNAL_SIZE),$(hide) echo "oem_journal_size=$(BOARD_OEMIMAGE_JOURNAL_SIZE)" >> $(1))
$(if $(INTERNAL_USERIMAGES_SPARSE_EXT_FLAG),$(hide) echo "extfs_sparse_flag=$(INTERNAL_USERIMAGES_SPARSE_EXT_FLAG)" >> $(1))
$(hide) echo "selinux_fc=$(SELINUX_FC)" >> $(1)
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_BOOT_SIGNER),$(hide) echo "boot_signer=$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_BOOT_SIGNER)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VERITY),$(hide) echo "verity=$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VERITY)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VERITY),$(hide) echo "verity_key=$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_VERITY_SIGNING_KEY)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VERITY),$(hide) echo "verity_signer_cmd=$(VERITY_SIGNER)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SYSTEM_VERITY_PARTITION),$(hide) echo "system_verity_block_device=$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SYSTEM_VERITY_PARTITION)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_VENDOR_VERITY_PARTITION),$(hide) echo "vendor_verity_block_device=$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_VENDOR_VERITY_PARTITION)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VBOOT),$(hide) echo "vboot=$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VBOOT)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VBOOT),$(hide) echo "vboot_key=$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_VBOOT_SIGNING_KEY)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VBOOT),$(hide) echo "futility=$(FUTILITY)" >> $(1))
$(if $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VBOOT),$(hide) echo "vboot_signer_cmd=$(VBOOT_SIGNER)" >> $(1))
$(if $(filter true,$(BOARD_BUILD_SYSTEM_ROOT_IMAGE)),\
    $(hide) echo "system_root_image=true" >> $(1);\
    echo "ramdisk_dir=$(TARGET_ROOT_OUT)" >> $(1))
$(if $(2),$(hide) $(foreach kv,$(2),echo "$(kv)" >> $(1);))
endef

4.使用build_image.py脚本生成system.img镜像文件。

四.$(FULL_SYSTEMIMAGE_DEPS)

FULL_SYSTEMIMAGE_DEPS又有以下两部分组成:
FULL_SYSTEMIMAGE_DEPS := (INTERNALSYSTEMIMAGEFILES) (INTERNAL_USERIMAGES_DEPS)

1.$(INTERNAL_SYSTEMIMAGE_FILES)

INTERNAL_SYSTEMIMAGE_FILES := $(filter $(TARGET_OUT)/%, \
    $(ALL_PREBUILT) \
    $(ALL_COPIED_HEADERS) \
    $(ALL_GENERATED_SOURCES) \
    $(ALL_DEFAULT_INSTALLED_MODULES) \
    $(PDK_FUSION_SYSIMG_FILES) \
    $(RECOVERY_RESOURCE_ZIP) \

从这里就可以看出,INTERNAL_SYSTEMIMAGE_FILES描述的就是从ALL_PREBUILT、ALL_COPIED_HEADERS、ALL_GENERATED_SOURCES、ALL_DEFAULT_INSTALLED_MODULES、PDK_FUSION_SYSIMG_FILES和RECOVERY_RESOURCE_ZIP中过滤出来的存放在TARGET_OUT目录下的那些文件,即在目标产品输出目录中的system子目录下那些文件。
ALL_PREBUILT:要拷贝到目标设备上去的文件。
ALL_COPIED_HEADERS:要拷贝到目标设备上去的头文件。
ALL_GENERATED_SOURCES:要拷贝到目标设备上去的由工具自动生成的源代码文件。
ALL_DEFAULT_INSTALLED_MODULES:要安装要目标设备上的所有的模块文件。
PDK_FUSION_SYSIMG_FILES是从PDK(Platform Development Kit)提取出来的相关文件。
RECOVERY_RESOURCE_ZIP描述的是Android的recovery系统要使用的资源文件,对应于/system/etc目录下的recovery-resource.dat文件。

2.$(INTERNAL_USERIMAGES_DEPS)

ifeq ($(INTERNAL_USERIMAGES_USE_EXT),true)
INTERNAL_USERIMAGES_DEPS := $(SIMG2IMG)
INTERNAL_USERIMAGES_DEPS += $(MKEXTUSERIMG) $(MAKE_EXT4FS) $(E2FSCK)
ifeq ($(TARGET_USERIMAGES_USE_F2FS),true)
INTERNAL_USERIMAGES_DEPS += $(MKF2FSUSERIMG) $(MAKE_F2FS)
endif
endif

ifeq ($(BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE),squashfs)
INTERNAL_USERIMAGES_DEPS += $(MAKE_SQUASHFS) $(MKSQUASHFSUSERIMG) $(IMG2SIMG)
endif

ifeq ($(BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE),squashfs)
INTERNAL_USERIMAGES_DEPS += $(MAKE_SQUASHFS) $(MKSQUASHFSUSERIMG) $(IMG2SIMG)
endif

INTERNAL_USERIMAGES_BINARY_PATHS := $(sort $(dir $(INTERNAL_USERIMAGES_DEPS)))

ifeq (true,$(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_SUPPORTS_VERITY))
INTERNAL_USERIMAGES_DEPS += $(BUILD_VERITY_TREE) $(APPEND2SIMG) $(VERITY_SIGNER)
endif

SELINUX_FC := $(TARGET_ROOT_OUT)/file_contexts
INTERNAL_USERIMAGES_DEPS += $(SELINUX_FC)

从以上可以看出INTERNAL_USERIMAGES_DEPS描述的是制作system.img镜像所依赖的工具。例如,如果要制作的system.img使用的是yaffs2文件系统,那么对应工具就是mkyaffs2image。
总结:也就是四小节提供镜像打包工具和所有需要的文件,这些文件在之前的编译中已经生成好了,然后交由三小节的build-systemimage-target函数使用build_image.py生成system.img镜像文件,这个镜像文件在target/product/xxx/obj/PACKAGING/systemimage_intermediates目录下,之后再由二小节中的拷贝函数将其拷贝到target/product/xxx目录下,xxx是产品名。

  • 12
    点赞
  • 54
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
使用方法:http://blog.csdn.net/asmcvc/article/details/11770851 工具: unyaffs,mkyaffs2image 其中unyaffs有windows版本和linux版本,mkyaffs2image只有linux版本。 windows版本的unyaffs用法: 把system.img复制到unyaffs的相同目录下,cmd命令下cd到unyaffs的目录下,然后执行命令:unyaffs system.img unyaffs会把system.img解压到其目录下。 linux版本的unyaffs用法: 把unyaffs复制到/usr/bin目录下,并修改权限为可执行。 然后cd到system.img目录下(假定目录为system目录),执行命令:unyaffs system.img 然后对system目录下的文件进行修改。 注意:修改完后的文件要修改一下权限,尽量和其他文件的权限保持一致。例如:chmod 644 framework-res.apk mkyaffs2image用法: 复制到/usr/bin目录下,并修改权限为可执行。 这里以打包system目录为system.img为例,执行命令: mkyaffs2image system system.img 然后把新生成的system.img复制替换掉原:adt-bundle-windows-x86\sdk\system-images\android-17\armeabi-v7a\system.img 执行bat批处理命令启动模拟器: D:\adt-bundle-windows-x86\sdk\tools\emulator-arm.exe -avd AndroidVM -partition-size 128 这里以修改android系统启动画面为例: 打开解包目录下的\framework\framework-res.apk 替换图片:framework-res.apk\assets\images\android-logo-mask.png为下图: 然后对\framework\framework-res.apk文件重新签名,复制到linux下后修改文件权限和原来一致。 然后mkyaffs2image system system.img打包生成新的system.img,替换原来的system.img,并启动模拟器,效果图如下: 修改代码: 工具:odextools(参考:《一键odex批量合并工具odextools的重新整理与使用》)、dexopt-wrapper 其中odextools.bat的代码: 批处理有一处bug:每打包一次会把odex文件删除掉,导致在后面的打包过程中会出现找不到:system/framework/core.odex类似的错误,因此只需要在打包完后不删除odex文件即可,找到del /f !apkx!.odex 1>nul 2>nul改为:::del /f !apkx!.odex 1>nul 2>nul,也就是注释掉这一行代码。 具体使用方法(操作在windows下): 在odextools\romdir目录下创建文件夹:system 利用unyaffs解包system.img后,把所有文件复制到system目录下。 然后运行odextools.bat,如图: 选择一个需要整合odex的目录选项即可。odextools.bat会自动设置环境变量,使用baksmali.jar来反编译odex为smali,然后再调用smali.jar打包为classes.dex, 然后再打包到相应的apk包(framework目录下对应的是jar后缀的,实际上也是个apk包),最后再重新签名。 如果要修改代码,则需要把上面重新打包生成的apk文件,利用常规方法反编译后修改smali代码,例如插桩输入log信息。然后再回编译并重新签名。 最后一步:因为system.img中的apk是优化过的,apk主目录下是没有classes.dex文件的,而是一个被优化过的odex文件,用于优化启动速度。 因此需要将修改后的apk包再用dexopt-wrapper优化apk包后生成出odex文件,然后删除apk包里的classes.dex,并在相同目录下放置与apk包同名的odex文件。 按照原system目录的文件结构组织好后,目录复制到linux环境下使用mkyaffs2image重新打包成system.img
C语言编译过程是将C语言源代码转化为可以在计算机上执行的可执行文件的过程。这个过程包括了预处理、编译、汇编和链接四个主要步骤。 首先是预处理阶段,预处理器负责对源代码进行处理,将所有的宏定义、条件编译指令、头文件包含等处理为实际的C代码。预处理器会将处理后的文件保存为.i文件。 接下来是编译阶段,编译器会将预处理后的代码翻译成汇编代码,该代码使用一种特定的汇编语言表示。编译器会对代码进行语法检查、语义分析、优化等处理,并生成汇编代码。编译器将处理后的代码保存为.s文件。 然后是汇编阶段,在这个阶段,汇编器将汇编代码转化为机器码指令,这些指令可以被计算机直接执行。汇编器将处理后的代码保存为.o文件。 最后是链接阶段,链接器将多个目标文件(.o文件)和库文件进行合并,生成最终的可执行文件。链接器会解析并处理数据和函数引用,将它们与实际的定义进行链接。同时,链接器还会进行地址重定位、符号解析等操作,确保连接的正确性和可执行文件的完整性。 总结起来,C语言编译过程包括预处理、编译、汇编和链接四个步骤,分别将源代码转化为预处理后的代码、汇编代码和机器码,并最终生成可执行文件。每个阶段都有特定的处理任务和输出文件,形成了完整的编译过程
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值