Age | Commit message (Collapse) | Author |
|
Change-Id: Ieac27294f4069b2cff17bb39a0954f74320ad943
|
|
Test: Existing tests
PiperOrigin-RevId: 202589482
Change-Id: I6982e4069d30032bf46caf3c9984dfc0e7196f6f
|
|
Test: SpeedDialAdapterTest
PiperOrigin-RevId: 202543795
Change-Id: I1eec7a7328da3037b4d1cbacc7d9b211305e3eb0
|
|
This needs to be moved in order to delete DialtactsActivity.
Bug: 109931227
Test: none
PiperOrigin-RevId: 199820125
Change-Id: I2b2c190152834bd1d0d0510f8e01110f05a5a8f3
|
|
END_PUBLIC
The bottom nav buttons do not work correctly when this flag is not enabled (see bugs). This flag is intended to always be true via an experiment but can be false for example when the user clears data or just launched dialer for the first time and hasn't received config flags.
It is not likely that we will ever want to turn off this behavior, so this change simply removes all support for it.
TEST=unit
Bug: 109762667,79485008
Test: unit
PiperOrigin-RevId: 199660314
Change-Id: I105f6c553c7541673b6d5dd7abf4d29f566e155f
|
|
It no longer provides any value, so just use dagger directly.
Bug: 80441695
Test: tap
PiperOrigin-RevId: 198806461
Change-Id: Id607abb65b77633bce511ad0c943ac19453a85d5
|
|
This enables us to have Google-Sans font in GoogleDialer and Roboto in AOSP.
Bug: 79883035
Test: tap
PiperOrigin-RevId: 197774497
Change-Id: I1d490ab196a444c62e439444627d659fc42973ea
|
|
- README on how to properly theme Dialer going forward.
- Migrated all widgets to use global colors.
- Removed all activity and application themes where it wasn't necessary.
- Added themeing test rule for Espresso tests.
Bug: 79883035
Test: tap
PiperOrigin-RevId: 197634256
Change-Id: I4b7d94d45aeeb59d484b0069fdd1e200a654910b
|
|
TelecomUtil.has*Permission() pass if the dialer is the default dialer. In reality most API does not allow the default dialer do whatever they want. PermissionUtil should be used instead.
TEST=uabdullah please fix your "Temporary" @Ignore
Bug: 77907588
Test: uabdullah please fix your "Temporary" @Ignore
PiperOrigin-RevId: 197442842
Change-Id: I1e6f275e2b8e6d3cfa54ddb8cd24f7d47f9462ca
|
|
Refactor Duo disclosure card to general promotion card.
Bug: 78905507
Test: unit tests
PiperOrigin-RevId: 197436677
Change-Id: I511c39308cadfb96ee4519b71ca29b75d0e6750b
|
|
Bug: 79183384
Test: manual
PiperOrigin-RevId: 196344851
Change-Id: I9f5c0e52cb4efe9e63e2c19a4f62ee0b9a23412f
|
|
Test: presubmit
PiperOrigin-RevId: 196285108
Change-Id: Ie424d231ced4066b0d5b734bebae443942994943
|
|
Bug: 67596257
Test: unit tests
PiperOrigin-RevId: 196049621
Change-Id: I6f9c6292b1d56e3faf7808aa668b03d07230a70b
|
|
OldMainPeer and
Always fetch the voicemail status when resuming OldMainPeerActivity. There is no reason why this should not happen.
TEST=N/A
Bug: 79365547
Test: N/A
PiperOrigin-RevId: 195744525
Change-Id: Ie31551bfecd5056b0b3b559946e9cd2c8f6ef23f
|
|
Bug: 77807682
Test: listnr
PiperOrigin-RevId: 195477904
Change-Id: I5408f4fad9bbc20ff7ce72b25201c23b11a35c43
|
|
missed calls.
Bug: 78458610
Test: MainActivityOldPeerTest
PiperOrigin-RevId: 194555035
Change-Id: Ib3ef02ec3f4a8ce7cfce6d052fce3b9b6daf75e5
|
|
Bug: 36841782
Test: SpeedDialAdapterTest
PiperOrigin-RevId: 194210091
Change-Id: I5b8ad5ca43ee6f519de09ad2a8b1b959637a825b
|
|
Bug: 36841782
Test: OldMainActivityPeerTest
PiperOrigin-RevId: 192647371
Change-Id: I3fff1784ce642b86f1e87a27e38737833f74c6b0
|
|
This makes the old peer read the CallLogConfig#isNewVoicemailFragmentEnabled and show the old or new fragment accordingly.
If the user is viewing the NewVoicemail and the CallLogConfig needs to disable the framework, the new fragment is immediately replaced with the old one. This is necessary because if the user were to scroll the fragment, the AnnotatedCallLog database would be read, which would trigger creation.
I tested this by flipping flags and observing underlying data being removed:
> dialer-cmd configprovider set new_voicemail_fragment_enabled false
> adb shell ls /data/data/com.google.android.dialer/databases/ && echo && adb shell cat /data/user_de/0/com.google.android.dialer/shared_prefs/com.google.android.dialer_preferences.xml
I test flipping flags back and forth on the voicemail tab, call log tab and ensuring that they are independent.
Bug: 77601968
Test: unit and manual. Some tests are failing, so to ensure we can have the voicemail ready for the bug bash tomorrow, I've ignored them temporarily but will be fixed in a follow up CL (tracked by b/77601893)
PiperOrigin-RevId: 191738860
Change-Id: I24ca38b862e98324cf802a3020e7e9df31c0b966
|
|
Test: unit
PiperOrigin-RevId: 191380073
Change-Id: If554d5ee0c55754802692a364bae591c3951c060
|
|
This makes the old peer read the CallLogConfig#isNewCallLogFragmentEnabled and show the old or new fragment accordingly.
If the user is viewing the NewCallLog and the CallLogConfig needs to disable the framework, the new fragment is immediately replaced with the old one. This is necessary because if the user were to scroll the fragment, the AnnotatedCallLog and PhoneLookupHistory databases would be read, which would trigger creation.
I don't expect this to be a common case because 1) we hopefully never have to disable the framework and 2) Framework is only updated on Phenotype broadcasts and JobScheduler jobs, which hopefully don't typically happen when user is viewing the call log. However, I still want to make sure that if it happens we don't irreversibly break users when we turn the framework back on.
I tested this by flipping flags and observing underlying data being removed:
> dialer-cmd configprovider set new_voicemail_fragment_enabled false
> adb shell ls /data/data/com.google.android.dialer/databases/ && echo && adb shell cat /data/user_de/0/com.google.android.dialer/shared_prefs/com.google.android.dialer_preferences.xml
I test flipping flags back and forth on the call log tab, speed dial tab, and while the activity was paused (pressing Home after viewing call log).
Note that this CL doesn't address showing missed calls and badge counts correctly with the new fragment; that will come in a later CL.
Bug: 74821995
Test: unit and manual
PiperOrigin-RevId: 190706481
Change-Id: I618d9c1649169abd65733502cfebc662a835e787
|
|
There were 2 issues at play here:
1) views not being able to leave the list view bounds
2) RemoveView not getting drag events.
Their resolutions are:
1) add a drag drop listener to the root layout of the activity, now the view
can be dragged anywhere.
2) Drag events are only sent to views that are visible, so we no longer set the
remove view visibility to GONE and instead set it's contents to GONE.
Bug: 76086197
Test: manual
PiperOrigin-RevId: 190526568
Change-Id: I3360015f65a134a896601d6298d07163844e302c
|
|
Test: Existing tests
PiperOrigin-RevId: 190516504
Change-Id: I5fa9e123b45beb9728257ecd160a348fb3f4732c
|
|
There is still some jank on first open, but it's much less janky
on close and consecutive open calls.
Test: existing tests confirm no regressions
PiperOrigin-RevId: 189802733
Change-Id: I49d6c2def7c33be0fdbb79c89772a5e4513cde3b
|
|
Bug: 74202944
Test: Existing tests
PiperOrigin-RevId: 189095432
Change-Id: I13015ee6c5767edd95b78c3fb2e7338495e9e1d7
|
|
Fast consercutive calls to #showFragment can have undesirable effects because
fragment manager doesn't handle transactions sychronously. This CL resolves one
of the scanrios where voicemail fetch status was calling #showFragment nearly
simulataniously to the #onHandleIntent call.
This issue may show itself again and I'm looking into more long term solutions
but we should be fine in the short term since the all of our fragment logic
is implemented.
Bug: 74051208,74621909
Test: manual
PiperOrigin-RevId: 188956984
Change-Id: I0796e31b03e0b749ae7e81f82859ea6f814a5fb5
|
|
Test: existing
PiperOrigin-RevId: 188928916
Change-Id: I2b6fb73545194fa175526a77ce2a76b1d23c049d
|
|
Keyboard should close when:
- requeting permission
- placing a call
- leaving the app
Search should close when:
- placing a call
- leaving the app
Bug: 74235853
Test: search closing onPause tests already exist (MainActivityOldPeerSearchIntegrationTest#placingCallFromSearchClosesSearch)
PiperOrigin-RevId: 188812026
Change-Id: Iaee084c59b4c514d10375deff5d73d5a456ef9df
|
|
Test: MainActivityOldPeerTest
PiperOrigin-RevId: 188409482
Change-Id: I0c132c49d63b9af849522851c55f51d431faa603
|
|
My hypothesis is that trying to commit multiple seperate transactions back to
back causes the fragment container to get into a weird state. So this change
has two parts:
- Disable preloading call log
- Combine the seperate hide/show transactions into one transaction
- Don't call conflicting transactions (i.e. hide then immediately show)
Bug: 74051208
Test: existing tests, manual
PiperOrigin-RevId: 188215791
Change-Id: I699fc02f1e2716bc019a29dc047ee4bc0d52df35
|
|
- Add screen events for 4 tabs, dialpad and search.
- Add impressions for opening MainActivity with tabs/dialpad (non user tab selection).
- Add impression for VVM visible.
Bug: 72525843
Test: MainActivityOldPeerTest, MainSearchControllerTest
PiperOrigin-RevId: 188090249
Change-Id: Ifdf3519f07d7230f20b5d82691a96747b1944d63
|
|
Bug: 72525843
Test: none
PiperOrigin-RevId: 187500135
Change-Id: Iaa73b9355a6b5c299f73fd113eb1f74a3eb47dd4
|
|
Test: n/a
PiperOrigin-RevId: 187442952
Change-Id: I9463e2c976102276ebc5886531397ad0cf160b78
|
|
Default is set to true but if we see issues with startup latency we can disable
this server side.
Test: n/a
PiperOrigin-RevId: 187419851
Change-Id: I6d1debfed86dbcaf3ee73ec0906e514a2687e2c0
|
|
- 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
|
|
This CL helps to ensure that when the VVM settings toggle is turned on or off, or a sim is swapped, inserted or removed the VM tab disappears and appears, just like it currently does. When a VM tab disappears we also move to the speed dial index.
Bug: 73123614,73998717
Test: N/A
PiperOrigin-RevId: 187400703
Change-Id: I76a0b43da86713caa67956413a39299c7ecbc8d1
|
|
Bug: 73123614
Test: N/A
PiperOrigin-RevId: 187255950
Change-Id: I9ab50a7a8052f325f1743721bf6432e6c4787a4e
|
|
Test: manual, going between tabs hides/shows the fab properly when ToS is (in)visible.
PiperOrigin-RevId: 187253210
Change-Id: Ied9ea44892786268b9dfa68816840dfbfc74aa6e
|
|
Bug: 70989605
Test: ShowBlockReportSpamDialogNotifierEndToEndTest + Manual
PiperOrigin-RevId: 187047450
Change-Id: I23c3929135bcfe5c14fe317ef65f628dc126027f
|
|
- Normalized the search query returned from DialpadFragment
- Dial button now updates when given a psuedo emergency number
- 'Clear frequents' now displays and functions properly in the menu
- Added simulator to the menu
Bug: 72525324
Test: added tests for clear frequents (only prod feature).
PiperOrigin-RevId: 186875815
Change-Id: I3bad3c71b355b987fc85777550bfa1de5028c3a4
|
|
- Handle Calls.CONTENT_TYPE intents
- Handle Add Call intents
- Handle onActivityResults
Bug: 72525324,72525840
Test: implemented
PiperOrigin-RevId: 186523438
Change-Id: Ia014e5e10ee0be2f32a09df79b3ade12d09814e9
|
|
In the case where the user is not able to dial into the voicemail tab, or there exists another voicemail app, or VVM is not supported, we do not want to show the VM tab.
This CL does not update the activity when a sim is inserted/removed.
Bug: 73123614
Test: Unit tests
PiperOrigin-RevId: 186433072
Change-Id: I0396b1e15c9a4740eee721af89dbfdf95696cace
|
|
- Nearby places promo now displays properly
- Dialpad now properly handles dial intents
- placing calls from search now closes search
- placing calls from search now closes the keyboard
- toolbar shadow is now visible when search is started
from the dialpad.
Bug: 72525324
Test: MainActivityOldPeerSearchIntegrationTest
PiperOrigin-RevId: 186390952
Change-Id: I7e10ef0499c787da2d1820cae915f2d42645303b
|
|
- No longer crashes when entering mw-mode while in multiselect
- Configuration changes now properly restore bottom nav visibility
- toolbar shadow is now only visible in search
Bug: 72525324
Test: MainActivityOldPeerSearchIntegrationTest
PiperOrigin-RevId: 186037379
Change-Id: I5fc00c8091e85fc67482b2131944fb776626d06f
|
|
Including:
- switching tabs
- touch search list
- press back button
- click search bar and voice button
- click FAB
Test: MainActivityOldPeerTest, MainSearchControllerTest
PiperOrigin-RevId: 185875596
Change-Id: Ie7824ce2f7a2570327abdb35cef1538cad786e73
|
|
Bug: 72525950
Test: disabled GoogleDialtactsActivity and was able to place a call over wifi.
PiperOrigin-RevId: 185867741
Change-Id: Id24b2318a8557a1b3262ff99b62303f4555728ed
|
|
This change doesn't implement any of the menu actinos, it just abstracts some
components so that the GoogleDialer toolbar menu can show help and feedback
(and thus, AOSP won't).
Bug: 72526274
Test: implemented
PiperOrigin-RevId: 185033936
Change-Id: I30f8cde6705145ef95efcfc82973a8aa2b16e4ee
|
|
Bug: 72525324
Test: manual
PiperOrigin-RevId: 184615350
Change-Id: Ic5701d67111e38f73dfa4be31dd89115ad7f5bb8
|
|
This CL has a few changes of varying relevance:
Most Relevance:
- MissedCallNotifications will open MainActivity if the component is enabled
(Meaning the launcher is in their app drawer and the flag is flipped).
- Implemented show tab intent (open MainActivity directly to a specific tab)
- Tests
Some Relevance:
- Implemented checking for ACTION_DIAL intents (dialpad will open immediately)
- Tests
Not Relevant but nice QoL changes:
- Added tests for missed calls being marked as read
- Makes espresso tests more horizontal to reduce timeouts
-
Bug: 72525550,72525615
Test: implemented
PiperOrigin-RevId: 184600627
Change-Id: If96a44ce252e97c022ebc1b58fa783b3326035e7
|
|
This change moves the remove button to overlap the search bar
instead of reside underneath it since we no longer have top tabs.
Bug: 72722364
Test: manual
PiperOrigin-RevId: 184347110
Change-Id: I5bfa70fec9dd7ee6ee0b7270039931f9277291f4
|
|
This solution has a couple hacks in it because the DialtactsActivity has a
non-support ActionBar and MainActivity has a support Toolbar. When multiselect
is implemented for NewVoicemailFragment, we should be careful to use support
action mode instead of non-support action mode so that the transitions and
styling are seamless and consistent.
Bug: 72722083
Test: manual
PiperOrigin-RevId: 184343414
Change-Id: Id16652de2d0add7b7c304d1cedb429fe9b1cf338
|
|
This change updates MainActivity to defer lifecycle callbacks and other
relevant methods to which ever peer is active, old or new.
The old peer implements the logic for the old fragments.
The new peer implements the logic for the new fragments.
MainActivity implements the logic that is shared or common between the two like
last tab, post call, search, dialpad, ect.
Bug: 72525324
Test: pending
PiperOrigin-RevId: 184317828
Change-Id: Ie73733f2a3837c9d63e54cf5b142984633340731
|