Android监听自身被卸载与反馈

1、引言

在做Android开发的时候，我曾经使用过监听自身卸载做统计的功能，但是没有总结过。依照不重复造轮子的想法，我将之前参考的文章转载到这里，以飨读者。

第一次转载，先注明出处：http://www.cnblogs.com/zealotrouge/p/3182617.html

2、描述

　一个应用被用户卸载肯定是有理由的，而开发者却未必能得知这一重要的理由，毕竟用户很少会主动反馈建议，多半就是用得不爽就卸，如果能在被卸载后获取到用户的一些反馈，那对开发者进一步改进应用是非常有利的。目前据我所知，国内的Android应用中实现这一功能的只有360手机卫士、360平板卫士，那么如何实现这一功能的？

　　我们可以把实现卸载反馈的问题转化为监听自己是否被卸载，只有得知自己被卸载，才可以设计相应的反馈处理流程。以下的列表是我在研究这一问题的思路：

　　1，注册BroadcastReceiver，监听"android.intent.action.PACKAGE_REMOVED"系统广播

　　结果：NO。未写代码，直接分析，卸载的第一步就是退出当前应用的主进程，而此广播是在已经卸载完成后才发出的，此时主进程都没有了，去哪onReceive()呢？

　　2，若能收到"将要卸载XX包"的系统广播，在主进程被退出之前就抢先进行反馈处理就好了，可惜没有这样的系统广播，不过经过调研，倒是发现了一个办法，读取系统log，当日志中包含"android.intent.action.DELETE"和自己的包名时，意味着自己将要被卸载。

　　结果：NO。调试时发现此方法有两个缺陷，（1）点击设置中的卸载按钮即发出此Intent，此时用户尚未在弹框中确认卸载；（2）pm命令卸载不出发此Intent，意味着被诸如手机安全管家，豌豆荚等软件卸载时，无法提前得知卸载意图。

　　3，由于时间点不容易把控，所以干脆不依赖系统广播或log，考虑到卸载过程会删除"/data/data/包名"目录，我们可以用线程直接轮询这个目录是否存在，以此为依据判断自己是否被卸载。

　　结果：NO。同方法1，主进程退出，相应的线程必定退出，线程还没等到判断目录是否存在就已经被销毁了。

　　4，改用C端进程轮询"/data/data/包名"目录是否存在

　　结果：YES。借助Java端进程fork出来的C端进程在应用被卸载后不会被销毁。

3、总结

这里的代码我就不贴了，大家可以自己去找找看。我将他所写的博客贴到这里：

Android应用如何监听自己是否被卸载及卸载反馈功能的实现

Android应用如何监听自己是否被卸载及卸载反馈功能的实现（第二版）

Android应用如何监听自己是否被卸载及卸载反馈功能的实现（第三版）