Age | Commit message (Collapse) | Author |
|
Bug: 77908301
Test: opened dialpad, didn't crash
PiperOrigin-RevId: 192654487
Change-Id: If5bf9b6df7f15364358fb601d154d4bb99dd5b55
|
|
- Content description for voicemail button is now "1... double tap and hold to
call vociemail"
- Content description for 0 button is now "0... double tap and hold for plus
symbol"
Bug: 19621015,62712616
Test: manual + a11y office hours
PiperOrigin-RevId: 191673375
Change-Id: I9b5d8d875f1bf218be6fcc33dff4ac9e479e4f43
|
|
The warning is shown when there is no service, and the carrier requires the message to be shown because they cannot make emergency call over wifi.
Bug: 68030294
Test: Unit tests, integration tests.
PiperOrigin-RevId: 190241868
Change-Id: Ia6b838ac1e8e62ad6b40d97c1cf1a970491c1e6f
|
|
In order to correctly show animation, we have to ensure:
1. fab.scaleIn() is not called before dialpad is slide up.
2. fab is invisible before scaleIn is called.
Caveat:
This change is not tested on old UI (DialtactsActivity) since it's deprecated.
Test: manual
PiperOrigin-RevId: 189765153
Change-Id: Iada96b2789f96ca1612ae2048020a649f8b57b6b
|
|
Repro steps:
1. open dialer, click on FAB to open dialpad
2. make outgoing call, end call, press home
3. enable WiFi call
4. open dialer again, click on FAB to open dialpad
This is caused by change icon called after the FAB is visible and scaleIn won't do anything since it's already visible. But for some reason the icon is changed so nothing is drawn on the screen when the dialpad slide up. (dialpadfragment is visible even before it's slide up before user trigger it)
The fix is to scaleOut the FAB when the fragment onStop thus the changed icon will be correctly drawn.
Bug: 74586190
Test: manual
PiperOrigin-RevId: 189629441
Change-Id: I3dcbedcd171c992e5df14bff35758fce1bb67bc1
|
|
Bug: 73718977
Test: MotorolaUtilsTest & PhoneNumberHelperTest
PiperOrigin-RevId: 187889473
Change-Id: I00d58071ba18ddce5a09c07de9edd2d0956d6478
|
|
Bug: 73718977
Test: PhoneNumberHelperTest
PiperOrigin-RevId: 187540382
Change-Id: I814ec62b2215c24b8cde3442c5dc83d98ad87164
|
|
- Never show the dialpad chooser in MainActivity.
- If the call log changed while dialer was in the background, it would trigger
the content observer to fetch the new info, which would request it's parent
that wasn't there. Now we register/unregister them in onResume/onPause. This
is safe to do because we force refresh the data onResume anyways, so any
changes will still be shown.
Bug: 73972084,73975555,73995512
Test: manual
PiperOrigin-RevId: 187407058
Change-Id: Iae86dabbcb852398bb2b9df4627e234261ab8030
|
|
Bug: 72525324
Test: existing
PiperOrigin-RevId: 183776841
Change-Id: Ia78002d3da823a228cf5a29f93cd53ad21105f94
|
|
Methods moved to TelecomUtils
Test: Unit tests
PiperOrigin-RevId: 183305626
Change-Id: Idd6604e58c06a36066bd49870849dd71747969c6
|
|
There are a few interesting UX niceties that we support in search:
1) When in regular search with an empty query, close the UI if the user
touches the blank space.
2) When in regular search with a non-empty query, hide the keyboard if the
user touches the the list so they can see all results.
2) When in dialpad search with an empty query, close the UI if the user
touches the blank space.
3) When in dialpad search with a non-empty query, hide the dialpad so the user
can see the full list of results.
This change also adds logic to transfer the dialpad query to the search bar.
Bug: 64655802
Test: MainActivityIntegrationTest
PiperOrigin-RevId: 182434126
Change-Id: Iabb73b0018fa20e2811010a73a35d3aa3b35343b
|
|
Toolbar, Dialpad, Bottom Nav, FAB and Search now all show
and hide properly according to the state of the application.
Follow up CLs will include:
- saving/restoring state
- sending query to search fragment to display results
Bug: 181512198
Test: MainActivityIntegrationTest
PiperOrigin-RevId: 182259200
Change-Id: I1309d8df2a5425bf051e52a459a1f78e1157fe08
|
|
This change adds the existing dialpad to the new UI and the animation logic
required to show/hide it along with the toolbar. A follow up CL will come
afterwards to combine these animations with the toolbar expanding/collapsing.
known issue: bottom nav appears over the dialpad.
Bug: 181512198
Test: MainActivityTest
PiperOrigin-RevId: 181777370
Change-Id: Ief1591174ebca3a709df6d1d38c8b8ecbdc1878e
|
|
Test: Existing tests
PiperOrigin-RevId: 180230450
Change-Id: I0b2589cfeeaef81e42a04efa48af24b4e4d0e95f
|
|
Copybara is fixed for AOSP export
Bug: 68665330
Test: rollback
PiperOrigin-RevId: 177480870
Change-Id: I0ba38e213bb840436fa6dafc4af0a79019ee93f4
|
|
Argentina mobile numbers.
Bug: 30224215
Test: DialerPhoneNumberFormattingTextWatcherTest, DialpadFragmentIntegrationTest
PiperOrigin-RevId: 177218942
Change-Id: Id6eaaad2f6d81e591d59a1d8444f45fb06f3f8d5
|
|
Bug: 69463065
Test: manual
PiperOrigin-RevId: 176399153
Change-Id: I699688ab47c1ba497a0b6bb3301380a8e06f2ee2
|
|
There must be a bug in FloatingActionButton because when you call
setImageDrawable multiple times (possibly with the same drawable/icon), the FAB
renders with no icon present. That's why the icon would disappear in
Fragment#onResume.
Bug: 69006360
Test: manual
PiperOrigin-RevId: 175878924
Change-Id: I1c36be3f9aeb003410f0bdbb9d52b5a483262f03
|
|
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
|
|
All voicemails are called by using CallIntentBuilder.forVoicemail() so the PhoneAccountHandle can be designated. A future CL will use dialogs to customize the call (multi SIM selection, RTT, etc.)
As a result voicemail error messages and legacy voicemail notifications will call the account it is received from directly.
Bug: 64216442
Test: Unit tests
PiperOrigin-RevId: 174784322
Change-Id: Ibe1c57bc7852e3d55a39a0cc2da19b6a79954c0f
|
|
We now use dagger everywhere for consistency and explicitness.
Test: tap
PiperOrigin-RevId: 174071122
Change-Id: I15d2f8261a7b753353be9e7d3b80692aa0c1b64d
|
|
By always creating executor services via dagger, we can now bind special versions during espresso tests that can implement idling resources. We should be using idling resources during espresso tests for threads that we create ourselves, because espresso does not know about them.
Hopefully this reduces some of the flakiness of espresso tests that we have today.
This required converting all existing calls to DialerExecutors to pass a context used to fetch the component, and also required creating new application classes for espresso tests.
Test: temporarily added a task which just slept to DialtactsActivity and verified that its integration test failed due to idling resource timeout
PiperOrigin-RevId: 173334773
Change-Id: I876a93022d235d62cfc377bf5b06687e21a34758
|
|
Bug: 67419607
Test: manual
PiperOrigin-RevId: 172349180
Change-Id: I305f8a0e5ae90b2e5e8f77772edfb0b973aca096
|
|
One of the biggest issues with the FAB is that it doesn't
scale in/out properly. It looked more like setVisibility was
being called instead. This CL migrates the FAB controller to
use the built in scale in/out methods #show and #hide and the
animation is much nicer.
Some of the other issues were:
- Now scaling animation is correct and visible.
- No longer flashes when going in/out of search.
- No longer shows on top of the return to call controller.
- No longer bugs when switching between VVM TOS and contacts.
- No longer shows FAB over VVM TOS when entering/exiting search
Bug: 62588192,35359563,64116334,27458212,37991480,67419607
Test: manual
PiperOrigin-RevId: 171608105
Change-Id: I9b3f61df35abf3659a432adf411b1b7d20eba683
|
|
Bug: 65212837
Test: DialpadFragmentTest
PiperOrigin-RevId: 168745371
Change-Id: I62da45cdac58e3387343589b952e5d6bce7a4ee2
|
|
Improved behavior of back button in search ui.
Pressing the back button in the search UI now functions as follows:
- If the keyboard is opened, the keyboard is minimized
- If the dialpad is opened, the dialpad is closed
- If the keyboard and dialpad is closed, the search ui is closed
Our existing behavior was dependent on whether a query had been built yet.
basically, if the user pressed back with no query selected, the search ui
was closed.
From the bugbash:
7. No scroll bar in the search results if the results do not fill the entire
view. The keyboard overlaps the results and there is no way to get to the
enter list without dismissing the keyboard.
10. Dismiss the keyboard on tapping the down arrow on the keyboard. Arrow
points down but works like back button
Bug: 62685859,63691995,63939331,64137632,64902476
Test: manual
PiperOrigin-RevId: 168004913
Change-Id: Ia566fce6d90454a3eae6ecccfa81ce7e909e878f
|
|
*** Reason for rollback ***
Based off a CL that needs to be rolled back.
*** Original change description ***
Improved behavior of back button in search ui.
Pressing the back button in the search UI now functions as follows:
- If the keyboard is opened, the keyboard is minimized
- If the dialpad is opened, the dialpad is closed
- If the keyboard and dialpad is closed, the search ui is closed
Our existing behavior was dependent on whether a query had been built yet.
basically, if the user pressed back with no query selected, the search ui
was closed.
From the bugbash:
7. No scroll bar in the search...
***
Bug: 64902476,64137632,62685859,63691995,63939331
Test: n/a
PiperOrigin-RevId: 167661409
Change-Id: I0627d54af33fb55c64b5edcd459dde6a73d93266
|
|
Pressing the back button in the search UI now functions as follows:
- If the keyboard is opened, the keyboard is minimized
- If the dialpad is opened, the dialpad is closed
- If the keyboard and dialpad is closed, the search ui is closed
Our existing behavior was dependent on whether a query had been built yet.
basically, if the user pressed back with no query selected, the search ui
was closed.
From the bugbash:
7. No scroll bar in the search results if the results do not fill the entire
view. The keyboard overlaps the results and there is no way to get to the
enter list without dismissing the keyboard.
10. Dismiss the keyboard on tapping the down arrow on the keyboard. Arrow
points down but works like back button
Bug: 64902476,64137632,62685859,63691995,63939331
Test: manual
PiperOrigin-RevId: 167332236
Change-Id: I1c0b5b429316dae119b5fb21be4303d7fe052e35
|
|
The TelecomManager#isInCall method returns true anytime the user is in a call.
Starting in O, the APIs include support for self-managed ConnectionServices so that other apps like Duo can tell Telecom about its calls. So, if the user is in a Duo call, isInCall would return true.
Dialer uses this to determine whether to show the "return to call in progress" when Dialer is launched.
Instead, Dialer should use TelecomManager#isInManagedCall, which only returns true if the device is in a managed call which Dialer would know about.
Bug: 36991070
Test: none
PiperOrigin-RevId: 167200903
Change-Id: I12ac7b893dcbfa2fc842ca5ab356fbbc490a098b
|
|
Bug: 64129606
Test: none
PiperOrigin-RevId: 167174480
Change-Id: I4b5a494b0b334b42ee053c4d4d1e81d7699461d0
|
|
Previously, Android's Dialer app was developed in an internal Google
source control system and only exported to public during AOSP drops.
The Dialer team is now switching to a public development model similar
to the telephony team.
This CL represents all internal Google changes that were committed to
Dialer between the public O release and today's tip of tree on internal
master. This CL squashes those changes into a single commit.
In subsequent changes, changes will be exported on a per-commit basis.
Test: make, flash install, run
Merged-In: I45270eaa8ce732d71a1bd84b08c7fa0e99af3160
Change-Id: I529aaeb88535b9533c0ae4ef4e6c1222d4e0f1c8
PiperOrigin-RevId: 167068436
|