完成OTO（based onandorid x86-5.1)的多窗口扩展功能． 参考了tieto的andorid-4.4的多窗口扩展功能．
- 项目简介
- 功能需求
- 项目进展
- 设计实现
- 存在问题
- 陈刚 刘晓旭 曹永韧
- 陈刚 李兵 刘晓旭 曹永韧
- 陈刚 李兵 刘晓旭 曹永韧
- 陈刚 李兵 刘晓旭 曹永韧
- 陈刚 李冰 王之旭 卢宁 （fix bug, add feature）
- 陈刚 李冰 王之旭 （fix bug, add feature）
- 陈刚 - fix bug
- 罗浩 - fix bug
- 对框架层多窗口部分的代码进行整理，考核标准是：使其真正地做到跨平台，例如基于原生aosp-5.1，在arm64模拟器上正确运行多窗口的各个功能。
- 对框架层，尤其是多窗口部分，进行整体地分析总结，考核标准是：开会同各个相关人员沟通交流，通过整体审核。
- 对各个主流的不同应用的适配（至少包含前50的热门应用），例如很应用的内容显示被拉伸（很多应用都是如此），弹出框位置不准确（经常遇到），某些应用使用了特殊非常规的操作（例如微信），有些应用鼠标消息有问题（例如很多游戏类），横屏竖屏显示问题等。
- 搭建arm64虚拟机开发环境，下载aosp-5.1源代码。
- 整理现有的同多窗口相关的补丁。
- 使得arm64虚拟机能够基本成功运行起来多窗口。
- 完成总结文档，开会同相关人员沟通交流。
- 解决所有在x86上正常，但在arm64上运行异常的各类主要问题。
- 如果有arm64的真机，并能刷进原生aosp-5.1，则可以在真机上进行测试。
- 分析目前的代码，完成总结分析文档，开会同相关人员沟通交流。
- 梳理目前存在的主要的共性问题，进行尝试性的分析解决。
- 对目前的代码设计存在的问题，以及相关的缺陷进行分析。
- 完成总结分析文档，开会同相关人员沟通交流。
- 解决目前设计存在的问题，以及相关的缺陷。
- 解决一部分目前的共性问题。
- 完成总结分析文档，开会同相关人员沟通交流。
- 解决目前已知的所有共性问题。
- 完成总结分析文档，开会同相关人员沟通交流。
1、李兵： 任务517，2016－11－30前完成，terminal 改变字体大小后点关闭，此时任务栏消失。 2、周怡洁（李兵）： 任务496，2016－11－30前完成，2016-10-20版本泰捷视频，终端全屏打开后，按alt + f4关闭应用，任务栏消失。
1、陈刚： 任务313，2016－11－08前完成，Linux图形程序的完整支持（鼠标位置不准确，需要自动隐藏显示鼠标光标，窗口全屏需全屏显示）。
1、陈刚： 任务314，2016－11－18前完成，支持自动隐藏状态栏（鼠标划上去时自动显示）。
2、李兵： 任务410，2016－11－30前完成， Firefox浏览器从常用界面 及常规打开网站时，底部显示异常，见附件。
1、李兵： 任务418/410，2016－11－30前完成，Adobe Acrobat 最大化时有黑色边框，缩小后有白色边框，应用卸载(设置-应用 -选中APP进行卸载 ),横 屏时显示正常,设置页面全屏时,卸载弹出框显示异常。
1、陈刚： 任务315，2016－11－30前完成，支持窗口最大化时自动隐藏窗口的标题栏（鼠标划上去时自动显示）。
1、卢宁： 任务514，2016－11－30前完成，自带音乐播放器，点击上方导航栏，右侧闪现滚动条。
2、卢宁： 任务514，2016－11－30前完成，相机拍照是反的。
1、陈刚：任务316，2016－11－30前完成，完成窗口最大化自动隐藏的相关原理介绍文档。
目前multi-window卢宁和周怡洁还都带有一定的研究性质，所以对于卢宁和周怡洁的相关任务只要本月内完成即可 （所以贯穿本月）。
对于陈刚和李兵，除了multi-window以外，还有其他组的相关任务，所以在每个任务前都标记了具体的初定完成时间，并按时间顺序排列
1、目前完成的内容：
多窗口已成型，包括应用的多窗口，相互间的重叠，焦点切换，改变大小，同状态栏上对应的小窗口的互动等。
目前自己总共提交了144个补丁（git log --author=chengang --oneline | wc -l），除了完成以上功能以外，
解决了大概40-50个bug（有时候几个补丁对应于一个bug）。
2、遇到的难点：
原先不仅对多窗口不熟悉，而且对整个frameworks都不熟悉（有铁托的aosp-4.4的代码，对我们非常有帮
助）。所以在添加功能，以及解决大部分的bugs时，基本都需要摸索，逐步找到方法，所以耗时很多，而
且重复性的工作也很多（有些解决方法不治本，所以会有反复，反复几次后，才能逐步找到根本解决方法）。
对于很多代表性的闭源应用（例如WPS，QQ，微信，微软Office等），在多窗口下有各式各样的小问题，
其主要原因是这些应用没有考虑到多窗口环境（始终以为自己是在全屏模式，而且状态栏一定是在上方，并
与其有交互），分析这类闭源应用，要比分析开源应用明显复杂。
由于团队新组建，人员缺乏，而且大家经验都不足，所以个人的时间精力不能全部投入到多窗口的开发，目
前，全部投入多窗口的有效时间大概在（50-60%左右），而且由于事务来回切换，导致工作效率相对较低，
具体的其他事务如下：
由于要支持其他非多窗口的功能（例如开始菜单，通知栏，中间层等），需要分出时间去处理支持。
对于多人开发，代码Review和合并，需要分出较多时间去处理（例如合并应用开发人员的代码补丁）。
对于人员招聘（清华实验室，以及一铭公司等），需要分出时间去处理。
对于一些管理上的事务，需要去协助，对于产品层面的一些事务，有时也需要偶尔参与一下。
同新人，学生，以及有一定经验的人员的技术方面的沟通交流，需要分出一部分时间去支持。
3、下一步(20161031前)：
目前存在的问题：
目前依旧有15-20个关于多窗口的bugs需要解决，其中有些是关于对话框的处理，目前经验依旧不足（没
有根本解决问题），对于这15-20个问题，对于只是我个人来做，大概需要将近一个月的时间才能基本解
决完毕。
目前框架层的一些其他功能性的问题也需要解决（大概有5-7个），这些问题即同应用层相关，又同中间
层相关（例如有些应用不识别有线网卡，这同应用层、框架层、中间层都相关，需实现一个虚拟网卡），
个人估计，这5-7个问题，对于只是我个人来做，大概需要一个月左右的时间才能大体解决完毕。
目前系统的性能和稳定性也需要考虑，目前相关的问题有8-10个，这些问题大部分属于全局性问题，而且
很可能aosp-x86，甚至原生aosp也可能有问题。个人估计，这些问题大概需要一到两个月才能大体解决完
毕。不过这些问题不太明显，可能不会影响发布，所以可能不会那么紧急。
处理方案：
对于目前多窗口的bugs，更需要总结归纳经验，由此来根本解决。同时培养目前的人员来逐步有能力去分
担解决目前的相关的bugs（其实有经验的应用开发人员，都有这个潜质去解决这些问题）。
对于框架层的一些功能性问题，其实并不难解决，但目前来说，还是需要我这里先解决几个，并总结一些
解决相关问题的经验，这样后面就可以有人跟进了。同时对于应用层和中间层相关的部分，相关的人员应
该能提供明显的协助。
对于性能稳定性相关的问题，有些是比较简单的（例如有些通过版本对比即可解决，有些只要简单的段错
误堆栈分析即可），但有些可能就比较复杂（也包括通常的段错误）。这时候就需要有一套相应的调试方
法和分析方法。具体方法如下：
对于中间层、内核、框架层、应用层等都有相关的调试方法和分析方法，但都需要一定的阅读反汇编
代码的能力，以及可以快速阅读大量C/C++/Java代码的能力。对于调试C/C++代码，可直接使用gdb，
而对于调试框架层和应用层的代码，使用Android Studio即可（有可能需要详细的配置和反复地挂接）。
而对于那些需要进行转译的部分（arm转x86_64），目前可以通过对比arm平台运行（消除转译），
来进行分析。如果确有必要，则需要调试相关的虚拟机（也有相关的调试方法，例如把虚拟机当调试
器使用），但相对来说会更复杂一些。这需要对汇编指令和中间语言足够熟悉，并可看大量汇编代码。
各位好！ 以下是我对Multi-window开发的现阶段总结，仅代表个人看法，欢迎沟通交流：
1.完成内容概述：
截止到目前为止，个人在framework/base/下共提交28个补丁，并对从4月中旬以后的陈工提交的大部分补丁进行了review。在其它项目中也提交了一些用以支持上述补丁功能实现的内容。解决bug大概20-30个，实现了任务栏主要功能并对其代码进行了重构和优化。同时实现和完善了最小化功能体系，并对一些其他功能（例如home键，alt + tab功能）进行了最小化方面的功能支援。
2.主要遇到的问题：
从个人的角度出发，开发过程中主要遇到了以下问题：
1）对Android整体的不够熟悉导致开发进度缓慢，之前没有过Android的开发经验对大多数控件，组件的功能特性以及代码实现没有整体的把握，导致出气的额一个月左右都是在做相对无用的功能。直到完成了边框的拖拽以及鼠标的变化之后才真正步入了开发的正轨，但整体开发过程中个人任务一直在bug解决和功能完善之间游离，同时由于Android系统的庞大导致自己所负责的功能和bug相关性通常都很有限，再加之个人经验的匮乏能力的局限导致每一次踏入新的功能领域（不管是实现功能还是解决bug）都会需要一定的时间来熟悉，这是个人开发效率底下的主要原因。
2）学生身份对开发无法全力投入也是问题之一，为了能够毕业目前需要花大量时间在毕业论文以及小论文上，同时去年学长的毕业论文情况不够理想也在无形中给了我一些精神上的压力，这是个人工作状态无法达到最好的主要原因。
至于问题1已经在逐步的开发过程中进一步对Android有了深入的理解并对组件控件以及代码实现上都有了一定的分析经验，但Android是庞大的系统，没有涉足的领域仍然有很多，之后的工作中该类问题无法避免，只有通过交流沟通尽可能地学习他人在相关部分或者类似部分开发或分析问题的经验。对问题2而言，下学期会更加激化，但个人来说必须以毕业为重，还请谅解。
从实现功能的角度出发，遇到的难点主要有以下内容：
状态栏：首先由于初期设计不足，直接将statusbar用于当做状态栏此举并不知是否妥当，但开发过程中却是由于statusbar的适配问题产生了很多bug和功能实现上的难点。在实现状态栏图标固定功能的时候对statusbar的xml文件进行了大规模重写，同时尽可能地分离了状态栏图标与statusbar的关联，将状态栏图标进一步作为“显示在statusbar上的独立组件”来设计和实现，规避了很多由于对statusbar不够了解带来的困难。个人认为，对statusbar代码的分析为之后功能（例如home键等）的添加提供了基础，但也仍存在不足，目前相关功能看起来已经实现的相对完备，但在今后的移植和新功能添加时该部分仍有可能包含大量的陷阱需要注意。
bug与代码的隐性关联：个人项目经验不足，之前没有经历过Android这一类的代码量庞大系统复杂的工程开发，以下内容纯属个人看法。在解决bug的过程中，个人感觉bug与代码的关联性没有以往进行过的项目来的好发现。在解决锁屏问题的时候光是涉及的java文件和xml文件就不下20个，其中大量方法存在着高度耦合，很难将问题的具体位置进行明确定位。同时对于一些看起来与某些组件相关的bug实际上并非该组件引起（例如chrome在打开的情况再次打开崩溃的bug其实与窗口功能无关而是与startup menu中对应用的启动方式有关），在此之上，一些难以复现的bug解决起来更为棘手，这类问题往往会消耗更多的无用时间。个人感觉该问题在今后的开发过程中仍会大量出现，这不光是由于Android的复杂和庞大造成，也受制于人手的有限以及测试反馈的模糊也有关系。
调试难度：个人人为在实现framework/base/下的功能的过程中最为烦恼的就是调试问题，日志的加入和筛选以及每一次细小修改所需要消耗的编译时间都会让整个调研过程变得冗长，对于没有系统开发经验的人这样的节奏可能会导致不适应和状态下降，加之人员增加导致服务器负荷增加，编译速度进一步下降，通常会对思路的保持以及工作效率造成影响。
上述问题仅代表个人观点，总体而言在开发中遇到的难点基本都是由于Android系统开发的经验不足以及Android本身代码的复杂造成，从个人的角度来说这是不可避免的过程，毕竟项目团队中真正有Android系统开发经验的人很少，所做的内容也并非常规Android系统功能，这种开发上的“水土不服”以及经验的匮乏共同作用个人认为是导致本项目目前仍未有一个稳定版本的主要原因之一，同时也是我们需要解决的重要问题。
假期结束后个人可能会更多的投入到毕业设计的工作中去，在bug修复和功能实现方面的工作可能会减少，希望能够谅解。
祝各位八月份工作顺利！