| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously the same action instance is used every time the PreCallActivity is resumed. This causes some state to be retain, for example the isDiscarding state on CallingAccountSelector prevents canceling the next dialog to abort the call.
Actions should not retain state between activity life cycles.
TEST=TAP
Bug: 79692264
Test: TAP
PiperOrigin-RevId: 196696224
Change-Id: Ifa604f431563dd1fb123a42e2a64b34c001e897d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
call log.
For some reason not understood, startActivity with the call intent causes the current activity (MainActivity) to be paused, resumed, and paused again. This results in an opportunity to double-tap the row which causes the InCallUi to open in bubble mode (this is also not well understood).
In any event, PreCall.start eventually uses TelecomManager to place the call rather than startActivity, which is presumably the thing that fixes the problem.
Also refactored TestPreCallModule to remove the many test implementations of PreCall and remove the static field in the module which could cause test interference.
TEST=manual
Bug: 78187587
Test: manual
PiperOrigin-RevId: 193596093
Change-Id: I933020d33db1c158628f14b30c2681c59c86201b
|
| |
|
|
|
|
|
|
|
| |
See class comment on UkRegionPrefixInInternationalFormatHandler
Bug: 32501490
Test: Unit tests
PiperOrigin-RevId: 190296011
Change-Id: I6f01935f022fc288ad702735b38cb297fb9d2621
|
| |
|
|
|
|
|
|
|
| |
If CALL_PHONE is missing PreCall will abort immediately and show a toast.
Bug: 70565989,70566029
Test: PermissionCheckActionTest
PiperOrigin-RevId: 179123070
Change-Id: I0d43c6acd44e77562752c871bed0223b2f787dde
|
| |
|
|
|
|
|
| |
Bug: 69618691
Test: CallingAccountSelectorTest
PiperOrigin-RevId: 177062349
Change-Id: I4bc9098d06c541b607cca293269cf3489077b6c2
|
| |
|
|
|
|
|
|
|
|
|
| |
If no actions require an activity, instead of launching the PreCallActivity, all actions will be performed immediately, and the call intent will be sent to telecom directly.
This reduces the latency & risk when mutli SIM is not supported.
Bug: 68953196
Test: PreCallImplTest, HeadlessPreCallCoordinatorTest
PiperOrigin-RevId: 176032790
Change-Id: I03258e8643f18c65a8e5b1a84b18b71b30638044
|
| |
|
|
|
|
|
|
|
| |
This CL replaces all instance of CallIntentBuilder.build() with PreCall.getIntent(), which when run as an activity, will finish building the intent with user interaction.
Bug: 64216442
Test: manual
PiperOrigin-RevId: 174924323
Change-Id: If41868df4c7ed078d03bd3431fa85b8947056a01
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
CallingAccountSelector examines the CallIntentBuilder, and if the PhoneAccountHandle is missing on a multi-SIM device while the default is not set, it will show a dialog to let the user select it. This step used to be after the in call UI is launched and telecom wants dialer to disambiguate. This step is moved to pre call as dialer need more control, like voicemail calls should always prompt, or the preferred SIM info might be available. This also allows telecom to send the selected PhoneAccountHandle to other apps so they have more information on how to rewrite numbers.
AssistedDialAction replaces the step previously in CallIntentBuilder.build(), and rewrites the URI.
Pre-call actions are not hooked up for dialing in this CL yet, assisted dialing will still be broken.
Bug: 64216442
Test: CallingAccountSelectorTest, AssistedDialActionTest
PiperOrigin-RevId: 174917321
Change-Id: Iba2e9092f83c036b402d4044a48ff5c44e806210
|
|
|
When the user makes a call, the PreCallCoordinator will get a list of actions to perform from PreCallActionProviderComponent and apply them to the pending CallIntentBuilder, before sending the built intent to telecom
Bug: 64216442
Test: PreCallExecutorImplTest
PiperOrigin-RevId: 174911537
Change-Id: Ide5ec431d4e6e7879fcdfdbbbd7ea5eed9963b2c
|
