自己编译android
Ⅰ 编译调试Android系统原生App - 以Settings为例
本文已过时，最新文章：向大家推荐《使用 AS 开发 System App》 https://xiaozhuanlan.com/system-app
Android原生系统带有许多原生的App，比如 浏览器、录音机、计算器、设置 等，有些时候，我们需要用到一些系统的功能，或者是对已有的功能做二次开发，比如我上学时给一个公司做过一个Launcher和Wizard，就需要用到系统设置中的某些功能，比如Wifi、声音、显示等功能，于是就需要从Settings源码中提取出需要的功能。
特别是公司自己定制Android系统，需要在上面做一些 系统级的App 的时候，原生App已有的功能就可以通过编译其源码的方式直接拿过来改改就能用，而且可用度很高。
这里有两种情况，分为 原生 的和 公司定制 的系统。无论是原生的还是定制的，类似于Settings这样需要使用到 系统级或隐藏API 的App，都需要系统签名文件和编译系统源码后得到相应的jar包才可以在IDE中编译，因为标准SDK根本没有那些API可供调用。
举个栗子：
需要额外的Jar就需要自己编译系统源码啦，这个是比较麻烦的，有兴趣可以试试自己编译定制自己的Android系统。
** 注意，既然是定制的，源码、jar、签名文件，还有系统都是一一对应的，你不能拿其他公司的系统签名来给你公司的系统app签名，这样无法运行的。 **
有了源码，下一步当然是要跑起来啦。
建议都使用Eclipse来编译，不要使用AS，因为AS编译大型的原生App能卡到你吐血，而且出错提示也不友好。但是用过AS的人都不想再碰Eclipse了有没有？？别急，可以先用Eclipse编译过了，再贴到AS中，这样好很多，也很节省时间。
初始化：
放入源码：
修正res错误：
修正src错误：
使用到系统级API的，或者AndroidManifest.xml文件中声明了
那么没有系统签名，直接debug签名运行是不行的，需要向底层工程师要系统的签名文件，在源码目录
build\target\proct\security
下的 platform.pk8 和 platform.x509.pem ，如果你想看此次编译Settings是否已成功了，可以适当的在入口加一下Log，然后导出未签名的apk，使用系统签名进行签名后，放到 /system/app/ 下替换掉Settings.apk，然后重启系统，打开设置，看看Logcat是否输出里加入的Log。
在不知道系统签名可以转换成debug签名前，老实说我一直都是用Log的方式调试，太特么痛苦了。现在知道后整个人都懵逼了。
我们都希望可以像调试普通app那样调试系统app，以下是如何通过 openssl 将 platform.pk8 和 platform.x509.pem 转换成 debug.keystore 文件：
三个命令
此方法来自： http://curlog.com/2016/08/30/android-pk2debug-keystore/
Mac自带openssl，linux和Win需要安装。
然后就可以使用得到的debug签名配置到eclipse后愉快的调试啦，当然，得先把系统中已经存在的app先删除掉。然后重启系统，至于如何配置eclipse的debug签名，请Google。
使用过AS后，当然希望在AS中也可以调试系统App，抽空再写篇相关编译和调试的文章。如果这篇文章帮到你了，给个赞呗。
Ⅱ 怎么样将自己开发的Android应用程序编译到系统Image中
1. 搭建编译环境
编译环境： Ubuntu 10.10
Android版本：Android 2.2
编译过程中可能需要在Ubuntu上安装必要的一些软件，我安装过的包含如下软件，不同的系统可能会有差别：
jdk6(Android官方建议装jdk5，但是我在编译时会遇到java override问题，改用6没有任何问题), bison, lib64z1-dev, libasound2-dev, flex, gperf, libncurses5-dev
2. 应用程序存放目录
SimpleJNI是采用Android NDK和Java编写的程序，包含apk和so库文件，它的源代码在source tree的development/samples/目录下。
实际上package在编译时所放的目录并没有明确限定，编译后apk和so存放的位置是根据目录下Android.mk所指定的编译类型所决定的，例如：
SimpleJNI根目录下的Android.mk中有一行include $(BUILD_PACKAGE)，表示将该目录下的模块编译成package，即apk文件，默认存放的位置为/system/app。
SimpleJNI/jni目录下的Android.mk中有一行为include $(BUILD_SHARED_LIBRARY)，表示将该目录下的native.cpp编译为共享库文件，即so文件，默认存放的位置为/system/lib
因此，如果我们想要将自己编写的程序编译至image中，只需要将Eclipse下完成的整个工程到source tree下的某个目录即可，我一般习惯放到packages/apps下。
3. 添加Android.mk
完成了上一步，可以知道，Android.mk在编译中起着至关重要的作用，这其实就是Android编译环境中的make file。为了完成我们的工作，需要在源代码中添加Android.mk。添加自己的Android.mk可以仿照SimpleJNI中的Android.mk，稍微修改即可。我们首先看看SimpleJNI目录下的两个Android.mk的内容：
根目录下的Android.mk
TOP_LOCAL_PATH:= $(call my-dir)
# Build activity
LOCAL_PATH:= $(TOP_LOCAL_PATH)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := samples
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := SimpleJNI
LOCAL_JNI_SHARED_LIBRARIES := libsimplejni
LOCAL_PROGUARD_ENABLED := disabled
include $(BUILD_PACKAGE)
# ============================================================
# Also build all of the sub-targets under this one: the shared library.
include $(call all-makefiles-under,$(LOCAL_PATH))
根目录下的Android.mk决定了整个工程编译的配置，其中，
LOCAL_PATH 定义了当前的目录
LOCAL_MUDULE_TAGS 定义了当前模块的类型，编译器在编译时会根据类型的不同有些差别，有些tags的mole甚至不会被编译至系统中。LOCAL_MUDULE_TAGS主要有如下几种：user debug eng tests optional samples shell_ash shell_mksh。optional表示在所有版本的编译条件下都被编译至image中，剩下的表示在该版本中才会被编译只image中，如user表示在user版本下才会被编译至image中。
对于包含LOCAL_PACKAGE_NAME的mk文件，该项默认为optinal，具体可以参看build/core/package.mk。SimpleJNI中定义为samples的具体作用我也不太清楚，为了保险起见，我自己的apk一般定义为optional。
LOCAL_SRC_FILES 定义了编译apk所需要的java代码的目录
LOCAL_PACKAGE_NAME 这里需要改成自己的package的名字
LOCAL_JNI_SHARED_LIBRARIES 定义了要包含的so库文件的名字，如果你的程序没有采用JNI，这行不需要。
LOCAL_PROGUARD_ENABLED 定义了Java开发中的ProGuard压缩方法，主要用来分析压缩程序的，在我自己的应用中我没有加这行。
include $(BUILD_PACKAGE) 这行是build的关键，表示当前java代码build成apk
include $(call all-makefiles-under,$(LOCAL_PATH)) 表示需要build该目录下的子目录的文件，这样编译系统就会在当前目录下的子目录寻找Android.mk来编译so等其它程序。
根据上述所写，创建我自己的Android.mk如下：
TOP_LOCAL_PATH:= $(call my-dir)
# Build activity
LOCAL_PATH:= $(TOP_LOCAL_PATH)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := TestJniApp
LOCAL_JNI_SHARED_LIBRARIES := libtestjniapp
include $(BUILD_PACKAGE)
# ============================================================
# Also build all of the sub-targets under this one: the shared library.
include $(call all-makefiles-under,$(LOCAL_PATH))
看起来很简单吧，基本不需要改动即可。
Jni目录下的Android.mk
由于我们的TestJniApp是用JNI完成的，包含C源代码，因此也需要一个jni目录下的Android.mk。同样首先看看SimpleJNI中jni目录下的Android.mk的内容：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := samples
# This is the target being built.
LOCAL_MODULE:= libsimplejni
# All of the source files that we will compile.
LOCAL_SRC_FILES:= /
native.cpp
# All of the shared libraries we link against.
LOCAL_SHARED_LIBRARIES := /
libutils
# No static libraries.
LOCAL_STATIC_LIBRARIES :=
# Also need the JNI headers.
LOCAL_C_INCLUDES += /
$(JNI_H_INCLUDE)
# No special compiler flags.
LOCAL_CFLAGS +=
# Don't prelink this library. For more efficient code, you may want
# to add this library to the prelink map and set this to true. However,
# it's difficult to do this for applications that are not supplied as
# part of a system image.
LOCAL_PRELINK_MODULE := false
include $(BUILD_SHARED_LIBRARY)
LOCAL_MODULE 当前模块的名字，即编译后的so文件的名字
LOCAL_SRC_FILES 所要编译的文件
LOCAL_SHARED_LIBRARIES, LOCAL_STATIC_LIBRARIES 该模块要链接的动态库和静态库。
LOCAL_C_INCLUDES 要包含的头文件
LOCAL_CFLAGS C语言编译选项
LOCAL_PRELINK_MODULE 定义是否使用prelink工具，它用事先链接代替运行时链接的方法来加速共享库的加载，不仅可以加快起动速度，还可以减少部分内存开销。
经过修改后，我自己的TestJniApp中jni目录下的Android.mk如下：
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libtestjniapp
LOCAL_SRC_FILES := com_test_app_Jni.c
LOCAL_C_INCLUDES += $(JNI_H_INCLUDE)
LOCAL_PRELINK_MODULE := false
include $(BUILD_SHARED_LIBRARY)
这里有一点需要注意，如果要将so文件编译入image，必须要修改LOCAL_MODULE_TAGS，将原有的值samples修改为user，或者可以直接删掉 。删掉是因为对于包含LOCAL_MODULE的mk文件，如果没有指定LOCAL_MODULE_TAGS，该项默认为user，而只有定义为user的情况下，才会将so文件编译入image，具体定义可以参看build/core/base_rule.mk。
4. 修改/bulid/target/proct/generic.mk 把工程编译到系统中
至此，还有最后一部工作。为了将工程编译进入image，还需要在/bulid/target/proct/generic.mk文件中将package name添加进去
PRODUCT_PACKAGES := /
AccountAndSyncSettings /
CarHome /
DeskClock /
……
SyncProvider /
TestJniApp
完成上面这些步骤后，在source tree根目录下编译image就可以了。
Ⅲ Android反编译（三）— 手动编译
PS: 最近没工作，没工作就没需求，没需求就没什么技术总结的灵感，那就没更新什么。但是两个月不更新了，要是三个月不更新就会出大事，所以这次打算做一件有意思又不难的事。
之前有发文章写过反编译，今天就来试试反编译之正编译，开玩笑的，就是试试手动编译的过程， 平时我们在项目中编译出包都是使用Gradle直接执行assemble任务就能解决，我打算试试手动模拟整个过程。当然我也是第一次这样搞，所以如果有写得不对的地方，还望指出。
众所周知，apk实质上就是一个压缩包。复习一下，我们写个最简单的Demo，然后打包，然解压，注意是解压，不是反编译，意义是不同的。
注意我这个Demo很简单，什么都不引入
然后我们看看整个出包的过程，随便从网上拿张图
然后这里我们用Android SDK给我们提供的工具来完成整个流程，工具在sdk文件夹下的build-tools文件夹下，有什么aapt.exe、dx.bat，用的就是这些
这步应该是整个流程最简单的吧，我感觉，所以从最简单的开始。
我们先看看生成的dex有什么
对比项目，我是一开始最基本的项目，什么都没动，所以只有一个MainActivity.clas，所以这里肯定是要先想办法得到BuildConfig.class和R.class。
输入命令：
aapt p -f -m -J <输出路径> -S <res路径> -I <android.jar路径> -M <Manifest路径>
下一步，我们需要BuildConfig.class
这个BuildConfig.java是由gradle在我们配置好gradle之后自己帮我们生成的，所以我们直接拿来用，然后再javac就得到class文件了
然后我们再编译我们的MainActivity.java并将它们放到同一个文件夹下， MainActivity因为引用了Android.jar和R文件，所以编译时注意点，我为此被动好好的复习了一遍javac，都是泪
最后一步，我们用dx工具就能打出dex文件了
然后执行命令就得到一个Dex文件，看看这个文件里面和上面直接打出的apk中的Dex文件有什么不同：
看图，我们上一步已经生成.dex了，那么我们需要和compiled Resource 还有 Other Resource 一起生成APK。
我们先来生成compiled Resource，也就是resources.arsc
发现之前使用aapt生成R文件的时候没写完整，当时可以加一个-F参数直接生成arsc和Manifest
导出的abc.zip里面就有resources.arsc和AndroidManifest.xml。
因为之前写漏了，所以肯定要重新编一次MainActivity.java和Dex
我们把刚才的dex文件和aapt生成的resources.arsc、AndroidManifest.xml和res放到一个文件夹里面。
PS：res文件夹也是上面aapt的命令生成的
然后我们对比这个文件夹和之前apk解压的文件夹
最后运行
看来是成功了。
再说说遇到的还有两个问题，并说下我解决问题的思路
（1）我把它们都放到一个文件夹之后，我压缩成压缩包，然后改后缀成.apk，然后发现安装不了，我就直接反编译，发现发编译失败，提示包有问题，以我多点玩包的经验，我感觉就是压缩工具出了问题，然后我去下个“好压”（这不是广告啊），然后就能正常反编译了。
（2）但是还是安装不了，再根据我多年的玩包经验，我感觉是签名问题，然后我随便给这个包上一个签名，就能正常安装得到上图的结果了。
总体来说，还真挺好玩的，这整个过程，就是翻车了几次。做完之后感觉非常牛逼，为什么这样说，因为我知道这整个过程，我就可以做到，我不经过gradle来打包，我自己写个python脚本来调用aapt和dx来打包也是能做到的。
当然上面纯属异想天开，因为这是个什么都没有的Demo所以觉得简单，要是一个真实的项目，我感觉肯定要有很多坑，别的先不说，一个项目那么多依赖关系，我这javac要搞死人。
最后如果有不对的地方，希望有大佬能够指出，毕竟能运行也不能证明完全没问题。然后我使用的build-tools是28的，不敢保证其它版本包括以后版本的玩法都一样。
Ⅳ 自己可以编译安卓源码吗
用最新的Ubuntu 16.04,请首先确保自己已经安装了Git.没安装的同学可以通过以下命令进行安装:
sudo apt-get install git git config –global user.email “[email protected]” git config –global user.name “test”
其中[email protected]为你自己的邮箱.
简要说明
android源码编译的四个流程:1.源码下载;2.构建编译环境;3.编译源码;4运行.下文也将按照该流程讲述.
源码下载
由于某墙的原因,这里我们采用国内的镜像源进行下载.
目前,可用的镜像源一般是科大和清华的,具体使用差不多,这里我选择清华大学镜像进行说明.(参考:科大源,清华源)
repo工具下载及安装
通过执行以下命令实现repo工具的下载和安装
mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo
补充说明
这里,我来简单的介绍下repo工具,我们知道AOSP项目由不同的子项目组成,为了方便进行管理,Google采用Git对AOSP项目进行多仓库管理.在聊repo工具之前,我先带你来聊聊多仓库项目:
我们有个非常庞大的项目Pre,该项目由很多个子项目R1,R2,...Rn等组成,为了方便管理和协同开发,我们为每个子项目创立自己的仓库,整个项目的结构如下:
这里写图片描述
执行完该命令后,再使用make命令继续编译.某些情况下,当你执行jack-admin kill-server时可能提示你命令不存在,此时去你去out/host/linux-x86/bin/目录下会发现不存在jack-admin文件.如果我是你,我就会重新repo sync下,然后从头来过.
错误三:使用emulator时,虚拟机停在黑屏界面,点击无任何响应.此时,可能是kerner内核问题,解决方法如下:
执行如下命令:
通过使用kernel-qemu-armv7内核 解决模拟器等待黑屏问题.而-partition-size 1024 则是解决警告: system partion siez adjusted to match image file (163 MB >66 MB)
如果你一开始编译的版本是aosp_arm-eng,使用上述命令仍然不能解决等待黑屏问题时,不妨编译aosp_arm64-eng试试.
结束吧
到现在为止,你已经了解了整个android编译的流程.除此之外,我也简单的说明android源码的多仓库管理机制.下面,不妨自己动手尝试一下.
Ⅳ Android APK编译流程
apk 是Android Package的简写， 在平时的开发过程中，通过点击 Run app 按钮 或者 在命令行中输入
这样Android Studio就会启动构建流程，最终输出一个我们想要的APK。
直达官网介绍
对于小白来说，上面一张图已经可以解释apk的构建过程了，不过对于Andoid开发者而言还需要了解一些更详细的构建过程。
详细的对应步骤 和 使用工具如下：
资源文件（res文件夹下的文件）通过 AAPT（Android Asset Packaging Tool）打包生成R.java类（资源索引表）、.arsc资源文件 和res文件。
resources.arsc 是一个App的资源索引表，通过R.java 文件 和 resources.arsc 可以定位到资源的内存地址，resources.arsc文件的作用是通过一样的ID，根据不同的配置索引到最佳的资源显示在UI中。
AIDL （Android Interface Definition Language）， 是Android接口定义语言，是Android提供的IPC （Inter Process Communication，进程间通信）的一种独特实现。
如果有aidl文件，这个阶段会生成对应的Java接口文件。
R.java文件、工程源码文件、aidl.java文件， 在这一步通过javac生成.class文件。
源码.class文件和第三方jar或者library通过dx工具打包成dex文件
Android系统的Dalvik虚拟机的可执行文件为DEX格式，所以这里会将上一步中生成的.class文件 和 引用的第三方jar等过程中的.class 一起通过dx工具打包成dex文件
apkbuilder工具会将所有没有编译的资源、.arsc资源、.dex文件打包到一个完成apk文件中
tips：
apksigner工具会对未签名的apk验证签名。得到一个签名后的apk（signed.apk）
apksigner 是google 退出的V2签名方式
Jarsigner 是之前一直使用的V1签名方式
可以通过在命令行中输入apksigner --help来获取详情信息，如果没有特殊需求，使用下面命令即可完成签名
release mode 下使用 aipalign进行align，即对签名后的apk进行对齐处理
所谓对齐，主要过程是将APK包中所有的资源文件距离文件起始偏移为4字节整数倍，这样通过内存映射访问apk文件时的速度会更快。对齐的作用主要是为了减少运行时内存的使用。
zipalign是一个android平台上整理APK文件的工具，它对apk中未压缩的数据进行4字节对齐，对齐后就可以使用mmap函数读取文件，可以像读取内存一样对普通文件进行操作。如果没有4字节对齐，就必须显式的读取，这样比较缓慢并且会耗费额外的内存。
参考文章：
Android-Studio配置构建
浅谈Android打包流程
apk打包流程
END!
Ⅵ 如何使用自己的makefile编译android ndk项目
android ndk提供了一套自己的makefile管理方式，要将源码项目移植到android平台，需要按照android的makefile规则编写makefile，还要按android的规则部署源码目录，对一个有自己的makefile管理方法的大型项目来说，只是做一下makefile迁移工作就是一件很麻烦的事。
其实android ndk上的编译说到底也就是交叉编译，只要配置好交叉编译工具链，使用原有的makefile也是可以编译出在android运行的c、c++程序的。
以android-ndk-r4-crystax的ndk版本为例：
编译器路径 android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin
名称前缀 arm-eabi-
头文件目录 android-ndk-r4-crystax/build/platforms/android-3/arch-arm/usr/include
库文件目录 android-ndk-r4-crystax/build/platforms/android-3/arch-arm/usr/lib
你可以试一下上面的配置，如果编译链接都没有问题，可以adb push到android设备上运行看看，什么结果？
有点崩溃，根本运行不起来，你也许想试试看android自带的ndk例子，确实是能够运行的，问题在哪儿呢？
只是正确配置了编译器、头文件、库文件还不够，还需要配置编译、链接的参数，android例子中编译链接的参数是什么呢？你也许想深究一下android的makefile，可是不久你会发现那是更崩溃的事情，里面用了很多的make脚本函数。其实android的makefile是可以把执行的详细命令输出来的，只要make的时候加上V=1即可。可以看到确实带了很多参数
编译参数：
-fpic
-mthumb-interwork
-ffunction-sections
-funwind-tables
-fstack-protector
-fno-short-enums
-Wno-psabi
-march=armv5te
-mtune=xscale
-msoft-float
-mthumb
-fomit-frame-pointer
-fno-strict-aliasing
-finline-limit=64
-Wa,--noexecstack
-D__ARM_ARCH_5__
-D__ARM_ARCH_5T__
-D__ARM_ARCH_5E__
-D__ARM_ARCH_5TE__
-DANDROID
链接参数：
-nostdlib
-Bdynamic
-Wl,-dynamic-linker,/system/bin/linker
-Wl,--gc-sections
-Wl,-z,noreloc
-Wl,--no-undefined
-Wl,-z,noexecstack
-L$(PLATFORM_LIBRARY_DIRECTORYS)
crtbegin_static.o
crtend_android.o
这其中链接参数中的-Wl,-dynamic-linker,/system/bin/linker、crtbegin_static.o、crtend_android.o是最关键的，android使用了自己的进程加载器，并且自定义了c运行时的启动结束。难怪先前编译的进程启动不了。