Closed GoogleCodeExporter closed 9 years ago
Can you try the latest version :
http://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-03.
apk
(You must uninstall previously installed version from market before installing
this one).
Screen power modes has been modified in this version and it will maybe fix your
issue.
Thx in advance
Original comment by r3gis...@gmail.com
on 20 Jul 2010 at 2:20
Unfortunately still not blanking screen... love the info button though
Original comment by alessand...@gmail.com
on 20 Jul 2010 at 2:54
Do you mean by "blanking screen" the fact phone screen goes in "sleeping" mode?
If so, there is a "bug" in the wifi driver of Nexus One and some HTC devices.
The issue 71 provides more details on this issue.
Due to this problem, if an application use WIFI to receive datas, when the
screen goes off, the application doesn't receive datas in real time. As result
you get a choppy sound.
The only work around is preventing screen going off. That's the reason why in
latest version screen is lock at least in "DIM" mode (previously it was buggy
but probably for you in full bright mode).
To prevent user from unwanted action I started by implementing an additional
lock overlay. For now just based on a timer, but will be based on proximity
sensor soon.
Original comment by r3gis...@gmail.com
on 20 Jul 2010 at 3:05
I was just referring to the screen turning black when proximity sensor is
activated to prevent user to hit random buttons during calls. This is default
phone behaviour and would be great on this app! Noticed the double tap to
unlock feature. Seems a bit complicated but I understand there's no other
solution for the time being... thanks!
Original comment by alessand...@gmail.com
on 20 Jul 2010 at 3:46
Yes unfortunately there is no other solution with HTC devices. Wifi requires
the screen to be on to continue receive audio packet at a good rate.
Though, issue accepted and reused for Proximity sensor implementation :
It will not blank the screen but just activate/deactivate the double tap locker
screen.
Unless of course, the "keep awake while in call option" is disabled but *must*
not be the case for HTC devices. And in this case, yes, it will blank the
screen.
Original comment by r3gis...@gmail.com
on 21 Jul 2010 at 3:14
thanks!
Original comment by alessand...@gmail.com
on 21 Jul 2010 at 3:32
Maybe only some HTC devices. My Incredible doesn't suffer with WiFi Lock off.
Original comment by dc3de...@gmail.com
on 26 Jul 2010 at 10:32
The wifi lock option is for sip re-registration.
The issue can appear if you turn off the "keep awake while in call option"
(User interface section not in the network section).
However you're probably right, not all HTC devices suffer of this issue.
A good way to reproduce and be sure your device is or not affected is to turn
the screen off (using the power button / quick press) while in call and see if
the audio becomes choppy.
Btw, could be a good idea to set these option at first run according to the
detected device. For now it seems to be confirmed only for the Nexus One and
the Desire.
We should also make tests with codecs and audio driver frequency to see what
are the best settings to set as default according to the device. (I mean if we
should or not set 8Khz or 16Khz, if VAD and echo cancellation should be
disabled, which codec should be disabled etc etc).
Original comment by r3gis...@gmail.com
on 26 Jul 2010 at 10:50
Is it possible to get android to keep the phone from locking itself while in a
call but still blanking the screen without enabling the "keep awake while in
call option"?
When in a call the screen currently blanks as expected which is good, but then
if I want to access the screen (to hangup the call for instance) the phone has
locked the screen so I have to first press the power button for the screen to
go back on then use the slider to unlock it before I get access to the call.
Maybe not a big deal but a little annoying procedure.
Original comment by michael....@gmail.com
on 27 Jul 2010 at 8:43
Oh, yes your right, there is a bug here.... in fact, I've already added things
to manage the keyguard locks...
But I've just seen that it prevent from keyguard mode only if already in
keyguard mode.
Just to be sure, if you receive an incoming call while you are in keyguard mode
(screen off), the screen should wake up and keyguard should be disabled. And
then even if screen goes off keyguard will continue to be disabled.
The bug only appear if when call is started, keyguard is already not locked,
isn't it?
Original comment by r3gis...@gmail.com
on 27 Jul 2010 at 8:59
Yes I think you are right. I was testing with ougoing calls so the screen was
not locked. For incomming calls when the screen is locked it seems to work.
Original comment by michael....@gmail.com
on 27 Jul 2010 at 9:04
Proximity sensor support now ok with r191.
But... not works as it works in the native phone app : (they use private API
and besides they have no the issue with Nexus One wifi psp mode - which
simplify their life)
For reference, here is how it is implemented :
* Case 1 : Device has a proximity sensor :
When proximity sensor announce something is near of the phone, the lock overlay appear (full screen). When sensor announce nothing is near, lock overlay disappear.
* Case 2 : Device has no proximty sensor :
After timeout (5sec the first time, 20sec if after a manual unlock), lock overlay is shown. Double tapping on it hide this overlay.
Then....
* Case 1 : no "keep awake while in call" (hack for nexus one psp mode) :
Then phone will wait the time defined in settings and turn off the screen just
as it normally does when no activity is detected on the screen. (Note : the
goToSleep function defined in API is too dangerous to be use while in call to
force screen off mode - and probably also break the wifi lock).
* Case 2 : "keep awake while in call" active : screen will go in "DIM" mode
(low backlight) after the same delay than in the last point.
Original comment by r3gis...@gmail.com
on 9 Aug 2010 at 3:56
Original issue reported on code.google.com by
alessand...@gmail.com
on 20 Jul 2010 at 1:02