YuhanXu / omnidroid

Automatically exported from code.google.com/p/omnidroid
Apache License 2.0
0 stars 0 forks source link

call ended event is not being caught #117

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. create rule with call ended event
2. have two active rules at the same time
3. end one of them, while other is still active

What is the expected output? What do you see instead?
call ended event must have been caught.

Original issue reported on code.google.com by sv767%ny...@gtempaccount.com on 7 Jul 2010 at 9:58

GoogleCodeExporter commented 8 years ago
What do you mean in step 3 by "end one of them"? How do you end an active rule?

Original comment by renc...@gmail.com on 7 Jul 2010 at 11:40

GoogleCodeExporter commented 8 years ago
sorry, two calls not rules

Original comment by sv767%ny...@gtempaccount.com on 8 Jul 2010 at 12:02

GoogleCodeExporter commented 8 years ago
You mentioned in the steps to have 2 active calls. Is this done through 
conference call or call waiting? Or does that mean that the phone has multiple 
lines?

Original comment by renc...@gmail.com on 8 Jul 2010 at 12:11

GoogleCodeExporter commented 8 years ago
I meant call waiting. what do you mean phone has multiple lines?
It's simple really, if you have one call on hold, and you end the other one, 
new state is still off-hook.

I haven't tried conference call. but that shouldn't be a problem. new phone 
state will be idle.

Original comment by sv767%ny...@gtempaccount.com on 8 Jul 2010 at 12:37

GoogleCodeExporter commented 8 years ago
A new omnidroid-test may be in order?

Original comment by case.and...@gmail.com on 8 Jul 2010 at 2:37

GoogleCodeExporter commented 8 years ago
What I mean by multiple line is a phone that can have two independent phone 
lines. I am not sure if such a phone exists.

I am not sure how call waiting works, but I believe that it is being done in 
the phone network, so the phone (Android, in this case) probably won't even 
have a clue that there are actually two calls connected - one being active and 
one on hold. Therefore, I think the call ended event will still trigger if you 
end both calls since the connection has ended.

Original comment by renc...@gmail.com on 8 Jul 2010 at 4:30

GoogleCodeExporter commented 8 years ago
yeah if you end both calls, but if you end one and the other one is still 
active, this is still phone call ended event, and right now it's not being 
handled. same thing if you end one call while the other one is ringing.

what if you have some formal rule: send ppl email "it's pleasure to have 
business with you",after you end phone call.

Original comment by sv767%ny...@gtempaccount.com on 8 Jul 2010 at 4:58

GoogleCodeExporter commented 8 years ago
What I am trying to say is that this is probably a limitation that we probably 
can't do anything about because the handling of the two connections is done in 
the phone network and the phone itself does not know about it. All the phone 
sees is the single connection for the entire duration of the call waiting 
session. It would probably be a different story if the device is working on an 
IP phone network (which I believe Android is not).

Original comment by renc...@gmail.com on 8 Jul 2010 at 2:53

GoogleCodeExporter commented 8 years ago
onStateChanged is still called when these events happen

Original comment by sv767%ny...@gtempaccount.com on 8 Jul 2010 at 4:16

GoogleCodeExporter commented 8 years ago
I see, in that case, it is seems that then phone is not completely oblivious of 
the second connection. That means that there are other states other than the 
one I did on the wiki. To tell you the truth, I didn't want omnidroid to keep 
track of the phone state, since Android should be doing it already. However, I 
was forced to do it that way because I was not able to find a way how to figure 
out if the phone is ringing or call is ended other than thru the OFFHOOK, 
ONHOOK and RINGING intents.

It would perhaps be better if we could find a way to just ask the android for 
the state of the phone.

Original comment by renc...@gmail.com on 8 Jul 2010 at 5:29

GoogleCodeExporter commented 8 years ago
do you know what are those EXTRA_STATEs? they might be helpful. I find it quite 
annoying that even in case of off-hook hook state incoming number is null;

Original comment by sv767%ny...@gtempaccount.com on 8 Jul 2010 at 6:13

GoogleCodeExporter commented 8 years ago
Not actually. I didn't take into call waiting before when I was experimenting 
with the android phone state transitions.

Original comment by renc...@gmail.com on 9 Jul 2010 at 2:04

GoogleCodeExporter commented 8 years ago
bad news, we're missing some incoming calls as well.

Original comment by sv767%ny...@gtempaccount.com on 12 Jul 2010 at 3:10

GoogleCodeExporter commented 8 years ago
Do you know what circumstances cause it to miss incoming calls?  Is it the same 
(when you're getting a call waiting beep)?

Original comment by case.and...@gmail.com on 12 Jul 2010 at 3:41

GoogleCodeExporter commented 8 years ago
that happens when you have two incoming calls at the same time.

So from what I have tested, onCallStateChanged is only called when state 
changes. in this case, phone is ringing, and there is another incoming call, so 
phone state is "ringing" again, so onCallStateChanged is not called.

Technically, phone is aware of this change, it simply shows up on your screen, 
so I think there must be ways to catch these events.

What we might be unable to monitor is when I'm connected to someone through 
someone else. But that's ok i guess.

Original comment by sv767%ny...@gtempaccount.com on 12 Jul 2010 at 4:08