9月27日 星期五 晴
我总是被接到一些无头无尾的邮件，没有人告诉我上下文，然后就让我去做什么项目了。
这个D项目也不例外，去和客户谈的时候，我一无所知。见面聊了才知道，先前别的部门做了，我们部门移植了一下，客户是来让我们改bug的。
客户需求：
1. 最根本需求：客户有自己的内部通讯录，员工可以看到通讯录里人的名字，但不能看到电话号码。
2. 围绕着需求1，演变出不想让员工自行安装APK，比如360安全卫士等能截获号码看到。
3. 围绕着需求1，担心log能看到。
之前开发情况：
1. 只是把android Contact的位置偏移了一下，写到数据库里的都是明文的号码。
2. 在通话记录、短信里显示的是一个真实号码，其中中间几位被*来替代，比如138****8888。
有一些bug，比如拨通话记录里的A，不小心就拨成B就出去了。之前的代码，我一行都没看，bug有那么五六个，看起来比较烦。
我也是没事，于是给客户提了两条主要的意见:
1. APK安装，我们也不知道你哪些可以安装，哪些不能安装，所以我可以提供一个白名单接口，动态更新，由他们来决定要更新哪些APK。
我说我能做到这一条，客户已经喜出望外了。
2. 能否做一个网络通讯录？号码都在底层和网络这边加密和解密就好，本地不存储通讯录。
我是这样说服客户的：你看过《暗算》么？就是谍战片，那些通过电报或者电台里传输的，很多都是加密过的。如果你加密方式足够好，那之前的都可以不做了。
客户当然一时时接受不了的，他得想半天。不过他当场表示，我提出的更好，更具安全性。
我也是有私心的，我就是不想改那些bug，客户同意我把自带的Mms和Contact给去掉，那我只要实现了，就没有什么bug了。
从底层来改，修改的地方不多，比较简洁，也符合我的风格。
工作量不大，具体的一些工作如下：
一、分别在底层和网络服务器都加上加解密。
- 在framework比较靠近底层的地方(当然，modem才是通讯更底层的地方)，分别修改通话和短消息这几个地方。
事实上，我记得我只修改了5个文件，分别是发短信，收短信、来电、去电、Mms，分别在这些地方调用函数一下就可以了。
以来电为例：
来电--》framework层加密来电号码-》上层处理或者广播时会显示加密的号码--》客户APK截获
去电是一个反向的过程，原理是一样的。
- 加密后的号码，报给客户的APK，客户的APK用约定好的加解密算法来解密即可。
如果担心有人反编译APK，加解密算法可以用C来打包处理，实在不行就上传到他们的后台服务器处理好了。
- 加解密算法：
没有必要采用非对称加密算法，采用简单的对称加密算法就好。
加密的密钥可以由IMEI + IMSI + 独特密钥就好。
服务器上记录了每台手机的IMEI和IMSI号，离职的时候，禁用这个账号，对传上来的IMEI和IMSI不予理睬即可。
如果员工更换手机，那么IMEI就不起作用了，防止员工换手机吧。
如果员工更换了SIM卡，那么IMSI也不起作用了，防止员工换SIM卡去运营商营业厅打通话清单。
二、APK安装动态白名单
- 直接修改PackageInstaller.apk的源码，安装的时候加个条件判断，不符合条件就不能安装就行。这个条件，就是白名单，可以读取比如一个文件或者APK的preferenece等。
- 在framework里封杀adb安装的方式，这应该可以防止豌豆夹和91助手之类的安装吧。
- 客户要求干掉文件管理器。
- 考虑到的问题：其实apk安装的底层函数我没修改，如果有人直接调用函数直接安装的话，可能是可以的。
如果有人能获取root权限的话，可以直接push进去的，除非我连手机自带的adb也改了。
当然，有了上述的加解密算法，APK的动态白名单无足轻重，但我也可以后续在别的项目上使用。
现在我的斯玛特卡只有300多块钱了，有点怀念以往有几千块钱的时候挥金如土的样子，国庆在家写1~2篇专利好了，一篇专利1500元。专利其实很好写，你能写博客，稍微加工一下，主要是加解密的算法和过程写详细一点(审核专利的只看有没有重复的，如果算法重复，那就换另外一种算法就成，反正就强调新颖性、有价值之类的就好)，垃圾专利的钱还是很好骗的。
