Android卸载程序之后跳转到指定的反馈页面
2015-01-13 02:53
267 查看
那个360被卸载之后会跳转到指定的反馈页面,是怎么弄的?
回来了,就百度了一下,果然网上似乎有相关的问题的解答,这里就将他们的步骤在细化一下了:
其实这个问题的核心就在于:应用被卸载了,如果能够做到后续的代码逻辑继续执行
我们再来仔细分析一下场景和流程
一个应用被用户卸载肯定是有理由的,而开发者却未必能得知这一重要的理由,毕竟用户很少会主动反馈建议,多半就是用得不爽就卸,如果能在被卸载后获取到用户的一些反馈,那对开发者进一步改进应用是非常有利的。目前据我所知,国内的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端进程在应用被卸载后不会被销毁。
解决的方案确定了,下面来看一下代码吧:
?
这里面主要是用到了Linux中的inotify,这个相关的内容可以自行百度一下~~
这里有一个很重要的知识,也是解决这个问题的关键所在,就是Linux中父进程死了,但是子进程不会死,而是被init进程领养。所以当我们应用(进程)卸载了,但是我们fork的子进程并不会销毁,所以我们上述的逻辑代码就可以放到这里来做了。(学习了)
Android应用程序代码:
MyActivity.java
?
SDCardListenSer.java
?
开启一个服务,在这个服务中我们可以看到,用到了一个很重要的一个类FileObserver,也是用来监听文件的变更的,这个和上面的inotify功能差不多。关于这个类的具体用法和介绍,可以自行百度呀~~
运行:
我们将应用安装之后,打开log进行检测日志:
adb logcat -s onEvent
当我们从设置中卸载应用的时候,会弹出如下界面:
注:这里我特定说了是从设置界面中去卸载应用,因为当我使用小米手机自带的那种快捷卸载应用的时候并不会跳转。这个具体的原因还有待解决(当然360的这个问题也没有解决掉。。)
总结:
我写这篇文章的目的以及我从这个过程中唯一学习到的一个知识点就是当父进程消亡了,子进程并不会消亡,所以我们可以记住这个知识点,以后遇到像应用被卸载之后的一些逻辑操作都可以采用这种方式去解决。
回来了,就百度了一下,果然网上似乎有相关的问题的解答,这里就将他们的步骤在细化一下了:
其实这个问题的核心就在于:应用被卸载了,如果能够做到后续的代码逻辑继续执行
我们再来仔细分析一下场景和流程
一个应用被用户卸载肯定是有理由的,而开发者却未必能得知这一重要的理由,毕竟用户很少会主动反馈建议,多半就是用得不爽就卸,如果能在被卸载后获取到用户的一些反馈,那对开发者进一步改进应用是非常有利的。目前据我所知,国内的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端进程在应用被卸载后不会被销毁。
解决的方案确定了,下面来看一下代码吧:
?
这里有一个很重要的知识,也是解决这个问题的关键所在,就是Linux中父进程死了,但是子进程不会死,而是被init进程领养。所以当我们应用(进程)卸载了,但是我们fork的子进程并不会销毁,所以我们上述的逻辑代码就可以放到这里来做了。(学习了)
Android应用程序代码:
MyActivity.java
?
?
运行:
我们将应用安装之后,打开log进行检测日志:
adb logcat -s onEvent
当我们从设置中卸载应用的时候,会弹出如下界面:
注:这里我特定说了是从设置界面中去卸载应用,因为当我使用小米手机自带的那种快捷卸载应用的时候并不会跳转。这个具体的原因还有待解决(当然360的这个问题也没有解决掉。。)
总结:
我写这篇文章的目的以及我从这个过程中唯一学习到的一个知识点就是当父进程消亡了,子进程并不会消亡,所以我们可以记住这个知识点,以后遇到像应用被卸载之后的一些逻辑操作都可以采用这种方式去解决。
相关文章推荐
- Android卸载程序之后跳转到指定的反馈页面
- Android卸载程序之后跳转到指定的反馈页面
- Android卸载程序之后跳转到指定的反馈页面
- Android卸载程序之后跳转到指定的反馈页面
- Android卸载程序之后跳转到指定的反馈页面
- Android卸载程序之后跳转到指定的反馈页面
- Android卸载程序之后跳转到指定的反馈页面
- Android卸载程序之后跳转到指定的反馈页面
- (仿360卸载后弹窗)Android卸载程序之后跳转到指定的反馈页面
- 详解Android App卸载后跳转到指定的反馈页面的方法
- Android不被kill的Service与卸载之后跳转出反馈页面
- Android不被kill的Service与卸载之后跳转出反馈页面
- Android单击通知栏后返回正在运行的程序并跳转到指定fragment页面
- Android activity跳转到另一个activity的指定fragment页面
- android 页面跳转到上个页面后之后再返回,页面没变
- 让页面在指定时间之后跳转代码
- 跳转到Android的程序卸载界面
- android实现加载的progressDialog之后跳转到程序主界面
- android 跳转指定浏览器访问指定页面(支持UC、Opera、QQ、Dolphin、Skyfire、Steel、Google)
- android 跳转指定浏览器访问指定页面(支持UC、Opera、QQ、Dolphin、Skyfire、Steel、Google)