给Android源码制作Patch文件

VIA之后计划每周发包,但都不是以Patch形式给.所以我们这边需要每次都在新包上合一遍十多个人的提交,提交工作量会很大,效率比较低.

之后在新包上计划采用Patch的形式做代码提交,每个工程师维护一版自己所有提交的Patch文件.

做Patch的方法:

1.从服务器上git clone一个最新版.

2.添加自己修改(先不要编译)

3.”git add .” (把自己所有的修改添加进index file, . 代表所有文件)

4.然后再编译验证自己的提交.若有问题,修改后也要再 git add xxx.java (XXX修改的文件)

5.验证无误后 执行 git diff –cached > xxx.patch 生成Patch文件. (git diff –cached:是查看index file与commit的差别的)

注意: A: 添加自己的修改,在未编译前一定要git add .

B: 编译后又修改了文件,要再单独git add xxxx.java

C: 一定不要在编译后执行git add . (编译后会有.o文件可能会添加到patch中)

每个工程师维护一版自己提交的Patch文件要费些事,但能够快速的提交新版上.

关于working tree, index file, commit,参考这篇文章.

KunLun阶段总结:代码提交,Bug管理,编译遇到问题及改进后的流程

我们的KunLun项目己进行了近半年,Android项目的开发需求,Bug数量,第三方,及要沟通解决的问题都较非智能机多了很多,这段时间总结了之前项目中有关代码提交,Bug管理,多版本编译几个方面遇到的问题,及针对这些问题的改进方法.目的是尽量减少人为出错的可能,提高效率,确保项目进度按时完成。

1.代码提交

原有流程: 原有问题: 代码审核人或配置管理员不在,导致漏提,忘提,找不到提交记录等问题,原有是直线型流程,任一点出问题都导致代码提交失败.

(more…)

Android 2.1 添加Taos光距感应 之总结篇

上一篇文章写到添加光感的步骤及遇到的问题,这篇总结上次遇到的难点及更合理的解决措施—驱动上报事件而不是每次读取,由于Taos光距感应是一起,所以这里一起叙述,按从驱动到上层应用的顺序。

1.Taos驱动层

驱动获取硬件的信息有两种方式,一是每次都主动的读取硬件寄存器的信息,二是硬件产生中断主动往Input中上报事件。第一种方式较简单,这里介绍下第二种方式。在Taos中,中断产生后会调用中断处理函数 taos_work_func  会根据事件类型主动上报光感或位置信息:

(more…)

Android 2.1 添加光感HAL层,及解决自动亮度设置不起作用的问题

基于VIA Kunlun 0.8.0 OMAP3630 Android 2.1 的方案,添加光感。Taos的驱动己完成,并且Demo测试光感可以正常工作。要使上层应用的光感可以正常工作,还需要做以下工作:

1.>添加光感HAL层的实现

2.>添加各层对光感的支持(默认2.1是没有直接支持光感的)

3.>修改Android2.1的“平台Bug”,以解决自动亮度设置不起作用的问题

(more…)

Android,杭州

         

         明天,要到杭州参加VIA组织的Android的KunLun项目的相关培训,很好的机会,拿到代码己经几天了,Android的源码量也是相当可观,在Ubuntu下搭建了编译环境,经过了三个小时终于编译完全,并成功通过T卡烧到了手机上。用VIA的2.1的源码与Google的代码库中的一比,差距也很大,看来VIA也是做了很多工作,还有一些第三方的参于。最近在看Android的书籍资料,对代码树有所了解,但更深层次的代码组织结构了解还不够多。正像书上所说,要想全部了解Android的所有部分比较困难,工作中就某一方面的开始入手,慢慢深入了解。

Windows Mobile 辅助设计 工具箱

    在开发Windows Mobile的程序之前,多了解些辅助设计工具箱中的工具,会更加事半功倍。以下列表是我总结目前可能的工具。 

1.
Mobile Client Software Factory July 2006 release

with
VS2005, .NET2.0 and WM5.0

The
Mobile Client Software Factory provides an integrated set of guidance that
assists architects and developers in creating applications on the Windows
Mobile platform. The software factory includes a reference implementation,
how to’s, patterns, and Visual Studio .NET extensions.

2.
Mobile Application Blocks

with
VS2008, .NET3.5 and WM6.1

Base on Mobile Client Software Factory July 2006
release

微软开发的一套软件工厂框架,将设计模式应用于Mobile软件开发

patterns & practices: Mobile Application
Blocks

3.
Mobile In The Hand

Mobile In The Hand 4.0 is a set of
APIs for Windows Mobile
 5.0
and above for .NET Compact Framework 2.0 and later. It provides a superset of
the Windows Mobile 6 managed APIs along with functionality from the full .NET
framework which is missing in the Compact Framework.

著名的开源类库,32feet.NET是以Bluetooth和IrDA开发为主的Shared
Source类库。

4.
OpenNETCF
著名的开源类库,早先由多位MVP发起,进行公司化运作,后被Novell收购,先为咨询公司。OpenNETCF的最新版本仍可以免费使用,但不提供源代码。
5.
Windows Mobile 6 SDK Refresh – Samples

The Windows Mobile
Software Developer’s Kit (SDK) ships with over a hundred code samples. These
are working applications that can help you learn to develop software for the
Windows Mobile platform.

 

Windows Mobile 应用开发 方法论

通过一个月的系统学习,总结出一套方法论,哈哈,其实没什么,但感觉挺有用的。之前做Windows
Mobile上程序都只是用ManagerCode来实现,没想很多,但随着了解的深入,发现有很多很多东西可以学习的,是VIA所没有的
。也了解了很多第三方库。

 

相关的学习资料,那不是用丰富来形容的(跟VIA不是一个数量极的),介绍一个感觉比较强,资料比较完善的地方:
其它的在Google搜“Windows Mobile开发资源介绍马宁介绍了更多
此方法论是以开发效率而言的,而不是以执行效率来说的,不然的话只能用WinCE API了。
1.首先用ManagerCode来做,看能否实现:
2.若.NET CF无法直接实现,则查找第三方库,封装了很多CF当前还没封起来的API:

OpenNETCF的1)Smart Device Framework2)32feet.net等库,这些库为基于.NET Compact
 Framework的程序封装了P/Invoke的调用。

    The
managed APIs do not include functionality to read messages already on the
device, which would require Platform Invocation Services (PInvoke) around the
CEMAPI functionality or use of a third-party library such as
3)Mobile In The Hand

3.若这些库还不行,则:
P/Invoke的调用WinCE API。

4.若需要call a .NET function
from a Win32 Process.
(如,GPSAPI 到得信息回调ManagerCode),则:

使用NameEvent等方法NativeAPI来回调ManagerCode

5.若再不行,就直接用Native
Code
来实现吧

     Native
C++还是可以通过MFC,ATL,WTL,STL来补救提高效率
使用WTL处理界面和大量使用STL。

虽然也是早看过Windows API的人了,但写起来还是比较艰辛的,所以首先选ManagerCode,是对我们繁重工作的解放,是让写程序充满乐趣的好办法:)