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

　　一方案：

　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端进程在应用被卸载后不会被销毁。

    二 方案

Android自API1就有的一个类FileObserver，这个类用于监听某个文件的变化状态，如果是目录，这个类还可以监听其子目录及子目录文件的变化状态，通过阅读FileObserver源码，发现其实现利用了Linux内核中一个重要的机制inotify，它是一个内核用于通知用户空间程序文件系统变化的机制，详情可参考http://en.wikipedia.org/wiki/Inotify，里面对inotify有比较详细的说明。

　　使用inotify的好处就在于不需要每1s的轮询，这样就不会无谓地消耗系统资源，使用inotify时会用read()方法阻塞进程，直到收到IN_DELETE通知，此时进程重新被唤醒，执行反馈处理流程。

 三方案

阻塞结束后，通过调用exec函数发出am命令调起浏览器访问网页，在API16（Android 4.1.x）的设备上尚可正常访问网页，而API17（Android 4.2.x）的设备上连浏览器也不能调起。解决方案：增加处理分支，若API>=17，将userSerialNumber传递给C端进程，然后在am命令中带上参数--user userSerialNumber即可