精华内容
下载资源
问答
  • 安卓Build使用与传参

    2020-11-30 16:10:43
    安卓Build使用与传参 ** Build用法 Intent intent = new Intent(context,GoTo.class); Bundle bundle = new Bundle(); bundle.putBoolean(“boolean”, false); bundle.putString(“string”, PrisonerId); intent....

    安卓Build使用与传参

    **
    Build用法
    Intent intent = new Intent(context,GoTo.class);
    Bundle bundle = new Bundle();
    bundle.putBoolean(“boolean”, false);
    bundle.putString(“string”, PrisonerId);
    intent.putExtras(bundle);
    context.startActivity(intent);
    接受
    Bundle bundle = getIntent().getExtras();
    String str = bundle.getString(“string”);
    Boolean bool = bundle.getString(“boolean”);

    展开全文
  • 安卓 build/core/Makefile 以及main.mk android make 系统总共分为四层 arch board device product 在各个字android.mk文件中引用的定义都存放在./build/core/下! 比如android.mk中的 include (CLEARVARS)...

    安卓 build/core/Makefile 以及main.mk

    android make 系统总共分为四层

    • arch
    • board
    • device
    • product

    在各个字android.mk文件中引用的定义都存放在./build/core/下!
    比如android.mk中的
    include (CLEARVARS)它对应的是在./build/core/config.mk中的CLEARVARS:=(CLEARVARS)它对应的是在./build/core/config.mk中的CLEARVARS:=(BUILD_SYSTEM)/clear_vars.mk
    include $(BUILD_PACKAGE) 
    它对应的是在./build/core/config.mk中的BUILD_PACKAGE:=$(BUILD_SYSTEM)/package.mk

    main.mk中的模块
    .PHONY:checkbuilt
    .PHONY:prebuilt
    .PHONY: files
    .PHONY: ramdisk
    .PHONY: systemimage
    .PHONY: userdataimage
    .PHONY: bootimage
    .PHONY: recoveryimage
    .PHONY: droidcore
    .PHONY: apps_only
    .PHONY: sdk
    .PHONY: clean
    .PHONY: clobber
    .PHONY: modules
    .PHONY: showcommands


    在一个makefile文件中,可以一次性的make出多个目标!每个独立的目标其结构大体如下

    LOCAL_PATH:=(call my-dir) //获取当前目录 #include(call my-dir) //获取当前目录 #include(CLEAR_VARS) //make系统为子模块定义了很多的私有变量,这个调用是为了初始化所有的私有变量
    ...
    //里面的内容根据不同的需要会出现不同的LOCAL变量
    ...
    #include $(BUILD_XXX) //执行编译任务


    编译APK
    LOCAL_SRC_FILES:=(callall−subdir−java−files)LOCALPACKAGENAME:=packageNameinclude(callall−subdir−java−files)LOCALPACKAGENAME:=packageNameinclude(BUILD_PACKAGE)

    编译依赖静态java库的应用程序
    LOCAL_STATIC_JAVA_LIBRARIES:=static-library
    LOCAL_SRC_FILES:=(callall−subdir−java−files)LOCALPACKAGENAME:=packageNameinclude(callall−subdir−java−files)LOCALPACKAGENAME:=packageNameinclude(BUILD_PACKAGE)

    编译一个需要用平台key签名的应用程序
    LOCAL_SRC_FILES:=$(call all-subdir-java-files)
    LOCAL_PACKAGE_NAME:=packageName
    LOCAL_CERTIFICATE:=platform
    include (BUILDPACKAGE)编译一个需要特定key的应用程序LOCALSRCFILES:=(BUILDPACKAGE)编译一个需要特定key的应用程序LOCALSRCFILES:=(call all-subdir-java-files)
    LOCAL_PACKAGE_NAME := LocalPackage
    LOCAL_CERTIFICATE := vendor/example/certs/app
    include (BUILDPACKAGE)添加一个预编译应用程序LOCALSRCFILES:=(BUILDPACKAGE)添加一个预编译应用程序LOCALSRCFILES:=(LOCAL_MODULE).apk
    LOCAL_MODULE := LocalModuleName
    LOCAL_MODULE_CLASS := APPS
    LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)

    include (BUILDPREBUILT)LOCALSRCFILES:=(BUILDPREBUILT)LOCALSRCFILES:=(call all-subdir-java-files)
    LOCAL_JAVA_LIBRARIES := android.test.runner
    LOCAL_MODULE := sample
    include $(BUILD_STATIC_JAVA_LIBRARY) 

    常用的mk分类
    Android.mk 用来编译模块或者apk的,module对应native code,package对应于java
    AndroidProducts.mk 设置product,设置系统包含了那些应用
    target_<os>-<arch>.mk,host_<os>-<arch>.mk,<os>-<arch>.mk 针对不同的系统和CPU架框进行设置
    BoardConfig.mk 设置主板用的,比如driver的选择

    ./build/core/Makefile 定义了image是如何生成的

    frameworks/base/core/java 扩展SDK时,可以向里面添加自己的类

    make参数
    build/envsetup.sh 可以设置环境,运行之后会支持mm命令,使make支持只编译一个模块
    buildspec.mk

    用户也可以通过mm来编译指定模块,或者通过make clean-module_name来删除指定模块。

    make ONE_SHOT_MAKEFILE=<path to Androiod.mk>

    通过CREATE_MODULE_INFO_FILE,build system会将所有的模块信息列在$(PRODUCT_OUT)/module-info.txt中

    make CREATE_MODULE_INFO_FILE=true 产生单个的image文件,用以早期的硬件测试
    HOST_BUILD_TYPE 和 TARGET_BUILD_TYPE 用来设置是debug还是release,debug的带有调试信息,这两个参数也可以在 buildspec.mk中进行设置以防止在别处被重复指定

    其它的一些变量
    LOCAL_AAPT_FLAGS
    LOCAL_ACP_UNAVAILABL
    LOCAL_ADDITIONAL_JAVA_DIR
    LOCAL_AIDL_INCLUDES
    LOCAL_ALLOW_UNDEFINED_SYMBOLS
    LOCAL_ARM_MODE
    LOCAL_ASFLAGS
    LOCAL_ASSET_DIR
    LOCAL_ASSET_FILES 在与BUILD_PACKAGE一起时有效,表示资源文件
    LOCAL_BUILT_MODULE_STEM
    LOCAL_C_INCLUDES 用来指定外面的头文件路径
    LOCAL_CC 可以指定C编译器
    LOCAL_JAR_MANIFEST
    LOCAL_JARJAR_RULES
    LOCAL_JAR_PATH
    LOCAL_SHARED_LIBRARIES 可链接动态库
    LOCAL_SRC_FILES 编译源文件
    LOCAL_STATIC_JAVA_LIBRARIES
    LOCAL_STATIC_LIBRARIES 可链接静态库
    LOCAL_UNINSTALLABLE_MODULE
    LOCAL_WHOLE_STATIC_LIBRARIES 禁止在连接时删除库中的无用代码
    LOCAL_FORCE_STATIC_EXECUTABLE 如果编译的可执行程序要进行静态链接(执行时不依赖于任何动态库)
    LOCAL_JAVA_LIBRARIES 编译java应用程序和库的时候指定包含的java类库,目前有core和framework两种
                         多数情况下定义成:LOCAL_JAVA_LIBRARIES := core framework
                         注意LOCAL_JAVA_LIBRARIES不是必须的,而且编译APK时不允许定义(系统会自动添加)




    envsetup.mk主要会读取由envsetup.sh写入环境变量中的一些变量来配置 编译过程中的输出目录
    config.mk里面定义了各种module所需要的工具,以及如何来编译各个模块
    CLEAR_VARS:= (BUILDSYSTEM)/clearvars.mkBUILDHOSTSTATICLIBRARY:=(BUILDSYSTEM)/clearvars.mkBUILDHOSTSTATICLIBRARY:=(BUILD_SYSTEM)/host_static_library.mk
    BUILD_HOST_SHARED_LIBRARY:= (BUILDSYSTEM)/hostsharedlibrary.mkBUILDSTATICLIBRARY:=(BUILDSYSTEM)/hostsharedlibrary.mkBUILDSTATICLIBRARY:=(BUILD_SYSTEM)/static_library.mk
    BUILD_RAW_STATIC_LIBRARY := (BUILDSYSTEM)/rawstaticlibrary.mkBUILDSHAREDLIBRARY:=(BUILDSYSTEM)/rawstaticlibrary.mkBUILDSHAREDLIBRARY:=(BUILD_SYSTEM)/shared_library.mk
    BUILD_EXECUTABLE:= (BUILDSYSTEM)/executable.mkBUILDRAWEXECUTABLE:=(BUILDSYSTEM)/executable.mkBUILDRAWEXECUTABLE:=(BUILD_SYSTEM)/raw_executable.mk
    BUILD_HOST_EXECUTABLE:= (BUILDSYSTEM)/hostexecutable.mkBUILDPACKAGE:=(BUILDSYSTEM)/hostexecutable.mkBUILDPACKAGE:=(BUILD_SYSTEM)/package.mk
    BUILD_HOST_PREBUILT:= (BUILDSYSTEM)/hostprebuilt.mkBUILDPREBUILT:=(BUILDSYSTEM)/hostprebuilt.mkBUILDPREBUILT:=(BUILD_SYSTEM)/prebuilt.mk
    BUILD_MULTI_PREBUILT:= (BUILDSYSTEM)/multiprebuilt.mkBUILDJAVALIBRARY:=(BUILDSYSTEM)/multiprebuilt.mkBUILDJAVALIBRARY:=(BUILD_SYSTEM)/java_library.mk
    BUILD_STATIC_JAVA_LIBRARY:= (BUILDSYSTEM)/staticjavalibrary.mkBUILDHOSTJAVALIBRARY:=(BUILDSYSTEM)/staticjavalibrary.mkBUILDHOSTJAVALIBRARY:=(BUILD_SYSTEM)/host_java_library.mk
    BUILD_DROIDDOC:= (BUILDSYSTEM)/droiddoc.mkBUILDCOPYHEADERS:=(BUILDSYSTEM)/droiddoc.mkBUILDCOPYHEADERS:=(BUILD_SYSTEM)/copy_headers.mk
    BUILD_KEY_CHAR_MAP := $(BUILD_SYSTEM)/key_char_map.mk
    以上的*.mk中都包含了base_rules.mk

    products设置
    ./build/target/product/AndroidProducts.mk
    module设置
    native code和java的一些通用方法都在./build/core/definitions.mk中
    BUILD_SHARE_xxx等变量在./build/core/config.mk中
    Board
    ./build/target/board/(TARGETDEVICE)/BoardConfig.mk./vendor/∗/(TARGETDEVICE)/BoardConfig.mk./vendor/∗/(TARGET_DEVICE)/BoardConfig.mk 
    rules相关
    与 LOCAL_MODULE_TAGS相关的定义


    include (BUILDSTATICLIBRARY)编译成静态库include(BUILDSTATICLIBRARY)编译成静态库include(BUILD_SHARED_LIBRARY) 编译成动态库。
    include (BUILDEXECUTABLE)编译成可执行程序常用函数callmy−dircallall−subdir−java−filescallall−java−files−undercallall−makefiles−under,(BUILDEXECUTABLE)编译成可执行程序常用函数callmy−dircallall−subdir−java−filescallall−java−files−undercallall−makefiles−under,(LOCAL_PATH)
    call all-clean-step
    call import-module,android/native_app_glue
    call inherit-product,xxx.mk
    call inherit-product-if-exists
    call device-test
    call include-path-for,libpagemap
    call dist-for-goals,dist_files,(LOCALBUILTMODULE)calladd−charger−image,(LOCALBUILTMODULE)calladd−charger−image,(_img)
    call libfilterfw-all-java-files-under,(1)calllibfilterfwtodocument,(1)calllibfilterfwtodocument,(LOCAL_PATH)
    call intermediates-dir-for,EXECUTABLES,(LOCALMODULE,true)callall−named−subdir−makefiles,(LOCALMODULE,true)callall−named−subdir−makefiles,(legacy_modules)
    call RM;call MKDIR
    call emugl-begin-host-shared-library,libEGL_translator
    call emugl-import,libOpenglOsUtils
    call emugl-end-module
    call emugl-export,LDLIBS,-lGL
    cal emugl-export,LDFLAGS,(GLCOMMONLINKERFLAGS)callemugl−set−shared−library−subpath,hwcallemugl−export,CINCLUDES,(GLCOMMONLINKERFLAGS)callemugl−set−shared−library−subpath,hwcallemugl−export,CINCLUDES,(intermediates)
    call all-makefiles-under,$(LOCAL_PATH) 这个和下面的区别还不清楚
    call all-subdis-makefiles 这个是通常出现在整个makefile的尾部,以实现递归调用子目录中的makefile,使整个make系统成为一个树状结构

    展开全文
  • 安卓build.prop教程

    2012-10-10 19:43:11
    build.prop文件可以控制整个安卓系统的流畅性
  • 安卓上的Build.prop参数详解,包含Dalvik虚拟机相关的参数属性,系统版本、定义等参数,基本性能相关参数
  • 安卓BuildConfig与DEBUG模式

    千次阅读 2018-11-27 15:21:59
    安卓项目中Mobule的build.gradle文件中buildConfigField和manifestPlaceholders都可以定义常量, 我们今天说的BuildConfig就是用buildConfigField定义的常量。如下所示: android { compileSdkVersion LIBRARY...
    在安卓项目中Mobule的build.gradle文件中buildConfigField和manifestPlaceholders都可以定义常量,
    我们今天说的BuildConfig就是用buildConfigField定义的常量。如下所示:
    
    android {
        compileSdkVersion LIBRARY_COMPILE_SDK_VERSION
        buildToolsVersion LIBRARY_BUILD_TOOLS_VERSION
    
        defaultConfig {
            applicationId "。。。"
            minSdkVersion LIBRARY_MIN_SDK_VERSION
            targetSdkVersion LIBRARY_TARGET_SDK_VERSION // 不使用api23的动态权限策略(因为xutils)
            versionCode 87
            versionName "5.1.0"
            multiDexEnabled true // 分dex
            manifestPlaceholders = [
            ]
            buildConfigField("String", "VERSION_TIME", "\""+new Date().format("yyyy.MM.dd")+"\"")

    用buildConfigField定义的常量会生成在工程的BuildConfig中,然后我们就发现了一些常用的比如:

    DEBUG APPLICATION_ID FLAVOR VERSION_CODE VERSION_NAME等等
    public final class BuildConfig {
      public static final boolean DEBUG = Boolean.parseBoolean("true");
      public static final String APPLICATION_ID = "com.irenshi.personneltreasure";
      public static final String BUILD_TYPE = "debug";
      public static final String FLAVOR = "baidu";
      public static final int VERSION_CODE = 87;
      public static final String VERSION_NAME = "5.1.0";
      // Fields from default config.
      public static final String VERSION_TIME = "2018.11.27";
    }

    那我们如何在代码中使用这些常量呢?看下面这个例子:

    public class LogUtil {
        public static void i(String message){
            if(BuildConfig.DEBUG){
                Log.i(generateTag(), message);
            }
        }
        public static void i(String tag,String message){
            if(BuildConfig.DEBUG){
                Log.i(tag, message);
            }
        }
        private static String generateTag() {
            StackTraceElement sElements = new Throwable().getStackTrace()[2];
            String className = sElements.getFileName();
            String methodName = sElements.getMethodName();
            int lineNumber = sElements.getLineNumber();
            return String.format("%s:%s(%s:%d)", className, methodName,className, lineNumber);
        }
    }

    如果是dubug包输出log信息,如果是release也就是线上版本,我们屏蔽掉log输入。

    当然这些常量的应用不只这些,比如我们有时候要确认包的版本VERSION_NAME,

    有时候我们会比较版本新旧VERSION_CODE,

    有时候我们要获取APPLICATION_ID,

    有时候不同的应用商店不同包,也就是我们常说的渠道FLAVOR,

    这里还有一个我们自定义的VERSION_TIME,打包的时间。

    这样是不是方便管理多了呢。

    展开全文
  • 理解安卓build系统

    2015-11-06 18:18:27
    ...理解 Android Build 系统 Android Build 系统是用来编译 Android 系统,Android SDK 以及相关文档的一套框架。众所周知,Android 是一个开源的操作系统。Android 的源码中包含了许

    http://www.ibm.com/developerworks/cn/opensource/os-cn-android-build/

    理解 Android Build 系统

    Android Build 系统是用来编译 Android 系统,Android SDK 以及相关文档的一套框架。众所周知,Android 是一个开源的操作系统。Android 的源码中包含了许许多多的模块。 不同产商的不同设备对于 Android 系统的定制都是不一样的。如何将这些模块统一管理起来,如何能够在不同的操作系统上进行编译,如何在编译时能够支持面向不同的硬件设备,不同的编译类型,且还要提供面向各个产商的定制扩展,是非常有难度的。 但 Android Build 系统很好的解决了这些问题,这里面有很多值得我们开发人员学习的地方。对于 Android 平台开发人员来说,本文可以帮助你熟悉你每天接触到的构建环境。对于其他开发人员来说,本文可以作为一个 GNU Make 的使用案例,学习这些成功案例,可以提升我们的开发经验。

    强 波, Java 软件工程师, 富士通南大软件技术有限公司

    2013 年 3 月 28 日

    • +内容

    前言

    Android Build 系统是 Android 源码的一部分。关于如何获取 Android 源码,请参照 Android Source 官方网站:

    http://source.android.com/source/downloading.html

    Android Build 系统用来编译 Android 系统,Android SDK 以及相关文档。该系统主要由 Make 文件,Shell 脚本以及 Python 脚本组成,其中最主要的是 Make 文件。

    众所周知,Android 是一个开源的操作系统。Android 的源码中包含了大量的开源项目以及许多的模块。不同产商的不同设备对于 Android 系统的定制都是不一样的。

    如何将这些项目和模块的编译统一管理起来,如何能够在不同的操作系统上进行编译,如何在编译时能够支持面向不同的硬件设备,不同的编译类型,且还要提供面向各个产商的定制扩展,是非常有难度的。

    但 Android Build 系统很好的解决了这些问题,这里面有很多值得我们开发人员学习的地方。

    对于 Android 平台开发人员来说,本文可以帮助你熟悉你每天接触到的构建环境。

    对于其他开发人员来说,本文可以作为一个 GNU Make 的使用案例,学习这些成功案例,可以提升我们的开发经验。

    概述

    Build 系统中最主要的处理逻辑都在 Make 文件中,而其他的脚本文件只是起到一些辅助作用,由于篇幅所限,本文只探讨 Make 文件中的内容。

    整个 Build 系统中的 Make 文件可以分为三类:

    第一类是 Build 系统核心文件,此类文件定义了整个 Build 系统的框架,而其他所有 Make 文件都是在这个框架的基础上编写出来的。

    图 1 是 Android 源码树的目录结构,Build 系统核心文件全部位于 /build/core(本文所提到的所有路径都是以 Android 源码树作为背景的,“/”指的是源码树的根目录,与文件系统无关)目录下。

    图 1. Android 源码树的目录结构
    图 1. Android 源码树的目录结构

    第二类是针对某个产品(一个产品可能是某个型号的手机或者平板电脑)的 Make 文件,这些文件通常位于 device 目录下,该目录下又以公司名以及产品名分为两级目录,图 2 是 device 目录下子目录的结构。对于一个产品的定义通常需要一组文件,这些文件共同构成了对于这个产品的定义。例如,/device/sony/it26 目录下的文件共同构成了对于 Sony LT26 型号手机的定义。

    图 2. device 目录下子目录的结构
    图 2. device 目录下子目录的结构

    第三类是针对某个模块(关于模块后文会详细讨论)的 Make 文件。整个系统中,包含了大量的模块,每个模块都有一个专门的 Make 文件,这类文件的名称统一为“Android.mk”,该文件中定义了如何编译当前模块。Build 系统会在整个源码树中扫描名称为“Android.mk”的文件并根据其中的内容执行模块的编译。

    编译 Android 系统

    执行编译

    Android 系统的编译环境目前只支持 Ubuntu 以及 Mac OS 两种操作系统。关于编译环境的构建方法请参见以下路径:http://source.android.com/source/initializing.html

    在完成编译环境的准备工作以及获取到完整的 Android 源码之后,想要编译出整个 Android 系统非常的容易:

    打开控制台之后转到 Android 源码的根目录,然后执行如清单 1 所示的三条命令即可("$"是命令提示符,不是命令的一部分。):

    完整的编译时间依赖于编译主机的配置,在笔者的 Macbook Pro(OS X 10.8.2, i7 2G CPU,8G RAM, 120G SSD)上使用 8 个 Job 同时编译共需要一个半小时左右的时间。

    清单 1. 编译 Android 系统
     $ source build/envsetup.sh 
     $ lunch full-eng 
     $ make -j8

    这三行命令的说明如下:

    第一行命令“source build/envsetup.sh”引入了 build/envsetup.sh脚本。该脚本的作用是初始化编译环境,并引入一些辅助的 Shell 函数,这其中就包括第二步使用 lunch 函数。

    除此之外,该文件中还定义了其他一些常用的函数,它们如表 1 所示:

    表 1. build/envsetup.sh 中定义的常用函数
    名称 说明
    croot 切换到源码树的根目录
    m 在源码树的根目录执行 make
    mm Build 当前目录下的模块
    mmm Build 指定目录下的模块
    cgrep 在所有 C/C++ 文件上执行 grep
    jgrep 在所有 Java 文件上执行 grep
    resgrep 在所有 res/*.xml 文件上执行 grep
    godir 转到包含某个文件的目录路径
    printconfig 显示当前 Build 的配置信息
    add_lunch_combo 在 lunch 函数的菜单中添加一个条目

    第二行命令“lunch full-eng”是调用 lunch 函数,并指定参数为“full-eng”。lunch 函数的参数用来指定此次编译的目标设备以及编译类型。在这里,这两个值分别是“full”和“eng”。“full”是 Android 源码中已经定义好的一种产品,是为模拟器而设置的。而编译类型会影响最终系统中包含的模块,关于编译类型将在表 7 中详细讲解。

    如果调用 lunch 函数的时候没有指定参数,那么该函数将输出列表以供选择,该列表类似图 3 中的内容(列表的内容会根据当前 Build 系统中包含的产品配置而不同,具体参见后文“添加新的产品”),此时可以通过输入编号或者名称进行选择。

    图 3. lunch 函数的输出
    图 3. lunch 函数的输出

    第三行命令“make -j8”才真正开始执行编译。make 的参数“-j”指定了同时编译的 Job 数量,这是个整数,该值通常是编译主机 CPU 支持的并发线程总数的 1 倍或 2 倍(例如:在一个 4 核,每个核支持两个线程的 CPU 上,可以使用 make -j8 或 make -j16)。在调用 make 命令时,如果没有指定任何目标,则将使用默认的名称为“droid”目标,该目标会编译出完整的 Android 系统镜像。

    Build 结果的目录结构

    所有的编译产物都将位于 /out 目录下,该目录下主要有以下几个子目录:

    • /out/host/:该目录下包含了针对主机的 Android 开发工具的产物。即 SDK 中的各种工具,例如:emulator,adb,aapt 等。
    • /out/target/common/:该目录下包含了针对设备的共通的编译产物,主要是 Java 应用代码和 Java 库。
    • /out/target/product/<product_name>/:包含了针对特定设备的编译结果以及平台相关的 C/C++ 库和二进制文件。其中,<product_name>是具体目标设备的名称。
    • /out/dist/:包含了为多种分发而准备的包,通过“make disttarget”将文件拷贝到该目录,默认的编译目标不会产生该目录。

    Build 生成的镜像文件

    Build 的产物中最重要的是三个镜像文件,它们都位于 /out/target/product/<product_name>/ 目录下。

    这三个文件是:

    • system.img:包含了 Android OS 的系统文件,库,可执行文件以及预置的应用程序,将被挂载为根分区。
    • ramdisk.img:在启动时将被 Linux 内核挂载为只读分区,它包含了 /init 文件和一些配置文件。它用来挂载其他系统镜像并启动 init 进程。
    • userdata.img:将被挂载为 /data,包含了应用程序相关的数据以及和用户相关的数据。

    Make 文件说明

    整个 Build 系统的入口文件是源码树根目录下名称为“Makefile”的文件,当在源代码根目录上调用 make 命令时,make 命令首先将读取该文件。

    Makefile 文件的内容只有一行:“include build/core/main.mk”。该行代码的作用很明显:包含 build/core/main.mk 文件。在 main.mk 文件中又会包含其他的文件,其他文件中又会包含更多的文件,这样就引入了整个 Build 系统。

    这些 Make 文件间的包含关系是相当复杂的,图 3 描述了这种关系,该图中黄色标记的文件(且除了 $开头的文件)都位于 build/core/ 目录下。

    图 4. 主要的 Make 文件及其包含关系
    图 4. 主要的 Make 文件及其包含关系

    表 2 总结了图 4 中提到的这些文件的作用:

    表 2. 主要的 Make 文件的说明
    文件名 说明
    main.mk 最主要的 Make 文件,该文件中首先将对编译环境进行检查,同时引入其他的 Make 文件。另外,该文件中还定义了几个最主要的 Make 目标,例如 droid,sdk,等(参见后文“Make 目标说明”)。
    help.mk 包含了名称为 help 的 Make 目标的定义,该目标将列出主要的 Make 目标及其说明。
    pathmap.mk 将许多头文件的路径通过名值对的方式定义为映射表,并提供 include-path-for 函数来获取。例如,通过$(call include-path-for, frameworks-native)便可以获取到 framework 本地代码需要的头文件路径。
    envsetup.mk 配置 Build 系统需要的环境变量,例如:TARGET_PRODUCT,TARGET_BUILD_VARIANT,HOST_OS,HOST_ARCH 等。
    当前编译的主机平台信息(例如操作系统,CPU 类型等信息)就是在这个文件中确定的。
    另外,该文件中还指定了各种编译结果的输出路径。
    combo/select.mk 根据当前编译器的平台选择平台相关的 Make 文件。
    dumpvar.mk 在 Build 开始之前,显示此次 Build 的配置信息。
    config.mk 整个 Build 系统的配置文件,最重要的 Make 文件之一。该文件中主要包含以下内容:
    • 定义了许多的常量来负责不同类型模块的编译。
    • 定义编译器参数以及常见文件后缀,例如 .zip,.jar.apk。
    • 根据 BoardConfig.mk 文件,配置产品相关的参数。
    • 设置一些常用工具的路径,例如 flex,e2fsck,dx。
    definitions.mk 最重要的 Make 文件之一,在其中定义了大量的函数。这些函数都是 Build 系统的其他文件将用到的。例如:my-dir,all-subdir-makefiles,find-subdir-files,sign-package 等,关于这些函数的说明请参见每个函数的代码注释。
    distdir.mk 针对 dist 目标的定义。dist 目标用来拷贝文件到指定路径。
    dex_preopt.mk 针对启动 jar 包的预先优化。
    pdk_config.mk 顾名思义,针对 pdk(Platform Developement Kit)的配置文件。
    ${ONE_SHOT_MAKEFILE} ONE_SHOT_MAKEFILE 是一个变量,当使用“mm”编译某个目录下的模块时,此变量的值即为当前指定路径下的 Make 文件的路径。
    ${subdir_makefiles} 各个模块的 Android.mk 文件的集合,这个集合是通过 Python 脚本扫描得到的。
    post_clean.mk 在前一次 Build 的基础上检查当前 Build 的配置,并执行必要清理工作。
    legacy_prebuilts.mk 该文件中只定义了 GRANDFATHERED_ALL_PREBUILT 变量。
    Makefile 被 main.mk 包含,该文件中的内容是辅助 main.mk 的一些额外内容。

    Android 源码中包含了许多的模块,模块的类型有很多种,例如:Java 库,C/C++ 库,APK 应用,以及可执行文件等 。并且,Java 或者 C/C++ 库还可以分为静态的或者动态的,库或可执行文件既可能是针对设备(本文的“设备”指的是 Android 系统将被安装的设备,例如某个型号的手机或平板)的也可能是针对主机(本文的“主机”指的是开发 Android 系统的机器,例如装有 Ubuntu 操作系统的 PC 机或装有 MacOS 的 iMac 或 Macbook)的。不同类型的模块的编译步骤和方法是不一样,为了能够一致且方便的执行各种类型模块的编译,在 config.mk 中定义了许多的常量,这其中的每个常量描述了一种类型模块的编译方式,这些常量有:

    • BUILD_HOST_STATIC_LIBRARY
    • BUILD_HOST_SHARED_LIBRARY
    • BUILD_STATIC_LIBRARY
    • BUILD_SHARED_LIBRARY
    • BUILD_EXECUTABLE
    • BUILD_HOST_EXECUTABLE
    • BUILD_PACKAGE
    • BUILD_PREBUILT
    • BUILD_MULTI_PREBUILT
    • BUILD_HOST_PREBUILT
    • BUILD_JAVA_LIBRARY
    • BUILD_STATIC_JAVA_LIBRARY
    • BUILD_HOST_JAVA_LIBRARY

    通过名称大概就可以猜出每个变量所对应的模块类型。(在模块的 Android.mk 文件中,只要包含进这里对应的常量便可以执行相应类型模块的编译。对于 Android.mk 文件的编写请参见后文:“添加新的模块”。)

    这些常量的值都是另外一个 Make 文件的路径,详细的编译方式都是在对应的 Make 文件中定义的。这些常量和 Make 文件的是一一对应的,对应规则也很简单:常量的名称是 Make 文件的文件名除去后缀全部改为大写然后加上“BUILD_”作为前缀。例如常量 BUILD_HOST_PREBUILT 的值对应的文件就是 host_prebuilt.mk。

    这些 Make 文件的说明如表 3 所示:

    表 3. 各种模块的编译方式的定义文件
    文件名 说明
    host_static_library.mk 定义了如何编译主机上的静态库。
    host_shared_library.mk 定义了如何编译主机上的共享库。
    static_library.mk 定义了如何编译设备上的静态库。
    shared_library.mk 定义了如何编译设备上的共享库。
    executable.mk 定义了如何编译设备上的可执行文件。
    host_executable.mk 定义了如何编译主机上的可执行文件。
    package.mk 定义了如何编译 APK 文件。
    prebuilt.mk 定义了如何处理一个已经编译好的文件 ( 例如 Jar 包 )。
    multi_prebuilt.mk 定义了如何处理一个或多个已编译文件,该文件的实现依赖 prebuilt.mk。
    host_prebuilt.mk 处理一个或多个主机上使用的已编译文件,该文件的实现依赖 multi_prebuilt.mk。
    java_library.mk 定义了如何编译设备上的共享 Java 库。
    static_java_library.mk 定义了如何编译设备上的静态 Java 库。
    host_java_library.mk 定义了如何编译主机上的共享 Java 库。

    不同类型的模块的编译过程会有一些相同的步骤,例如:编译一个 Java 库和编译一个 APK 文件都需要定义如何编译 Java 文件。因此,表 3 中的这些 Make 文件的定义中会包含一些共同的代码逻辑。为了减少代码冗余,需要将共同的代码复用起来,复用的方式是将共同代码放到专门的文件中,然后在其他文件中包含这些文件的方式来实现的。这些包含关系如图 5 所示。由于篇幅关系,这里就不再对其他文件做详细描述(其实这些文件从文件名称中就可以大致猜出其作用)。

    图 5. 模块的编译方式定义文件的包含关系
    图 5. 模块的编译方式定义文件的包含关系

    Make 目标说明

    make /make droid

    如果在源码树的根目录直接调用“make”命令而不指定任何目标,则会选择默认目标:“droid”(在 main.mk 中定义)。因此,这和执行“make droid”效果是一样的。

    droid 目标将编译出整个系统的镜像。从源代码到编译出系统镜像,整个编译过程非常复杂。这个过程并不是在 droid 一个目标中定义的,而是 droid 目标会依赖许多其他的目标,这些目标的互相配合导致了整个系统的编译。

    图 6 描述了 droid 目标所依赖的其他目标:

    图 6. droid 目标所依赖的其他 Make 目标
    图 6. droid 目标所依赖的其他 Make 目标

    图 6 中这些目标的说明如表 4 所示:

    表 4. droid 所依赖的其他 Make 目标的说明
    名称 说明
    apps_only 该目标将编译出当前配置下不包含 user,userdebug,eng 标签(关于标签,请参见后文“添加新的模块”)的应用程序。
    droidcore 该目标仅仅是所依赖的几个目标的组合,其本身不做更多的处理。
    dist_files 该目标用来拷贝文件到 /out/dist 目录。
    files 该目标仅仅是所依赖的几个目标的组合,其本身不做更多的处理。
    prebuilt 该目标依赖于 $(ALL_PREBUILT)$(ALL_PREBUILT)的作用就是处理所有已编译好的文件。
    $(modules_to_install) modules_to_install 变量包含了当前配置下所有会被安装的模块(一个模块是否会被安装依赖于该产品的配置文件,模块的标签等信息),因此该目标将导致所有会被安装的模块的编译。
    $(modules_to_check) 该目标用来确保我们定义的构建模块是没有冗余的。
    $(INSTALLED_ANDROID_INFO_TXT_TARGET) 该目标会生成一个关于当前 Build 配置的设备信息的文件,该文件的生成路径是:out/target/product/<product_name>/android-info.txt
    systemimage 生成 system.img。
    $(INSTALLED_BOOTIMAGE_TARGET) 生成 boot.img。
    $(INSTALLED_RECOVERYIMAGE_TARGET) 生成 recovery.img。
    $(INSTALLED_USERDATAIMAGE_TARGET) 生成 userdata.img。
    $(INSTALLED_CACHEIMAGE_TARGET) 生成 cache.img。
    $(INSTALLED_FILES_FILE) 该目标会生成 out/target/product/<product_name>/ installed-files.txt 文件,该文件中内容是当前系统镜像中已经安装的文件列表。

    其他目标

    Build 系统中包含的其他一些 Make 目标说明如表 5 所示:

    表 5. 其他主要 Make 目标
    Make 目标 说明
    make clean 执行清理,等同于:rm -rf out/。
    make sdk 编译出 Android 的 SDK。
    make clean-sdk 清理 SDK 的编译产物。
    make update-api 更新 API。在 framework API 改动之后,需要首先执行该命令来更新 API,公开的 API 记录在 frameworks/base/api 目录下。
    make dist 执行 Build,并将 MAKECMDGOALS 变量定义的输出文件拷贝到 /out/dist 目录。
    make all 编译所有内容,不管当前产品的定义中是否会包含。
    make help 帮助信息,显示主要的 make 目标。
    make snod 从已经编译出的包快速重建系统镜像。
    make libandroid_runtime 编译所有 JNI framework 内容。
    makeframework 编译所有 Java framework 内容。
    makeservices 编译系统服务和相关内容。
    make <local_target> 编译一个指定的模块,local_target 为模块的名称。
    make clean-<local_target> 清理一个指定模块的编译结果。
    makedump-products 显示所有产品的编译配置信息,例如:产品名,产品支持的地区语言,产品中会包含的模块等信息。
    makePRODUCT-xxx-yyy 编译某个指定的产品。
    makebootimage 生成 boot.img
    makerecoveryimage 生成 recovery.img
    makeuserdataimage 生成 userdata.img
    makecacheimage 生成 cache.img

    在 Build 系统中添加新的内容

    添加新的产品

    当我们要开发一款新的 Android 产品的时候,我们首先就需要在 Build 系统中添加对于该产品的定义。

    在 Android Build 系统中对产品定义的文件通常位于 device 目录下(另外还有一个可以定义产品的目录是 vender 目录,这是个历史遗留目录,Google 已经建议不要在该目录中进行定义,而应当选择 device 目录)。device 目录下根据公司名以及产品名分为二级目录,这一点我们在概述中已经提到过。

    通常,对于一个产品的定义通常至少会包括四个文件:AndroidProducts.mk,产品版本定义文件,BoardConfig.mk 以及 verndorsetup.sh。下面我们来详细说明这几个文件。

    • AndroidProducts.mk:该文文件中的内容很简单,其中只需要定义一个变量,名称为“PRODUCT_MAKEFILES”,该变量的值为产品版本定义文件名的列表,例如:
     PRODUCT_MAKEFILES := \ 
     $(LOCAL_DIR)/full_stingray.mk \ 
     $(LOCAL_DIR)/stingray_emu.mk \ 
     $(LOCAL_DIR)/generic_stingray.mk
    • 产品版本定义文件:顾名思义,该文件中包含了对于特定产品版本的定义。该文件可能不只一个,因为同一个产品可能会有多种版本(例如,面向中国地区一个版本,面向美国地区一个版本)。该文件中可以定义的变量以及含义说明如表 6 所示:
    表 6. 产品版本定义文件中的变量及其说明
    常量 说明
    PRODUCT_NAME 最终用户将看到的完整产品名,会出现在“关于手机”信息中。
    PRODUCT_MODEL 产品的型号,这也是最终用户将看到的。
    PRODUCT_LOCALES 该产品支持的地区,以空格分格,例如:en_GB de_DE es_ES fr_CA。
    PRODUCT_PACKAGES 该产品版本中包含的 APK 应用程序,以空格分格,例如:Calendar Contacts。
    PRODUCT_DEVICE 该产品的工业设计的名称。
    PRODUCT_MANUFACTURER 制造商的名称。
    PRODUCT_BRAND 该产品专门定义的商标(如果有的话)。
    PRODUCT_PROPERTY_OVERRIDES 对于商品属性的定义。
    PRODUCT_COPY_FILES 编译该产品时需要拷贝的文件,以“源路径 : 目标路径”的形式。
    PRODUCT_OTA_PUBLIC_KEYS 对于该产品的 OTA 公开 key 的列表。
    PRODUCT_POLICY 产品使用的策略。
    PRODUCT_PACKAGE_OVERLAYS 指出是否要使用默认的资源或添加产品特定定义来覆盖。
    PRODUCT_CONTRIBUTORS_FILE HTML 文件,其中包含项目的贡献者。
    PRODUCT_TAGS 该产品的标签,以空格分格。

    通常情况下,我们并不需要定义所有这些变量。Build 系统的已经预先定义好了一些组合,它们都位于 /build/target/product 下,每个文件定义了一个组合,我们只要继承这些预置的定义,然后再覆盖自己想要的变量定义即可。例如:

     # 继承 full_base.mk 文件中的定义
     $(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk) 
     # 覆盖其中已经定义的一些变量
     PRODUCT_NAME := full_lt26 
     PRODUCT_DEVICE := lt26 
     PRODUCT_BRAND := Android 
     PRODUCT_MODEL := Full Android on LT26
    • BoardConfig.mk:该文件用来配置硬件主板,它其中定义的都是设备底层的硬件特性。例如:该设备的主板相关信息,Wifi 相关信息,还有 bootloader,内核,radioimage 等信息。对于该文件的示例,请参看 Android 源码树已经有的文件。
    • vendorsetup.sh:该文件中作用是通过 add_lunch_combo 函数在 lunch 函数中添加一个菜单选项。该函数的参数是产品名称加上编译类型,中间以“-”连接,例如:add_lunch_combo full_lt26-userdebug。/build/envsetup.sh 会扫描所有 device 和 vender 二 级目 录下的名称 为"vendorsetup.sh"文件,并根据其中的内容来确定 lunch 函数的 菜单选项。

    在配置了以上的文件之后,便可以编译出我们新添加的设备的系统镜像了。

    首先,调用“source build/envsetup.sh”该命令的输出中会看到 Build 系统已经引入了刚刚添加的 vendorsetup.sh 文件。

    然后再调用“lunch”函数,该函数输出的列表中将包含新添加的 vendorsetup.sh 中添加的条目。然后通过编号或名称选择即可。

    最后,调用“make -j8”来执行编译即可。

    添加新的模块

    关于“模块”的说明在上文中已经提到过,这里不再赘述。

    在源码树中,一个模块的所有文件通常都位于同一个文件夹中。为了将当前模块添加到整个 Build 系统中,每个模块都需要一个专门的 Make 文件,该文件的名称为“Android.mk”。Build 系统会扫描名称为“Android.mk”的文件,并根据该文件中内容编译出相应的产物。

    需要注意的是:在 Android Build 系统中,编译是以模块(而不是文件)作为单位的,每个模块都有一个唯一的名称,一个模块的依赖对象只能是另外一个模块,而不能是其他类型的对象。对于已经编译好的二进制库,如果要用来被当作是依赖对象,那么应当将这些已经编译好的库作为单独的模块。对于这些已经编译好的库使用 BUILD_PREBUILT 或 BUILD_MULTI_PREBUILT。例如:当编译某个 Java 库需要依赖一些 Jar 包时,并不能直接指定 Jar 包的路径作为依赖,而必须首先将这些 Jar 包定义为一个模块,然后在编译 Java 库的时候通过模块的名称来依赖这些 Jar 包。

    下面,我们就来讲解 Android.mk 文件的编写:

    Android.mk 文件通常以以下两行代码作为开头:

     LOCAL_PATH := $(call my-dir) 
     include $(CLEAR_VARS)

    这两行代码的作用是:

    1. 设置当前模块的编译路径为当前文件夹路径。
    2. 清理(可能由其他模块设置过的)编译环境中用到的变量。

    为了方便模块的编译,Build 系统设置了很多的编译环境变量。要编译一个模块,只要在编译之前根据需要设置这些变量然后执行编译即可。它们包括:

    • LOCAL_SRC_FILES:当前模块包含的所有源代码文件。
    • LOCAL_MODULE:当前模块的名称,这个名称应当是唯一的,模块间的依赖关系就是通过这个名称来引用的。
    • LOCAL_C_INCLUDES:C 或 C++ 语言需要的头文件的路径。
    • LOCAL_STATIC_LIBRARIES:当前模块在静态链接时需要的库的名称。
    • LOCAL_SHARED_LIBRARIES:当前模块在运行时依赖的动态库的名称。
    • LOCAL_CFLAGS:提供给 C/C++ 编译器的额外编译参数。
    • LOCAL_JAVA_LIBRARIES:当前模块依赖的 Java 共享库。
    • LOCAL_STATIC_JAVA_LIBRARIES:当前模块依赖的 Java 静态库。
    • LOCAL_PACKAGE_NAME:当前 APK 应用的名称。
    • LOCAL_CERTIFICATE:签署当前应用的证书名称。
    • LOCAL_MODULE_TAGS:当前模块所包含的标签,一个模块可以包含多个标签。标签的值可能是 debug, eng, user,development 或者 optional。其中,optional 是默认标签。标签是提供给编译类型使用的。不同的编译类型会安装包含不同标签的模块,关于编译类型的说明如表 7 所示:
    表 7. 编译类型的说明
    名称 说明
    eng 默认类型,该编译类型适用于开发阶段。
    当选择这种类型时,编译结果将:
    • 安装包含 eng, debug, user,development 标签的模块
    • 安装所有没有标签的非 APK 模块
    • 安装所有产品定义文件中指定的 APK 模块
    user 该编译类型适合用于最终发布阶段。
    当选择这种类型时,编译结果将:
    • 安装所有带有 user 标签的模块
    • 安装所有没有标签的非 APK 模块
    • 安装所有产品定义文件中指定的 APK 模块,APK 模块的标签将被忽略
    userdebug 该编译类型适合用于 debug 阶段。
    该类型和 user 一样,除了:
    • 会安装包含 debug 标签的模块
    • 编译出的系统具有 root 访问权限

    表 3 中的文件已经定义好了各种类型模块的编译方式。所以要执行编译,只需要引入表 3 中对应的 Make 文件即可(通过常量的方式)。例如,要编译一个 APK 文件,只需要在 Android.mk 文件中,加入“include $(BUILD_PACKAGE)

    除此以外,Build 系统中还定义了一些便捷的函数以便在 Android.mk 中使用,包括:

    • $(call my-dir):获取当前文件夹路径。
    • $(call all-java-files-under, <src>):获取指定目录下的所有 Java 文件。
    • $(call all-c-files-under, <src>):获取指定目录下的所有 C 语言文件。
    • $(call all-Iaidl-files-under, <src>) :获取指定目录下的所有 AIDL 文件。
    • $(call all-makefiles-under, <folder>):获取指定目录下的所有 Make 文件。
    • $(call intermediates-dir-for, <class>, <app_name>, <host or target>, <common?> ):获取 Build 输出的目标文件夹路径。

    清单 2 和清单 3 分别是编译 APK 文件和编译 Java 静态库的 Make 文件示例:

    清单 2. 编译一个 APK 文件
      LOCAL_PATH := $(call my-dir) 
      include $(CLEAR_VARS) 
      # 获取所有子目录中的 Java 文件
      LOCAL_SRC_FILES := $(call all-subdir-java-files) 			
      # 当前模块依赖的静态 Java 库,如果有多个以空格分隔
      LOCAL_STATIC_JAVA_LIBRARIES := static-library 
      # 当前模块的名称
      LOCAL_PACKAGE_NAME := LocalPackage 
      # 编译 APK 文件
      include $(BUILD_PACKAGE)
    清单 3. 编译一个 Java 的静态库
      LOCAL_PATH := $(call my-dir) 
      include $(CLEAR_VARS) 
       
      # 获取所有子目录中的 Java 文件
      LOCAL_SRC_FILES := $(call all-subdir-java-files) 
       
      # 当前模块依赖的动态 Java 库名称
      LOCAL_JAVA_LIBRARIES := android.test.runner 
       
      # 当前模块的名称
      LOCAL_MODULE := sample 
       
      # 将当前模块编译成一个静态的 Java 库
      include $(BUILD_STATIC_JAVA_LIBRARY)

    结束语

    整个 Build 系统包含了非常多的内容,由于篇幅所限,本文只能介绍其中最主要内容。

    由于 Build 系统本身也是在随着 Android 平台不断的开发过程中,所以不同的版本其中的内容和定义可能会发生变化。网络上关于该部分的资料很零碎,并且很多资料中的一些内容已经过时不再适用,再加上缺少官方文档,所以该部分的学习存在一定的难度。

    这就要求我们要有很强的代码阅读能力,毕竟代码是不会说谎的。 要知道,对于我们这些开发人员来说,源代码就是我们最忠实的朋友。 Use the Source,Luke!

    参考资料

    学习

    展开全文
  • 对于你未必有所改进,修改前先看一次 build.prop 的权限 修改后设定权限后才重启不然手机会砖 # 加入修改 persist.sys.use_dithering=1 # 效率 ro.max.fling_velocity=20000 ro.min.fling_velocity=18000 debug....
  • 很多人对build.prop文件感到头疼,所以这里就将它的信息详情一一列出供需要的朋友们参考。 本文以CM的build为例讲解如何修改这些参数# begin build properties (开始设置系统性能) # autogenerated by buildinfo....
  • 编写app模块下的build.gradle文件 首先,gradle是线性翻译的语音,这里需要注意下闭包的编写顺序。整个打包入口在android.applicationVariants.all触发的,打包的时候可以获取到配置当前清单文件的版本号,文件等。 ...
  • 安卓build.prop文件作用说明

    千次阅读 2017-01-04 16:13:23
    通过修改system\build.prop这个文件,可以做很多事,build.prop是Android系统中的一个重要的属性文件,它记录了Android系统的一些重要的设置信息,改变它能够取得一些意想不到的效果,但是也正是因为.prop的重要性,...
  • build.gradle 里缺少组建 Failed to open zip file. gradle-wrapper.properties去掉s或者使用本地的 ViewPagerIndicatorLibrary’ could not be found in root 该开源控件无法引入 Execution failed for task ...
  • 基于4.4版本的代码整理出来的build目录下的mk文件调用流程由于有时候需要修改或者增加mk文件中的一些变量,以达到修改系统property的效果。因此大致整理了海思3798M平台4.4版本的调用流程。如下图:
  • 关于安卓build.prop文件的讲解

    千次阅读 2013-02-27 21:51:59
    我们可以通过修改BUILD文件,DIY自己的信息,或者实现某项功能,我们可以使用RE管理器进行修改。在修改前记得先拷贝一份出来,以免失败。 本文以CM的build为例讲解如何修改这些参数 # begin build ...
  • Build fingerprint: 'alps/gioneebj6752_lwt_kk/gioneebj6752_lwt_kk:4.4.4/KTU84P/14 28549246:user/test-keys' pid: 27308, tid: 27308, name: exprojectclient >>> com.page.indexprojectclient < signal 11...
  • 安卓系统在根目录中只有一个Makefile文件,每个模块只有一个android.mk文件,这是Makefile文件的一个片段,为什么要这么设计呢?这种设计方式解决了什么问题呢?相信读完本文将会找到这些问题的答案。2.问题的提出 ...
  • 安卓build编译各种系统镜像的过程。

    千次阅读 2015-09-15 13:54:01
    从前面Android编译系统环境初始化过程分析和Android源代码编译命令m/mm/mmm/make分析这两篇文章可以知道,Android编译系统在初始化的过程中,会通过根目录下的Makefile脚本加载build/core/main.mk脚本,接着build/...
  • android studio更新到4.0出现了项目报错:cause-invalid-type-code-69 1.下载sdk tools下的ndk和cmake 2.配置local.properties中的ndk目录 例如: sdk.dir=E:\Android\sdk ...然后再次build便可解决问题 ...
  • <div><p>请问如何解决</p><p>该提问来源于开源项目:reactnativecn/react-native-pushy</p></div>
  • assembleBlueDebug combines the flavor configuration with the build type configuration, and the flavor settings override the build type settings. Source sets 构建变体也可以有自己的资源...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,365
精华内容 1,346
关键字:

安卓build