Age | Commit message (Collapse) | Author |
|
Change-Id: Ie307e80319e429f5e605af25d9f1858a09af5477
|
|
328410 snap-temp-L55300000101694322
Change-Id: I13647420b3816b6bed2ded16d778165b311bd309
|
|
4323561 snap-temp-L80400000100600189
Change-Id: I2f9d33eb95868d3712e39aff7e439cb7d7a1c1f4
|
|
Currently, if the user requests merge, and the call they request the merge
on is in the midst of some other pending operation (e.g. hold, resume), the
system will prevent the merge from taking place. The logic, however does
not account for the fact that the background call being merged into the
foreground call could also be engaged in some other update operation.
Added code to ensure that both calls are not actively engaged in some
pending operation.
Test: Manual
Change-Id: Icc2f3786865345435bbf138b54736fc6f09c0aa4
Fixes: 63764631
|
|
4314464 snap-temp-L54400000099147910
Change-Id: Ib6cada36b85a6aaec410fb2e9e3a08dde94038b4
|
|
into oc-mr1-dev
|
|
4308825 snap-temp-L52700000098265170
Change-Id: Ic5e7c6849c62d6d2e833390818de196b41b44f0f
|
|
ImsService initialization can take longer than
telephoyn initialization in some cases, which causes
ImsConfig queries to return with an error. This change
adds an exponential backoff for querying provisioning
results from ImsConfig if we get an error during
initialization.
Bug: 64540800
Test: Manual
Change-Id: I2193e42736994de3cce6fb24ee1dcc9e936bebf0
|
|
b3d249ba99 am: 33f853dfb6
am: 3f444a6a8c
Change-Id: I18ca42d2fbe9a074c1d8a0e9429bbb500619a92c
|
|
am: 33f853dfb6
Change-Id: Ifd6ce2d8494b68e3ac1cb0b26b0d50f2730bac28
|
|
am: b3d249ba99
Change-Id: I0a13d9215bcb6068fa83337833ffd9bcbe17f657
|
|
am: 4801a7a0a9
Change-Id: Id290b10c204301bd0eeabda53759f8148e144db0
|
|
am: e511a2031e
Change-Id: I46d1438bf8170418901b17933895d02ab6b88906
|
|
Make changes to only toggle IMS on/off if the actual TTY option
is on (i.e. UI preference is enabled and TTY accessory is plugged in)
Test: manual
Change-Id: Ieac0ca041a0bd026e8b2f07ebcadc9a6a1db75b9
Fixes: 63968802
|
|
4288633 snap-temp-L81700000095141745
Change-Id: I3fb48534f4e796b1db77a8b8bdc2d369bda9203a
|
|
am: b7fa40ccde
Change-Id: Id78bbde4158902d7ec95b638c872a355cf3ef992
|
|
am: 1a252db653
Change-Id: I4ac88712d88ea1349c4005f23a051b99c22e5f9c
|
|
Make changes to only toggle IMS on/off if the actual TTY option
is on (i.e. UI preference is enabled and TTY accessory is plugged in)
Test: manual
Change-Id: Ieac0ca041a0bd026e8b2f07ebcadc9a6a1db75b9
Fixes: 63968802
|
|
When video is disabled (due to mobile data being off), we will automatically
reject any incoming requests to upgrade to video.
Test: Manual
Bug: 36900451
Change-Id: I9991cc9940aef417ec7f05cb61e777bf0d354c93
|
|
ours am: fb38165516 -s ours am: af2d361ca7 -s ours
am: 825507b50b -s ours
Change-Id: I41f720eb8a7ba8e2523382cee400606eea6b6bbf
|
|
ours am: fb38165516 -s ours
am: af2d361ca7 -s ours
Change-Id: I5feab59a3ef278d8126c40261b4cea86ff44992b
|
|
am: fb38165516 -s ours
Change-Id: If843b1613311073cb87b6d30ea8180bdee9aaba2
|
|
am: c3d1880ed7 -s ours
Change-Id: I737c400c9dda11a94d8916d5fbeb02c5677546ea
|
|
am: a8f627deea -s ours
Change-Id: I21f67eafc9098eadb2e5a0119b1ad25c937941e0
|
|
1. Replace onImsConnected() with onImsConnected(int)
2. Replace onImsProgressing() with onImsProgressing(int)
3. Add registrationChangeFailed()
Bug: 33430556
Test: m
Merged-In: I14c171494bdcb0d82ed4be0caff8cb52d35421cc
Change-Id: I14c171494bdcb0d82ed4be0caff8cb52d35421cc
|
|
4c0a963a11 -s ours am: feb4c40b2f -s ours am: bf46fafe6b -s ours am: de0acaae42 -s ours
am: a70c867cbb -s ours
Change-Id: Iee95d5c447b5e60a6e4a4fe47146d7dbffa2a6d5
|
|
4c0a963a11 -s ours am: feb4c40b2f -s ours am: bf46fafe6b -s ours
am: de0acaae42 -s ours
Change-Id: Ie7bbbd38bffc2c8985562c8c6c83e18a8693de86
|
|
4c0a963a11 -s ours am: feb4c40b2f -s ours
am: bf46fafe6b -s ours
Change-Id: Icd614f00d976be163e918134392383d04991e1fd
|
|
4c0a963a11 -s ours
am: feb4c40b2f -s ours
Change-Id: I8bcbf272cf87bab70e3f253dc7392a5af3389104
|
|
am: 4c0a963a11 -s ours
Change-Id: Id0e47ff1a27f8676cbbb1d675a858a85854339fa
|
|
|
|
Scenario: A and B are in video call.
A goes to the background, pausing the video.
B attempts to turn off their camera.
The request fails to be interpreted by vendor code.
Reason: This SHOULD really be a request to go from/to:
Audio/TX/RX/Paused --> Audio/RX/Paused
However, it MUST be sent as:
Audio/TX/RX/Paused --> Audio/RX
The introduction of the VideoPauseTracker in N caused the request to be
sent in the former correct format rather than the latter incorrect format.
The VideoPauseTracker attempts to ensure that a request to pause sent by
the framework vs the incall ui are kept in sync (we use pause to disable
video on a call when the data limit is reached). In the process of ensuring
pause and resume requests were handled properly, this code was
fixing the malformed request.
Added a workaround to the code to ensure the requests remain in the same
broken format vendor code depends on.
Test: Manual, unit
Bug: 35304446
Merged-In: I9b974542234d3f567aba3f2996a815e39bc8963e
Change-Id: I9b974542234d3f567aba3f2996a815e39bc8963e
|
|
am: fa3df0bc9e am: c41dd5079d -s ours am: ec046469d1 -s ours
am: 53b731a9db -s ours
Change-Id: Ieb9226c3cf045a9ca49f9d1c32fd1d2f8152695e
|
|
am: fa3df0bc9e am: c41dd5079d -s ours
am: ec046469d1 -s ours
Change-Id: I87615779c7b246add0a01e2d71c232ae8af8dd62
|
|
am: fa3df0bc9e
am: c41dd5079d -s ours
Change-Id: I7c4c942a78db9e3c428dc301db5612b3824614ca
|
|
am: fa3df0bc9e
Change-Id: I11551ae94cd69532a81b8c0d43f5cfbc901f28b5
|
|
am: 138b4a620d
Change-Id: Ib617c2dfe895286a817fb06675c5510d071012c5
|
|
If the ImsService goes down, the stale binder interfaces
to the old service still get returned by ImsManager. This
change triggers the ImsManager to fetch the binder interfaces
again if the cached one is dead.
Bug: 62723694
Test: Manual, test procedure outlined in bug
Merged-In: I90e3df344785a5bc3818bc9bb24a2735f068058a
Change-Id: I64c1c668602d88663220a50c2e45ae4f970ac302
|
|
4189380 snap-temp-L90600000083186678
Change-Id: I8bebdfb2383ac3e56b4fefb79a08e5e35ac7d2d8
|
|
am: 8795220e73
Change-Id: Ibbf15360f0961c9b0bd66477a95f4ff9abc1b211
|
|
am: 0b5242f5c8
Change-Id: I16fbcd6d1542b8b01d033c8ffd1f2c19d8185c1f
|
|
am: 28552fbbf0
Change-Id: I4992a41ae4a1099a08ff6a2cef32b1200bd8a3c2
|
|
am: 567a70c96d
Change-Id: I35a50f702a8055ece40ee444a645f38515553681
|
|
If the request being sent to the video provider is to resume the video,
but the video stream is already resumed, do not send this request to the
modem.
In the case of swapping between calls, the video appears to resume
automatically on the modem-side, so sending another resume request is
redundant.
Also, in VideoPauseTracker, correcting the case where we get a resume
request, but there are no remaining pause requests in the tracker.
Although that case shouldn't run up in reality, if it did we should still
let the resume request pass along (since it would otherwise be re-written
as a pause).
Test: Manual test.
Change-Id: Ib9b9acaf2d92b1485e4766a13701fd472d6c117d
Fixes: 63606238
|
|
ImsVideoCallProviderWrapper was modified recently to check for the case
where the video is paused, and the video state changes to an unpaused state.
It used this to trigger a clear of the video pause tracker.
It did this by checking if the video pause tracker thought the video was
paused. In reality, it makes more sense for a change in the videostate
from paused to unpaused to be detected, and THAT used as a basis to
clear the video pause tracker.
The previous functionality caused a problem when the user, in quick
succession:
1. Turned off the camera
2. Went to the background.
The two requests would hit the framework, causing the video pause
tracker to record the current video state as paused (as requested by
the user). Shortly thereafter, the modem reports the fact that the
camera is off with a state of Audio RX. This would be misinterpreted
and cause the pause tracker to be cleared.
Test: Manually tested the bug, as well as regression tested b/62784036.
Change-Id: Iaa736e93e05ef3ae5dec21cd8ebc18be464f18ae
Fixes: 63410964
|
|
4165363 snap-temp-L49300000080728237
Change-Id: Ib2949b66c58ec664f36cbb8f777d003c78aa951d
|
|
|
|
efa7be99a6
am: f1138ad69d
Change-Id: Idf88846a5cb3e89a4256475ca8579ab43ba1c2ec
|
|
am: efa7be99a6
Change-Id: I99b53926105c689ac19c8805035061e106a8f0a1
|
|
ImsVideoCallProviderWrapper was modified recently to check for the case
where the video is paused, and the video state changes to an unpaused state.
It used this to trigger a clear of the video pause tracker.
It did this by checking if the video pause tracker thought the video was
paused. In reality, it makes more sense for a change in the videostate
from paused to unpaused to be detected, and THAT used as a basis to
clear the video pause tracker.
The previous functionality caused a problem when the user, in quick
succession:
1. Turned off the camera
2. Went to the background.
The two requests would hit the framework, causing the video pause
tracker to record the current video state as paused (as requested by
the user). Shortly thereafter, the modem reports the fact that the
camera is off with a state of Audio RX. This would be misinterpreted
and cause the pause tracker to be cleared.
Test: Manually tested the bug, as well as regression tested b/62784036.
Change-Id: Iaa736e93e05ef3ae5dec21cd8ebc18be464f18ae
Fixes: 63410964
|