2,852
社区成员
发帖
与我相关
我的任务
分享ISHELL_CloseApplet出现失效的情况，请各位大虾指教
高通6246平台，Brew4.0
在通话结束按下免提键挂掉电话。当收到AEECM_EVENT_CALL_END时间的之后做了这样一个处理，设置一个1s的timer，timer时间到后调用ISHELL_CloseApplet关掉当前的通话应用，大多数情况下都是OK的，通话应用正常收到EVT_APP_STOP后，我们把它转到后台。但是偶尔出现这样的情况，拨打几百个电话后（有时是几十个），同样的方法挂掉电话，通话应用没有收到EVT_APP_STOP事件，idle确被正常resume了。ISHELL_ActiveApplet()得到的应用是Idle，UI也返回到Idle。Idle确拦截不到任何的按键事件，此时按键都被通话应用拦截了。此时有2个top visible的应用。问题的关键是通话应用为什么没有收到EVT_APP_STOP事件？
而且这种情况只在2G网络环境下出现过，W网络环境下就是OK的。
各位大虾，有没有遇到这样情况？有什么高见？
在通话结束按下免提键挂掉电话。当收到AEECM_EVENT_CALL_END时间的之后做了这样一个处理，设置一个1s的timer，timer时间到后调用ISHELL_CloseApplet关掉当前的通话应用，大多数情况下都是OK的，通话应用正常收到EVT_APP_STOP后，我们把它转到后台。但是偶尔出现这样的情况，拨打几百个电话后（有时是几十个），同样的方法挂掉电话，通话应用没有收到EVT_APP_STOP事件，idle确被正常resume了。ISHELL_ActiveApplet()得到的应用是Idle，UI也返回到Idle。Idle确拦截不到任何的按键事件，此时按键都被通话应用拦截了。此时有2个top visible的应用。问题的关键是通话应用为什么没有收到EVT_APP_STOP事件？
而且这种情况只在2G网络环境下出现过，W网络环境下就是OK的。
各位大虾，有没有遇到这样情况？有什么高见？
...全文
请发表友善的回复…
发表回复
l1w1w1 2011-08-20
- 打赏
- 举报
打卡学习。呵呵
jackzhzh 2011-06-08
- 打赏
- 举报
首先确认一下timer是否生效（ISHELL_CloseApplet是否被调用）
再看看ISHELL_CloseApplet的返回值，然后根据返回值再进一步解析。
不过在CloseApplet中确实是有context的check。
再看看ISHELL_CloseApplet的返回值，然后根据返回值再进一步解析。
不过在CloseApplet中确实是有context的check。
myulei168 2011-05-11
- 打赏
- 举报
没见过这样的......
qq274840476 2011-04-25
- 打赏
- 举报
我曾经遇到过一种这样的情况，
由app1启动app2，然后app2中关闭app1.之后退出app2的时候 brew会自动会start app1
我询问过高通人员，他们说这是他们stop的一种机制，需要应用层人员，手动去删除history的东西
由app1启动app2，然后app2中关闭app1.之后退出app2的时候 brew会自动会start app1
我询问过高通人员，他们说这是他们stop的一种机制，需要应用层人员，手动去删除history的东西
半吊子全栈工匠 2010-12-31
- 打赏
- 举报
[Quote=引用 6 楼 smllyccat 的回复:]
这个问题是这么回事，利用了timer后会暂时把环境切换到系统上下文，这个时候去closeapplet是会失效的。所以在closeapplet之前最好加上恢复应用上下文的保护。这个问题就能解决了。
[/Quote]
可能是这种情况
这个问题是这么回事，利用了timer后会暂时把环境切换到系统上下文，这个时候去closeapplet是会失效的。所以在closeapplet之前最好加上恢复应用上下文的保护。这个问题就能解决了。
[/Quote]
可能是这种情况
smllyccat 2010-12-31
- 打赏
- 举报
这个问题是这么回事，利用了timer后会暂时把环境切换到系统上下文，这个时候去closeapplet是会失效的。所以在closeapplet之前最好加上恢复应用上下文的保护。这个问题就能解决了。
Duguachao 2010-12-26
- 打赏
- 举报
按理说通话应用被挂在后台的话，是不会接到事件的，BREW事件分发机制是把按键事件发给active applet的，只有特定应用的Event才会转给非active applet。事件处理完了，有时候并不一定要返回true，比如这个事件需要多个applet去处理，自己处理完就返回false，
欢乐的小熊 2010-11-10
- 打赏
- 举报
有可能，Qualcomm的也不能没有Bug啊。
事件顺序有时候会乱。
事件顺序有时候会乱。
FLYUP_CHEN 2010-11-08
- 打赏
- 举报
有点不可思议
chen_d031 2010-10-29
- 打赏
- 举报
所有按键都被通话截获了，他截获了并没真正处理就返回了。此时用brew的api得到idle和通话的应用的App state都是top visible。brew应用的状态有些乱了。。
rou1983 2010-10-19
- 打赏
- 举报
不管是BREW 还是BREW MP 都不可能出现两个top visible应用的场景，按你所说的情况，通话应该是被挂起了。
关于AEECM_EVENT_CALL_END消息，和网络相关，收到的时间是没有精确保证的。
你说idle收不到按键消息，那么按键消息被哪里截获了，是通话吗？？
关于AEECM_EVENT_CALL_END消息，和网络相关，收到的时间是没有精确保证的。
你说idle收不到按键消息，那么按键消息被哪里截获了，是通话吗？？
