手机管理应用研究【5】——应用杂篇

欢迎转载。转载请注明：http://blog.csdn.net/zhgxhuaa

说明

在本系列文章的第一篇《安装卸载篇》中介绍了应用安装卸载相关的一些东西。

本篇之所以取名为《应用杂篇》就是希望继续介绍一些应用相关的相对照较零散的东西，包含：应用安装位置选择、应用锁、山寨应用识别、零流量分享、智能推荐等。

上接《应用安装卸载篇》，首先介绍一下应用安装位置选择。

应用安装位置

在安装应用时，应用究竟会安装到内置存储器里面还是外置存储器里面呢？这里主要取决于四个方面的信息：

A.       应用自身在AndroidManifest中队installLocation的定义。

B.       调用安装程序（pm命令等）时指定的參数。

C.       系统设置里面的应用安装位置选项（非常多厂商会隐藏。此时默认通常是AUTO）。

D.       安装时系统（这里主要是依据存储空间）的推断。

应用锁

应用锁这个点不大，可是假设要做。还是有一些点能够挖掘，比方：

A.       应用锁（锁定应用。使用时须要验证，如：password、图案等）。

B.       锁定系统设置（Settings）。

C.       锁定数据连接状态（Wifi、蓝牙、移动网络、数据同步）。

D.       锁定安装/卸载。

E.        应用隐藏。

应用锁

这里有两种实现方案：

A.       实现一个Service，在Service中定时查询RunningTask中的Activity，假设发现Activity属于被锁定的应用，则弹出加密验证界面。

B.       利用进程注入技术，对ActivityManagerService中的startActivity进行拦截，，假设发现Activity属于被锁定的应用。则弹出加密验证界面。

两种方案存在的问题：

1)        方案一不须要root权限就可以实现，方案二须要root权限。并且进程注入实现门槛较高，但实现更为完美。

2)        方案一定时轮询。在耗电方面表现要差一些。

3)        在採用方案一时。轮询时间能够定为300-500毫秒。

4)        採用方案一时须要屏蔽Back键和“近期的任务”列表。

5)        採用方案一时须要注意除了MainActivity以外其它Activity的推断。

6)        不管採用哪种方式都须要注意黑白名单的维护。

以下是採用方案一时的核心实现代码：

设置锁

设置锁锁定的是系统设置里面的信息，系统设置的信息大部分都是保存在Settings数据库中，已SettingsProvider的形式提供訪问的。所以这里在设定了锁定选项后能够通过Observer的方式进行监控，一旦发生改变则重置为原来的值。

锁定数据连接状态

有时候可能会有这样一种需求。就是锁定手机数据连接的状态。防止其它应用或者人去改变。

系统在数据连接发生变化时会有响应的广播发出。这里响应和处理响应广播就可以。

锁定安装卸载

这里有三种实现思路：

A、 通过进程注入监控系统卸载代码。

B、 监控系统的应用安装器进程（PackageInstaller）就可以，利用2.1中的方法就可以做到。

C、 利用Linux中的inotify机制相应用文件夹进行监控，详细不做分析，可參见之前《应用宝卸载监控》的文章。

三种思路存在的问题：

1)        方案1：能够监控静默安装/卸载和通过系统接口进行安装卸载，但无法监控直接暴力删除应用文件夹下的apk文件。须要root权限。

2)        方案2：仅仅能监控利用系统安装器进行安装的情况，无法监控静默安装和暴力删除。

3)        方案3：理论上能够监控全部情况，但依赖于监控进程的存活。在小米等手机监控进程可能存在问题。

应用隐藏

能够參考《手机加速篇》中的2.3.2借关于setApplicationEnabledSetting接口的介绍。

山寨应用/恶意应用识别

眼下市面上非常多手机管理软件都推出“山寨应用识别”类似功能，以下介绍一下这里面的一些点。尽管眼下各家都在做山寨或者恶意应用扫描的功能，可是木有统一的标准。

据网上的数据。腾讯手机管家觉得是恶意应用的有接近40%被360觉得是安全的；相同360觉得是恶意应用的也有20%多腾讯觉得是安全的。

但不管各家详细採用的识别方式差异多大。当中包括的内容无外乎以下这些。

在识别山寨应用的时候，能够从例如以下一些点入手：

A.       自身特征（包含：包名签名、图标、开发商）。通过图标推断相似度。著名开发商和合作厂商觉得是安全的。

B.       安全特征（手机病毒、扣费代码、偷跑流量、偷发短信等）。这里能够跟安全厂商合作。

C.       隐私特征（敏感权限）

D.       广告特征（通知栏广告、内嵌广告）

E.        市场特征（下载量、评价、用户举报）。也能够结合后台对刷榜情况进行处理。

F.        语言特征（对电子市场中应用默认语言进行评分）

G.       应用来源（对不同来源採用不同的打分，比方说对来做360的打5分。对来做百度手机助手的打8分）

H.       外部合作（安全厂商扫描、12321站点等）

I.         利用Google Play进行验证。

这里面涉及到的核心点有这么几个：

1)        应用相似度的计算。

2)        恶意应用的推断（这里能够採用加权平均等多种方法）。

 

通过上面的分析能够看出。在识别恶意应用时，有非常多工作是能够在本地做校验的，在本地校验完后再到server做进一步的校验。这种优点是能够降低流量和server的计算量。

系统唯一标识

有非常多场景和需求你须要用到手机设备的唯一标识符。一般会用到的信息有：IMEI、WIFI Mac address、BT mac address、Android id等。

具体的获取方法这里不做具体介绍，可參见http://cloudstack.blog.163.com/blog/static/1876981172012710823152/这篇文章。这里说一下几个须要注意的点：

• 尽量不用使用wifi mac地址。由于在wifi设备关闭后获取不到的问题。
• 不要依靠imei。由于山寨机可能反复，而且用户可能通过手机管理软件禁止相关权限。
• 全部涉及到权限的都要考虑用户可能会通过管理软件等禁止的情况。
• 除了上面的那篇參考文章中的方法外，guid生成唯一串保存起来以后使用，也是一种可行的实现思路。

这一篇仅仅是做了简单的方案的介绍，贴的代码较少，欢迎交流讨论。

下一篇介绍《省电管理篇》