Ubuntu虚拟机编译Android6.0总结

1 前言

   昨天使用清华的源下载了android 6.0的源码,校园网可以达到10M的速度,爽!今天一大早就迫不及待地准备编译一个模拟器版本,看看效果,哪知竟然耗费了一整天的时间才搞定...为了避免其他人在同样的问题上浪费时间,特记录整个编译过程中遇到的问题和解决方案,毕竟时间就是金钱!

2 背景

   我是在MAC上安装的ubuntu14.04 64bit系统,起初分配了3G的内存(血的教训,完全不够用!),和两个核心。编译的系统版本为6.0.1_r9和6.0.0_r26

3 编译过程遇到的问题和解决方案

   整个编译过程严格按照官网的说明进行,不过因为不需要经常编译源码,同时为了节省空间,所以没有使用ccache.

   起初编译很顺利,但是当执行到编译java代码(jar或者dex)阶段的时候出现如下错误:

   

                                               图3.1 编译错误反馈信息 

   显然,是一个叫做Jack的服务没能启动,那么这个Jack是干什么的呢?截取官网信息简要概括如下:

   Jack (Java Android Compiler Kit)是一个新的Android编译工具,用于将Java代码编译为Android dex字节码,主要用于替换之前的编译工具: javac, ProGuard, jarjar以及dx等等。更详细的信息可参考官网介绍:

  https://source.android.com/source/jack.html#jack_intermediate_library_linker_jill

  Jack的重要性不言而喻,因此如果不能正常启动它的话,我们的源码是断然无法编译下去的。那么它为什么无法启动呢?  

  查看官网,有如下两条提示信息:

If your computer becomes unresponsive during compilation or if you experience Jack compilations failing on “Out of memory error”

You can improve the situation by reducing the number of Jack simultaneous compilations by editing your $HOME/.jack and changing SERVER_NB_COMPILE to a lower value.

If your compilations are failing on “Cannot launch background server”

The most likely cause is TCP ports are already used on your computer. Try to change it by editing your $HOME/.jack (SERVER_PORT_SERVICE and SERVER_PORT_ADMIN variables).

   排除第二种情况后,觉得第一种情况很有可能,因为从jack的启动参数来看的话(从图3.1编译错误反馈信息可以看出),在启动jack的时候为java虚拟机分配了2560M的内存,但我整个ubuntu虚拟机才3G啊!所以我马上将Ubuntu虚拟机的内存增加到4G,然后重新编译,不过我并没有make clean因为前面非java部分的编译都是没问题的,而java部分编译一开始就出错了,所以不需要进行彻底地重新编译。

   哪知,悲剧再次上演!当时两眼抓瞎,都准备放弃了....中途去请教了下之前有过成功编译经验的同学,以为是版本的问题,所以将6.0.1_r9切换到6.0.0_r26后完全重新编译,漫长等待后也是出现同样的问题。这里记录下切换源码版本的方法:

① 首先进入源码根目录,将.repo/ 文件全部删掉。
② 查看可切换的分支
    cd .repo/manifests
    git branch -a | cut -d / -f 3
    这里选择6.0.0_r26即可
③ 切换分支
    repo init -b android-6.0.0.0_r26
④ 同步分支
   repo sync   
   注:因为我之前同步的是6.0.1_r9的源码,所以这一步很快就完成了,根据git的原理,并不需要重新下载整个源码,所以这里很快就完成了。

   

  显然,这根系统版本并没太大关系,继续分析Jack无法启动的原因。偶然发现每次编译失败之后都会在源码根目录生成如下日志文件:

   

   从名字就可以看出是一些错误日志,打开看一看,关键信息截取如下:

 1 #
 2 # There is insufficient memory for the Java Runtime Environment to continue.
 3 # Native memory allocation (malloc) failed to allocate 1789919232 bytes for committing reserved memory.
 4 # Possible reasons:
 5 #   The system is out of physical RAM or swap space
 6 #   In 32 bit mode, the process size limit was hit
 7 # Possible solutions:
 8 #   Reduce memory load on the system
 9 #   Increase physical memory or swap space
10 #   Check if swap backing store is full
11 #   Use 64 bit Java on a 64 bit OS
12 #   Decrease Java heap size (-Xmx/-Xms)
13 #   Decrease number of Java threads
14 #   Decrease Java thread stack sizes (-Xss)
15 #   Set larger code cache with -XX:ReservedCodeCacheSize=
16 # This output file may be truncated or incomplete.
17 #
18 #  Out of Memory Error (os_linux.cpp:2827), pid=101129, tid=47875161523968
19 #
20 # JRE version:  (7.0_91-b02) (build )
21 # Java VM: OpenJDK 64-Bit Server VM (24.91-b01 mixed mode linux-amd64 compressed oops)
22 # Derivative: IcedTea 2.6.3
23 # Distribution: Ubuntu 14.04 LTS, package 7u91-2.6.3-0ubuntu0.14.04.1
24 # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
25 #

     从红色加粗的信息可以得到如下结论:在为Java虚拟机分配内存的时候失败了,原因就是内存不够用。但按照我的经验来看的话,4G内存无论怎样都够用了,那为什么还是报错呢?再仔细观察一下错误日志,里面还提及了“swap空间问题”。问题可能出在它身上!swap分区主要用于在物理内存不够用的情况下,使用硬盘来模拟扩展物理内存,只是速度要慢几个数量级而已。

    我不记得当初安装系统的时候是否分配了swap分区,所以使用如下命令查看:

chouchou:~$ sudo swapon -s
[sudo] password for chouchou:
Filename                Type        Size    Used    Priority

    信息竟然为空!也就是说我并没有swap分区,下面就开始创建分区了,这里为了方便可以使用swap文件的方式来实现:

创建4G大小的swapfile
sudo fallocate -l 4G /swapfile 
设置/swapfile权限
sudo chmod 600 /swapfile
设置swapfile
sudo mkswap /swapfile
启用
sudo swapon /swapfile
查看
 sudo swapon -s
[sudo] password for chouchou: 
Filename                Type        Size    Used    Priority
/swapfile                               file        4194300    345156    -1

   注意:这种方式创建的swap分区只是当前登录状态有效,重启后就无效了。至于如何实现永久有效,大家可自行google。

   现在再次编译,一次性通过!上图:

   

4 总结

   这次编译源码花了一整天的时间,除了遇到Jack错误之外,在虚拟机里面编译源码效率低下也是一个重要的因素。因为随着Android系统的升级,源码越来越庞大,其所需要的编译环境也跟着水涨船高,因此有条件的最好还是使用实体机编译,且内存一定得大于4G!另外,遇到问题,第一时间查看错误日志也很关键,这样往往能在搜索不到解决方案的时候,快速定位问题,节约很多时间!

   

posted @ 2016-01-13 02:12 WanChouchou 阅读(...) 评论(...) 编辑 收藏