美文网首页
【安卓实践】apex导致的安卓编译失败原因调查

【安卓实践】apex导致的安卓编译失败原因调查

作者: nianxing | 来源:发表于2022-06-15 11:01 被阅读0次

    背景

    在实现功能的时候,我把我的功能逻辑实现在libmeminfo.so库当中。
    由于我的功能需要调用libmemtrack.so库中的一些函数,我就在libmeminfo的Androidbp中将libmemtrack.so动态连接过来了。如下:

    cc_library {
        name: "libmeminfo",
        defaults: ["libmeminfo_defaults"],
        export_include_dirs: ["include"],
        export_shared_lib_headers: ["libbase"],
        srcs: [
            "pageacct.cpp",
            "procmeminfo.cpp",
            "sysmeminfo.cpp",
        ],
        //ADD START: {
        shared_libs: [
            "libmemtrack",
        ],
        //END}
    }
    

    这样增加之后无论是在 其他so库中调用我提供的方法,还是单独编译libmeminfo都可以编译通过,并且功能验证不会有问题。
    但是当我带patch编译整个rom包的时候,却报了以下错误:

    [ 99% 111787/112588] //art/build/apex:art-check-debug-apex-gen generate art-check-debug-apex-gen.dummy
    FAILED: out/soong/.intermediates/art/build/apex/art-check-debug-apex-gen/gen/art-check-debug-apex-gen.dummy
    rm -rf out/soong/.intermediates/art/build/apex/art-check-debug-apex-gen/gen && out/soong/host/linux-x86/bin/sbox --sandbox-path out/soong/.temp --output-root out/soong/.intermediates/art/build/apex/art-check-debug-apex-gen/gen -c 'out/soong/host/linux-x86/bin/art-apex-tester --debugfs out/soong/host/linux-x86/bin/debugfs --tmpdir __SBOX_OUT_DIR__ --debug out/soong/.intermediates/art/build/apex/com.android.runtime.debug/android_common_com.android.runtime.debug/com.android.runtime.debug.apex && touch __SBOX_OUT_FILES__'  __SBOX_OUT_DIR__/art-check-debug-apex-gen.dummy
    --bitness=auto, trying to autodetect. This may be incorrect!
      Detected multilib
    Unexpected file 'lib64/libcutils.so'
    Unexpected file 'lib64/libutils.so'
    Unexpected file 'lib64/libhwbinder.so'
    Unexpected file 'lib64/libhidlbase.so'
    Unexpected file 'lib64/libbinderthreadstate.so'
    Unexpected file 'lib64/libhidltransport.so'
    Unexpected file 'lib64/libprocessgroup.so'
    Unexpected file 'lib64/libhardware.so'
    Unexpected file 'lib64/libmemtrack.so'
    Unexpected file 'lib64/android.hardware.memtrack@1.0.so'
    No superfluous libraries checker FAILED
    

    拿到这个错误的时候,由于这个错误最多是“Unexpected file 'lib64/libmemtrack.so'”这一行与我的修改有关系,
    所以我一度觉得不是我的问题。后来调查了两个小时我才发现编译错误的原因。

    原因

    确实我的修改不会导致问题,但是在安卓编译的过程中编译com.android.runtime.debug时,编译脚本会检查/apex/com.android.runtime.debug/目录下多个目录lib/lib64/bin/以及lib/bionic等路径下是否包含非法的so库。
    如果包含非法的so库,就会在编译脚本中报错,导致rom包的编译失败。

    art/build/apex/art_apex_test.py
      def check_no_superfluous_files(self, dir_path):
        paths = []
        for name in sorted(self._provider.read_dir(dir_path).keys()):
          if name not in ('.', '..'):
            paths.append(os.path.join(dir_path, name))
        expected_paths = set()
        dir_prefix = dir_path + '/'
        for path_glob in self._expected_file_globs:
          expected_paths |= set(fnmatch.filter(paths, path_glob))
          # If there are globs in subdirectories of dir_path we want to match their
          # path segments at this directory level.
          if path_glob.startswith(dir_prefix):
            subpath = path_glob[len(dir_prefix):]
            subpath_first_segment, _, _ = subpath.partition('/')
            expected_paths |= set(fnmatch.filter(paths, dir_prefix + subpath_first_segment))
        for unexpected_path in set(paths) - expected_paths:
          self.fail('Unexpected file \'%s\'', unexpected_path)
    

    修改编译脚本,执行“make art-check-debug-apex-gen -j16”打印expected_paths如下:

    expected_paths '{'lib64/libziparchive.so', 'lib64/libz.so', 'lib64/libmeminfo.so', 'lib64/libprofile.so', 'lib64/libnpt.so', 'lib64/libart-compiler.so', 'lib64/libvixl.so', 'lib64/libc_malloc_debug.so', 'lib64/libopenjdkjvmd.so', 'lib64/libprofiled.so', 'lib64/libcrypto.so', 'lib64/libjavacore.so', 'lib64/libartd.so', 'lib64/libartbase.so', 'lib64/libartd-dexlayout.so', 'lib64/libprocinfo.so', 'lib64/libart-dexlayout.so', 'lib64/libc_malloc_hooks.so', 'lib64/libnativeloader.so', 'lib64/bionic', 'lib64/libc++.so', 'lib64/libexpat.so', 'lib64/libbase.so', 'lib64/liblzma.so', 'lib64/libunwindstack.so', 'lib64/libpac.so', 'lib64/libdt_fd_forward.so', 'lib64/libopenjdkd.so', 'lib64/libopenjdkjvmtid.so', 'lib64/libnativehelper.so', 'lib64/libicui18n.so', 'lib64/libadbconnection.so', 'lib64/libsigchain.so', 'lib64/libdexfile_support.so', 'lib64/libopenjdkjvmti.so', 'lib64/libopenjdkjvm.so', 'lib64/libartpalette.so', 'lib64/libvixld.so', 'lib64/libdexfile.so', 'lib64/libdexfile_external.so', 'lib64/libdt_socket.so', 'lib64/libopenjdk.so', 'lib64/libartd-disassembler.so', 'lib64/libandroidicu.so', 'lib64/libjdwp.so', 'lib64/libbacktrace.so', 'lib64/libart-disassembler.so', 'lib64/libartd-compiler.so', 'lib64/libnativebridge.so', 'lib64/libicuuc.so', 'lib64/libadbconnectiond.so', 'lib64/libdexfiled.so', 'lib64/libartbased.so', 'lib64/libart.so', 'lib64/libandroidio.so'}'
    

    可以看到libmeminfo.so包含在这些库当中。
    这意味着,如果我在libmeminfo.so中想要动态连接其他非expected_paths中的so库,如libmemtrack,就会在编译的时候把libmemtrack放在apex/com.anroid.runtime.debug/lib64/路径下。
    而编译脚本会检查此路径下的库是否都是expected_paths中所包含的库,如果不是,就会报错。
    而这次报错中之所以会有其他库如libhwbinder.so,原因是libmemtrack动态连接了这些库。
    至此,问题原因调查完毕。
    那只能换一种方式实现我的功能了,至少不能放在libmeminfo.so中去实现。

    相关文章

      网友评论

          本文标题:【安卓实践】apex导致的安卓编译失败原因调查

          本文链接:https://www.haomeiwen.com/subject/ilcxvrtx.html