13.如何全编译代码?
由于上面介绍了如何连接真机进行调试,因此必须赶紧补充上全编译的方法。因为要进行联机调试,之前首先得将对应的代码进行全编译。很多新人在进行联机调试的时候会有很大的疑惑:为什么手机运行时Eclipse就知道,它就能让代码一起跑动运行?解答这些问题必须先了解全编译。
全编译就是告诉整个开发环境这各工程里有些什么代码,有些什么资源,将我们的Java代码转为机器/环境所理解的格式,并事先告诉它。这样,Eclipse在连接真机的时候就知道手机里到底是怎么回事了。当然,手机所使用的系统版本和Eclipse里的代码版本当然需要一致(有时候只是调试一个模块的话,保持模块代码版本一致大部分情况下也是可行的,为什么是大部分?因为一个模块难免和其他模块其他部分的代码有关联,如果恰好其他部分的代码没有保持相同版本却在调试运行中调用到了,就会出现Eclipse不知道的错误)。最后解释一下Eclipse通过什么来使代码和手机一起跑动运行的,这样就基本能解释清楚新人的疑惑了:通过ADB和DDMS。
源码分MTK提供的baseline(基线代码)和Google提供的Android原生代码,区别为前者在后者的基础上加了很多MTK自己的定制功能和代码。因此,全编译的方法也分两种:全编MTK平台代码、全编Google源码。
下面先讲MTK平台代码全编译的方法:
1.打开终端,进入源码根目录(这里以eyelike-v1.0-dint为例):
$cd /local/eyelike-v1.0-dint/
2.输入命令:
$./makeMtk listp
3.此时会出现下图内容:
图x 全编译项目示意图
特别说明:我们可以看到一个项目名列表,表示在该代码分支下面,拥有列表中这么多的项目(也就是说这些项目都共用这一套代码,为什么可以共用呢?因为我们有定制机制,可以通过Perso进行控制,从而满足不同项目的需求)。我们找到所需要的项目名即可,本例为下面用红线标识的jrdhz72_we_jb3(为什么是这个名字而不是其他呢?这是因为这个名字是项目经理或者管理代码的集成组同事写的,不知道的时候向他们询问知道这个信息就可以了,并没有其他特殊原因。当然你也可以使用列表中其他名字进行全编译,但显然你编译的就是其他名字所对应的项目了)。
4.接下来输入全编译的命令:
$./makeMtk -t new jrdhz72_we_jb3
5.回车后,即可开始编译。根据平台不同,要花费半小时到数小时不等。
然后讲Google源码的全编译方法:
1.打开终端,进入源码目录(这里以kitkat-v1.0-dint为例):
$cd /local/kitkat-v1.0-dint/
2.输入命令:
$make
说明:Google源码使用make命令即可进行全编译,如果需要多线程进行编译,可以使用下面命令:
$make -j8
说明:-j表示线程,8表示是8线程,多线程编译可以缩短一些编译时间,但有时候会出现可能因为线程按非线形运行而造成的编译错误。因此,在时间充裕的情况建议直接使用make命令。
14.什么是adb?
ADB全称叫做Android Debug Bridge,它本来就是进行Android debug通信的桥梁,它就像一个负责任的中间人一样,保持Eclipse(开发环境)和手机的代码运行同步状态。借助这个工具,我们可以管理设备或手机/模拟器的状态 。还可以进行以下的操作:
1、快速更新设备或手机模拟器中的代码,如应用或Android系统升级;
2、在设备上运行shell命令;
3、管理设备或手机模拟器上的预定端口;
4、在设备或手机模拟器上复制或粘贴文件;
我们一般在终端中输入adb xxx(命令)来使用。具体可在后面的示例操作中进行学习。DDMS全称叫做Dalvik Debug Monitor Service,它专门为 Android 开发环境中的Dalvik虚拟机调试监控服务。
15.什么是DDMS?
DDMS 的全称是Dalvik Debug Monitor Service,是 Android 开发环境中的Dalvik虚拟机调试监控服务。它为我们提供例如:为测试设备截屏,针对特定的进程查看正在运行的线程以及堆信息、Logcat、广播状态信息、模拟电话呼叫、接收SMS、虚拟地理坐标等等。因为我们在进行实际开发维护工作中,DDMS使用频率简直太高了,太重要了,所以必须详细解释一下DDMS。
在集成开发环境中,有DDMS控制台窗口。如,MyEclipse中,有个叫DDMS的Console。
1.如何启动DDMS
这个工具存放在SDK-tools路径下,启动方法:
1) 直接双击ddms.bat运行;
2) 在Eclipse调试程序的过程中启动DDMS,在Eclipse如下:
Window-Open Perspective-DDMS,点击启动就可以了
DDMS对Emulator和外接测试机同等效用,如果系统检测到它们(VM)同时运行,那么DDMS将会默认指向Emulator,以上两种启动后的操作有些不一样,建议分别尝试下;
2.DDMS的工作原理
DDMS将搭建起IDE与测试终端(Emulator或者connected device)的链接,他们应用各自独立的端口监听调试信息,DDMS可以实时监测到测试终端的连接情况.当有新的测试终端连接后,DDMS将捕捉到终端的ID,并通过adb建立调试器,从而实现发送指令到测试终端的目的;
DDMS监听第一个终端APP进程的端口为8600,App进程将分配8601,如果有更多的终端或者更多App进程将按照这个顺序依次类推.DDMS通过8700端口接收所有终端的指令.
3.通过GUI详细了解DDMS的一些功能
Devices:
在这个面板可以看到所有与DDMS连接的终端的信息,以及每个终端正在运行的App进程,每个进程的右边相对应的是与调试器链接的端口,因为Android是基于Linux内核开发的操作平台,同时也保留了Linux中特有的进程ID,它介于进程名和端口号之间;
Emulator Control:
通过这个面板的一些功能可以非常容易的使测试终端模拟真实手机所具备的一些交互功能比如:接听电话,根据选项模拟各种不同网络情况,模拟接受SMS消息和发送虚拟地址坐标用于测试GPS功能等;
Telephony Status:
通过选项模拟语音质量以及信号连接模式.
Telephony Actions:
模拟电话接听和发送SMS到测试终端.
Location Control:
模拟地理坐标或者模拟动态的路线坐标变化并显示预设的地理标识,可以通过以下3种方式:
Manual:
手动为终端发送二维经纬坐标。
GPX:
通过GPX文件导入序列动态变化地理坐标,从而模拟行进中GPS变化的数值.
KML:
通过KML文件导入独特的地理标识,并以动态形式根据变化的地理坐标显示在测试终端
16.怎么预研PR?
在对模块代码有了初步认识和熟悉后,就可以穿插进模块相关PR的演练。PR是什么?在本文中PR(Problem Request)代指Bug,可以理解为软件开发工程师所解决的问题。学习别人解决的问题,是非常好的一种方式,可以快速理解未来可能要遇到的问题,并掌握解决的方法。
可以找个早前的项目,比如yarism,搜索出它上面蓝牙(以蓝牙模块为例)相关的PR,尝试自己去理解PR描述的问题,然后自己去找解决的代码位置和方式。自己本来就不熟悉模块,也不清楚哪些PR有代表性,因此可以请资深同事帮助筛选一些PR出来。请资深同事或TeamLeader帮忙吧!再次好好感谢他们吧!
然后,先不要看别人的修改方法(怎么能看到?不会后面有教),自己独立思考摸索。是的,一定要自己独立思考,如果时间实在有限,也一定要在自己思考后实在没办法的情况下再看别人的修改。而且,看别人的修改也要尽量理解清楚来龙去脉,为什么能解决或为什么要这么解。当自己也有思路而与别人的修改不一样时,一定不要放过它,放马去问修改的那位同事,问他当时是怎么想的,为什么这么改,最后才将你自己的想法告诉他,这时往往他会告诉你的方法的缺陷!是的,你这样的新手想法往往是有缺陷的!不过,这正是你飞跃的时刻啊!天呐,你每遇到一次这样的机会,就是一次强有力地升级!
17.怎么查看别人的修改记录?
我们的PR(Bug/问题)通过Bugzilla(问题管理工具,对于使用者来说就是一个网站)来管理。我们可以在Bugzilla上面查看所有项目的所有PR(其实还分RR/CR/FR,不过本文全部以 PR代替描述)记录(只要权限足够)。搜索任何一个已有的PR号码,就可以进入它的详细信息界面,能够看到它的问题简介、问题详细描述、复现步骤、修改历史、修改备注(Comments)、项目名、最后解决时间、当前解决状态等等。学习一个PR最重要的便是阅读它的问题描述,理解问题所在,然后查看Comments中的备注。我们为了更好地管理PR和修改记录的关系,使用了脚本工具,使得每次提交解决方案后,Bugzilla都会自动将解决方案的链接以Comments的方式插入到该PR下面。因此,我们一般可以在Comments中找到一些链接,它就是我们所需!而这些链接,就是Gerrit网站的修改历史链接,上面记录了代码的修改等等信息。
18.什么是Git/Gerrit?
这时,就引出了Git。我们的代码都是通过Git(代码分布式管理工具)管理的,而存放都是存放在专门的代码服务器上的(在集成组的办公室里,有集成组同事专门负责维护)。我们在真正解决了一个问题后,所有的代码修改均要提交到Git服务器上面,以Git库的形式进行保存。
说明:很多人之前可能听过CVS和Subversion等,它们也是代码管理工具。我们这里以Git进行说明,而且作者本来也更倾向于Git。一方面是作者所在部门使用它进行代码管理,另一方面火爆异常的xxx网站即主导Git,个人觉得是潮流所趋。
18.1释义
Gerrit(代码审核服务器)对于代码提交者来说就是一个网站。为了保证代码质量,一般情况代码提交后均需要有资深工程师进行代码审核,审核通过后方可最终提交到Git库中。
代码提交者将代码通过 git 命令(或 repo 封装)推送到 Gerrit 管理下的 Git 版本库,然后去Gerrit网站设置该代码更改的审核者(Reviewer),将提交转化为一个一个的代码审核任务,审核任务可以通过 refs/changes/ 下的引用访问到。代码审核者可以通过 Web 界面查看审核任务、代码变更,通过 Web 界面做出通过代码审核或者打回等决定。测试者也可以通过 refs/changes/ 引用获取(fetch)修订对其进行测试,如果测试通过就可以将该评审任务设置为校验通过(verified)。最后经过了审核和校验的修订可以通过 Gerrit 界面中提交动作合并到版本库对应的分支中。
前面在讲到下载代码的小节中,曾提到下载代码的权限问题,其实有下载代码的权限,就同时对应提交代码的权限。由于这两个操作均是在Git/Gerrit服务器上进行,因此,我们接下来详细讲讲怎么开通这些权限。
18.2开通Git/Gerrit权限
第一次登陆Gerrit
1.在ubuntu中,进入~/.ssh,查看有没有id_rsa.pub文件,若没有,执行命令:
$ssh-keygen -t rsa
说明:命令执行过程中会询问key要保存的路径,选择默认即可。
2.继续执行命令:
$git config --global user.email <email_address>
说明:是在公司所用的邮件地址,在提交代码时Gerrit需要验证用户的Email地址,不执行这个命令可能无法提交代码。
3.在浏览器中,输入如下网址访问Gerrit服务器:http://gerrit.eyelike.com:8081/。
4.打开网页后点击右上角的Sign in,使用登录Windows时所用的用户名跟密码(域账号)来登录,如下图所示:
图x Gerrit网站登陆界面示意图
5.登录进去后点击Add Key,把id_rsa.pub中的内容粘贴进输入框里面,点击Add。这个key是将来push代码时git认证要用到。如下图所示:
以后使用中如果要更改或者增加其他的ssh key可以在登录到gerrit之后进入Settings->SSH Keys来操作。
6.然后发送邮件给集成组管理Git/Gerrit网站的同事,同时将id_rsa.pub作为附件发送给他,并抄送给TeamLeader,请求开通代码下载和提交权限,即可。
[email protected]