各种权限

aosp下载之坑：巨大的代码，脆弱的网络，单独一个版本也有3,4十G，完整repo达到200多G，好网需要至少4天，一般网估计要翻倍，垃圾网，保守估计一个月，
不过一旦下完，以后切换版本就直接用本地源了，速度超快
aosp编译之坑：不同的android版本需要不同的java版本，如果刷机，需要驱动，某些版本需要对makefile打个补丁，万万不要考虑mac来编译，妥妥的ubuntu16.04,好在我写了脚本自动化这一切，然后是喝茶时间更多了。
aosp刷机之坑：bootloader，boot，system，userdata，recovery，分区概念，及相互关系要清晰，时刻小心bootloader被刷错的可能性，否则恭喜获得一块砖头， 同样没有匹配的驱动，刷机后会卡死不动，好在我有写了脚本自动化刷机，root，一键完成。
aosp  root之坑：supersu之后，想重刷内核（想要重编内核，改配置参数使得能加载内核模块，或者修改调试标志过反调），对于某些nexus，你还要root一遍。
定制内核之坑：配置内核是一个方面，打包也是另一个方面，定制修改就别说了，算三坑一体，修改后莫名无法启动，循环重启，你需要解锁新技能：手动焊接音频转串口调试线。
android  工具链之坑：讨厌ida来调试，更不想用as调试，vs也试过，最后统统抛弃，直接gdb，因gdb各个版本藏匿不同的bug，于是想编译自己的工具链，大坑开始。 需要解锁新技能：编译工具链。终于交叉编译最新8.1gdb，gdbserver成功，但发现gdb，gdbserver通信有bug，且不同于已公开的那些通信bug，于是寻求绕过，终于编译成功gdb81直接运行与android之上，于是通信问题没了，终于无法忍受gdb命令的原始，于是寻找pwddbg，gef等神器。但android上的gdb81不支持python，于是寻求绕过，先用termux，尝试进入另一坑，后出坑，发现linux  deploy的新大陆，于是直接安装ubuntu与android共存，现在gdb，gef已完美结合，此时你想彻底脚本化调试apk，于是发现chroot后无法访问am了，于是彻底研究了ld，linker，发明了挂载system，data，加ld_library_path的新方法来调用am，一切完美。不经意间strace发现am内部有某些调用失败了，于是认为发现了神器linux  deploy的bug，深呼一口气，读了代码，打了补丁，提了个pr给原作者。（原作者拒了pr，他自己写了个更好的方式来实现调用原来的android中的命令）

-----------------打字累了不写了。

厉害了,  楼上这位大兄弟!!!

lslx aosp下载之坑：巨大的代码，脆弱的网络，单独一个版本也有3,4十G，完整repo达到200多G，好网需要至少4天，一般网估计要翻倍，垃圾网，保守估计一个月，不过一旦下完，以后切换版本就直接用本地源了 ...

先生威武！！！

lslx aosp下载之坑：巨大的代码，脆弱的网络，单独一个版本也有3,4十G，完整repo达到200多G，好网需要至少4天，一般网估计要翻倍，垃圾网，保守估计一个月，不过一旦下完，以后切换版本就直接用本地源了 ...

666 服

aosp 国内清华镜像很快的

LZ安卓逆向研究得怎么样？

我感觉软件开发也比较难

slm孙礼明 我感觉软件开发也比较难

逆向是不是更难呢

mark

MARK

lslx aosp下载之坑：巨大的代码，脆弱的网络，单独一个版本也有3,4十G，完整repo达到200多G，好网需要至少4天，一般网估计要翻倍，垃圾网，保守估计一个月，不过一旦下完，以后切换版本就直接用本地源了 ...

你说的am不是在安卓机器里面运行的么？
不可以在ubuntu上运行吧

lslx aosp下载之坑：巨大的代码，脆弱的网络，单独一个版本也有3,4十G，完整repo达到200多G，好网需要至少4天，一般网估计要翻倍，垃圾网，保守估计一个月，不过一旦下完，以后切换版本就直接用本地源了 ...

那你最后gdb研究成功没？

mark

mark

lslx aosp下载之坑：巨大的代码，脆弱的网络，单独一个版本也有3,4十G，完整repo达到200多G，好网需要至少4天，一般网估计要翻倍，垃圾网，保守估计一个月，不过一旦下完，以后切换版本就直接用本地源了 ...

现在aosp也支持在Mac编译了，我已经编译过8.1的代码了。