The wakelock will be kept held if there is outstanding requests
in request list. When WAKE_LOCK_TIMEOUT occurs, all requests
in mRequestList already waited at least DEFAULT_WAKE_LOCK_TIMEOUT
but no response. Those lost requests return GENERIC_FAILURE and
request list is cleared.
bug:3292426
Change-Id: I369c6ba4d6836d65ef616140e48c7304faf888f0
Rewrote interceptKeyBeforeQueueing to make the handling more systematic.
Behavior should be identical except:
- We never pass keys to applications when the screen is off and the keyguard
is not showing (the proximity sensor turned off the screen).
Previously we passed all non-wake keys through in this case which
caused a bug on Crespo where the screen would come back on if a soft key
was held at the time of power off because the resulting key up event
would sneak in just before the keyguard was shown. It would then be
passed through to the dispatcher which would poke user activity and
wake up the screen.
- We propagate the key flags when broadcasting media keys which
ensures that recipients can tell when the key is canceled.
- We ignore endcall or power if canceled (shouldn't happen anyways).
Changed the input dispatcher to not poke user activity for canceled
events since they are synthetic and should not wake the device.
Changed the lock screen so that it does not poke the wake lock when the
grab handle is released. This fixes a bug where the screen would come
back on immediately if the power went off while the user was holding
one of the grab handles because the sliding tab would receive an up
event after screen turned off and release the grab handles.
Bug: 3144874
Change-Id: Iebb91e10592b4ef2de4b1dd3a2e1e4254aacb697
For bug #3164802.
CallManager allow a new phone call only if ALL of the following are true:
- Phone is not powered off
- There's no incoming or waiting call
- There's available call slot in either foreground or background
- The foreground call is ACTIVE or IDLE or DISCONNECTED.
Change-Id: I0124d600fd8c63b8c608301f3889b3faec47f1db
Wait until all APN's have been tried before checking for permanent errors
and then, don't do retires only if all of the APN's had permanent errors.
Also, don't disable the requested apn type because if we do we won't
be able to setup data because there won't be an apn type.
This was tested by creating a new non existent APN, I chose:
Name="badapn1"
APN="badapn1"
Server="noapn.com"
Then selecting "badapn1" will cause a permanent error.
bug: 3202729
Change-Id: I182c7197456c849176ce08d7d1459359f8c3b30e
Fix bug # 3136179.
Keep audio mode as IN_CALL during hangup DISCONNECTING state
to prevent the NORMAL and IN_CALL glitch in auiod setMode.
Change-Id: I5513a3d5c65bd13ac054c9718c4dbd7d6db9eaf3
instead of silently returning null and causing NPE in applications as returning
null is not documented in the javadoc.
Add connection to the connection list in SipCall after dial() succeeds so that
we don't need to clean up if it fails. The original code will cause the failed
connection to continue to live in the SipCall and in next dial() attempt, a new
connection is created and the in-call screen sees two connections in the call
and thus shows conference call UI.
Bug: 3157234, 3157387
Change-Id: Iabc3235f781c4f1e09384a67ad56b09ad2c12e5e
The problem was that when we did a contact lookup based on a SIP address,
the resulting CallerInfo object did not have the person_id field set
correctly. That meant we had no way to look up the photo for that person.
This was because of a missing case in the logic to determine which column
(in the resulting cursor) to use for the person_id lookup. We were
handling lookups fine in the PhoneLookup and Phone tables, but were
missing a case for direct lookups in the Data table (which is how we look
up SIP addresses.)
The fix is to add a case for URIs like
"content://com.android.contacts/data" when looking up the person_id.
Also, since the person_id lookup is pretty hairy (and includes ~20 lines
of comments to explain what it's doing!) refactor it out into a helper
method.
TESTED: Both SIP and PSTN calls; verified that contact name *and* photo
are displayed correctly in all cases.
Bug: 3121292
Change-Id: I2b0083cc5394c1a49bbdc9a4e5651854aedb82f7
When a SIP call is put on hold and no other call is active, the audio mode should not be
switched to incall.
Change-Id: I1307330f10cbfb9c4223bcb9dc4faa79778750af
+ Avoid concurrent modification when forming >3-way conf call.
+ Revise SipConnection.separate() to put the newly separated call to foreground.
Bug: 3114987
Change-Id: If6204e7e3cc05f4a516c33657a368b53a0ad014d
it's a SIP call and the peer's username is all numeric. The all-numeric username
could be a PSTN number.
Bug: 3105116 (case #2)
Change-Id: I1de9cfac3aab1c4c89935176264d07693adb5e7d
(watch out auto-merge conflict for SipAudioCall).
Bug: 3113033, related CL: https://android-git/g/#change,75185
Change-Id: Ib48d3b990e229e0b341e47e10e76934e1a50d10f
Remember, the system and main logs are
- Shared resources
- Primarily for recording problems
- To be used only for large grained events during normal operation
Bug: 3104855
Change-Id: I136fbd101917dcbc8ebc3f96f276426b48bde7b7
In case it's a PSTN number carried by an Internet call, the phone app can still
get the original phone number from Connection.getAddress() instead of getting a
SIP URI.
http://b/issue?id=3085996
Change-Id: Ie6c66100a4b5b2ce3f73baa1b446761cd51d7727
Currently the SipPhone class manually creates a CallerInfo object, and
populates it with very basic info from the SIP address, when making an
outgoing call.
But this is no longer needed, now that we do caller-id lookup properly for
SIP addresses (based on real data from the contacts database -- see
bug 3004127 and change https://android-git.corp.google.com/g/70555).
And in fact the presence of this initial CallerInfo object actually
*disabled* contacts lookup for outgoing calls (bug 3072731).
This change removes all that CallerInfo-related stuff from SipPhone.
(Thus SipPhone is now consistent with the other phone objects, like
GSMPhone and CDMAPhone, in that it doesn't muck with CallerInfo data at
all, but instead lets the phone app do it.)
Also, update isUriNumber() to handle "%40" in case the passed-in string is
URI-escaped. (Nobody depends on that now, but it may be needed in the
future, and it's certainly safe to say that "%40" will never be found in a
legal PSTN number.)
TESTED:
- Outgoing SIP call:
- In-call UI shows correct contact info
- After the call, Call Log shows correct contact info
- Incoming SIP call:
- In-call UI shows correct contact info
- After the call, Call Log shows correct contact info
- PSTN calls:
- correct contact info everywhere
Bug: 3072731
Change-Id: I51434e4e5ad66d2e8ff51fc220001fb74485f0f5
Using mimeType causes an IPC request to contacts which can
be slow. This can cause an ANR of the Phone app. This change
parses the URL and to decide which column to use for the person_id
and thus should not cause an ANR.
bug: 3060704
Change-Id: I750c72746c7269e162f0338c0a3e00230a600519
+ CallManager: fix getFirstActiveRingingCall(), getActiveFgCall(), getFirstActiveBgCall()
+ Set DisconnectCause to be INCOMING_REJECTED when a call is rejected
http://b/issue?id=3049671
Change-Id: Ica1d81ca4b71ab0ceb2ab437b82bbb4ccf86fe92
Adding changes to be able to have access to missing data to SUPL
(celld, imsi, WAP_PUSH and SMS)
Change-Id: I0207f7f7ea6595ed3fd7021cb732feddf52e4cf9
Signed-off-by: Mike Lockwood <lockwood@android.com>
Let SipSession return it when UnknownHostException is caught.
Add DisconnectCause.SERVER_UNREACHABLE in Connection and have SipPhone report
it when receiving SERVER_UNREACHABLE from SipSession.
http://b/issue?id=3061691
Change-Id: I944328ba3ee30c0a9386e89b5c4696d4d9bde000
* Fix some typos in Javadoc and log messages.
* Remove redundant initializer in BluetoothAdapter.readOutOfBandData()
* Use canonical "UTF-8" charset name instead of "UTF8" in
BluetoothDevice.convertPinToBytes()
Change-Id: I58cd5dc48a7ad0053d204c5f590b4b3d438d8672
Exceptions may throw during canTake() as the peer may cancel the call and
result in a race with this method call.
Change-Id: I61903d601d8f9b2dcb4c4fbe1586e2c1a1069109
http://b/issue?id=3033868
Make them DISCONNECTED immediately. Don't enter DISCONNECTING state and wait
until SipSession ends the session. SipSession will get timed out eventually
but PhoneApp/user don't need to know this detail and wait.
This should fix the bug:
http://b/issue?id=3027719
Change-Id: Ida5a1bd09d08b9d591721384b4978127619aab51
CallerInfoAsyncQuery can now handle SIP addresses in addition to regular
phone numbers: if the number passed in to startQuery() is actually a "URI
number", we now treat it as a SIP address and look it up directly in the
Data table.
If it's a regular phone number, the behavior is unchanged: we use the
PhoneLookup table as before.
This piece of the fix covers only the contact lookup for incoming calls;
we still need some more cleanup of the CallerInfo class in order to get
the call log working.
Bug: 3004127
Change-Id: I0fcb80f9de5b8ecf99d31ee92e0889ddb07216fd
