Age | Commit message (Collapse) | Author |
|
Dialer has 3 files which contain preferences, currently we only backup com.google.android.dialer_preferences. This CL adds the support to backup com.google.android.dialer and com.android.dialer preferences.
Bug: 64363054
Test: DialerPersistentBackupAgentTest
PiperOrigin-RevId: 165510264
Change-Id: Icca707377702fafdafe148b791fe323606254345
|
|
This cl adds a transcription backfill service to transcribe old voicemails. This service queries the database for any voicemails without a transcription and whose transcription_state column has not been set and schedules a transcription task to update them. This service is only run once, after the user accepts the voicemail TOS and we
have an un-metered network connection.
Bug: 62423649
Test: manual and updated unit tests
PiperOrigin-RevId: 165486104
Change-Id: Ic85c9d728937411638074fec07cf44bb83862acb
|
|
A strict violation was being caused by calling this on the main thread:
android.telephony.PhoneNumberFormattingTextWatcher.<init>(PhoneNumberFormattingTextWatcher.java:71)
We now initialize the watcher on a background thread and pass it back to the main thread to be attached to the textview.
Behavior before: Dialpad fragment would fail to appear until libphonenumber finished (verified by adding sleep and observing)
Behavior after: Dialpad fragment loads immediately, but formatting is not enabled until libphonenumber finishes reading metadata. When adding sleeps, I could type "4084" before init finished and it would remain unformatted. When init finished I could type another character like "6" and the text view would be correctly updated to "408-46".
Bug: 64716944
Test: manual
PiperOrigin-RevId: 165480191
Change-Id: Ie1136a5a0e0b7ed66d4882e96c5830ca1e7523f0
|
|
Previously incallui/spam was being built directly into the incallui
build target. With this CL it's now a standalone build target.
This change should make it easier to test spam notifications.
Bug: 62937258
Test: N/A
Change-Id: I5f238ed7f9a4eaaff4b2a325479d2b6de19bdf07
PiperOrigin-RevId: 165479077
|
|
These are mostly columns that are just copied from the system call log.
Also refactored and implemented new logic for displaying call log durations and dates (not used yet).
Bug: 34672501
Test: existing and new
PiperOrigin-RevId: 165387731
Change-Id: I2bc736d848b5c10e42562e62beea64efdeed9c12
|
|
This is a regression caused by cl/164019619.
Bug: 64533766,64413593
Test: manual
PiperOrigin-RevId: 165356773
Change-Id: I598fd8fa3f77bd1a963858f11f06f953b97e76b0
|
|
Instead of logging expansion and return to call in Bubble.java, add a listener for expansion and send intent with extra package name for return to call. This allows other team to use bubble.
Test: BubbleTest
PiperOrigin-RevId: 165323455
Change-Id: I6e996dbf6c0849612b8bb69e33f8540db20985be
|
|
We have observed ~40% error rate with the synchronous transcription service and
suspect that it is at least partly due to the fact that the synchronous API requires that
we maintain a network connection to the server for up to several minutes.
This cl allows us to also use the asynchronous transcription API which will eliminate
the need for long lived network connections. The client will still block until
the transcription is complete but this will be on a background thread and shouldn't
affect performance.
Also adding more impression logging for the new async API errors.
Bug: 37340510
Test: manual and updated unit tests
PiperOrigin-RevId: 165320593
Change-Id: Icf0e0b38d3a584fa679968592f91db0c42a6f1ee
|
|
Fall back to manual file generation.
Bug: 62875795
Test: checked out head, cherry picked this cl, th
Change-Id: I47b9fb65acb259ead09055783ad5e65718ec8891
|
|
This allows expanding linespacing based on actual fallback fonts
used. Since TextView has the feature on for P and later, Dialer
should assume it's on.
Bug: 28963299
Test: none
Change-Id: I2ce33ac7b5dff76f98bd48d1eef595b48b05106a
|
|
With this CL we now post HIGH_GLOBAL_NOTIFICATION_COUNT_REACHED once per
process lifetime if we post more than 45 notifications.
With this logging we'll have a better understanding of how many users
get into this state.
Note, the exact limit for notifications is 50. We could log an
impression when we reach this limit exactly. This CL doesn't do that to
avoid calling getActiveNotifications() on every notification. We also
limit logging to once per process lifetime for performance reasons too.
Bug: 62937258
Test: NotificationThrottlerTest.highGlobalNotificationCountReached
PiperOrigin-RevId: 165291217
Change-Id: Iad3a8e84b10b9133870fc45579d98b1a0f922ed7
|
|
Android only allows apps to post a maximum of 50 notifications. After
this limit is exhausted no more notifications are allowed. This breaks
features like incoming phone calls.
This CL works around the issue by adding a rate limiter for all cases
where a feature posts more than one notification:
- call quality feedbakc notifications
- missed call notifications
- visual vociemail notifications
- spam notifications
The rate limit is applied on a per group basis. Each group is
allowed a maximum of 10 notifications. When the limit is exceeded
older notifications are cancelled until we're under the threshold.
Some things to note:
- the "group summary" for bundles don't count as a notification
- because we're not implementing a global rate limiter it could be
possible to exceed the maximum system limit. For example, if all
features post their maximum number of notifications and all the "one
off" notifications are shown then we could potentially be above the
limit.
- this CL adds groups for spam and feedback notifications. Those
notifications don't have a group summary so the UI is unchanged.
To enforce all of the above, all notifications must now be posted using
the DialerNotificationManager class. This is a thin wrapper around the
system NotificationManager API. Using the system API directly is now
forbidden.
Bug: 62937258
Test: NotificationRateLimiterTest
PiperOrigin-RevId: 165289368
Change-Id: I40e688bea3af40d829fd32d985cf04d22f7e384a
|
|
There is no change visually but this may resolve an issue with textview being
unable to inflate because of a potential theme bug.
Bug: 64384829
Test: manual
PiperOrigin-RevId: 165254157
Change-Id: I456b3548ce071710f5becd92188b8666f29be5fd
|
|
Previously we were showing Video call as the button in an expanded Duo call log
entry. This is a problem since the primary icon is to start a Duo video call,
there is no way to place a phone call without this fix.
Before: https://drive.google.com/a/google.com/file/d/0B7uuA4cyYX0xa2o2c2c2U2Y5T1E/view?usp=sharing
After: https://drive.google.com/a/google.com/file/d/0B7uuA4cyYX0xM0JqY3JWbHZLdjg/view?usp=sharing
Bug: 64693073
Test: GoogleCallLogAdapterTest
PiperOrigin-RevId: 165247078
Change-Id: If77a14ad717f39e3db2bc58e25e754286f671638
|
|
is supported in Android SDK 26, which is not supported by the Android Auto application.
Bug: 64091458
Test: None. Functionally equivalent
PiperOrigin-RevId: 165234983
Change-Id: I02f4c5be1431a9b2f3122d466abf74a80c2063c1
|
|
This additional metadata will be used by the telephony system
to determine if an outgoing call is eligible for assisted
dialing.
Bug: 63995025
Test: some new unit tests
PiperOrigin-RevId: 165233878
Change-Id: Idee6491e3396b0798ae6c72da53d51367f9fd7ee
|
|
This CL bumps the version name of Dialer from Dialer v12 to Dialer v13. This CL
also bumps the version code from 16***** to 1700000.
I've also set 'version_conf_incrementer_max_version_code' at go/dialer-v12 to 1699999.
Test: N/A
PiperOrigin-RevId: 165233623
Change-Id: I2ed447ddd7db9851a2d63a190799b2fb179bfdb4
|
|
Bug: 37209462
Test: SearchAdapterTest + existing tests
PiperOrigin-RevId: 165210817
Change-Id: I9fb78cf7d964b97e6e95c01437780aa66405f019
|
|
Visual voicemail activation is delayed until the setup wizard is completed, so all settings like user language can be gathered. This is don by monitoring the DEVICE_PROVISIONED system setting.
Previously it is asserted that when DEVICE_PROVISIONED changed it can only be changed to "1". This is not true and the "0" case must be handled by rescheduling the monitoring job.
Bug: 62666193
Test: DeviceProvisionedJobServiceTest
PiperOrigin-RevId: 165210810
Change-Id: I15990eba65cfc41faeec057cd4bc56b6fdc72082
|
|
Fix bubble conference call bugs once and for all.
ReturnToCallController.onDsconnect() is called twice when ending the last call
in conference call: one for the last call itself, one for the parent call. And
we should do nothing for the parent call. This change avoids extra handling in
Bubble.showText() and Bubble.hideAndReset().
Test: ReturnToCallControllerTest
PiperOrigin-RevId: 165195412
Change-Id: Ib21fac6dd7ad9fe85c3070ce1295f63a91c61a02
|
|
Updated the pixel feature to be nested under the correct parent element.
Bug: 62339559
Test: blaze build java/com/google/android/apps/dialer:dialer_pixel2017 &&
PiperOrigin-RevId: 165181980
Change-Id: I6e84c3dd72adef3bbc2ceff1d472d2dce2146c6b
|
|
This is being moved from DialtactsActivity#onCreate in order to provide better coverage (since App#onCreate is called earlier).
Additionally, to de-risk any impact on release builds, warming up now only happens when strict mode is enabled, i.e. on bugfood builds.
Test: none
PiperOrigin-RevId: 165046087
Change-Id: I2bd5337a59fa5a430480e77986015c61798185e8
|
|
This is a partial rollback of previous attempts to fix preview scaling in cl/161444534 and cl/157891853.
The scaling issue was partially due to issues beneath the application, see b/63518188.
By rolling back the previous attempts, this CL improves preview scaling across all devices and OS's (assuming O builds after Aug 3).
There are still some very slight and intermittent scaling issues which we believe to be caused by the system but this CL is strictly a huge improvement. See b/63518188 for details.
Bug: 63518188
Test: manual
PiperOrigin-RevId: 165045984
Change-Id: I8e53870077e2ae86b10cd934f9f3b4508eb60ac3
|
|
Many strict mode violations are due to use of shared preferences on main thread, so we now warm up shared preferences in bypass mode in DialtactsActivity.onCreate. (Note that this shouldn't slow it down because we were already accessing them but without bypassing strict mode.)
I also added a new "storage" module which caches device protected shared prefs. Before we were not caching them and every access was resulting in a disk access, because #createDeviceProtectedStorageContext returns a new context for each call. (Note that this change is required for warming those prefs to work.)
Note that warming up prefs doesn't fix cases where prefs are read from jobs, services, or Application#onCreate (because those things can happen before DialtactsActivity#onCreate) so there is still a need to bypass in those specific places.
Finally, there were various other violations which we now bypass though we probably shouldn't; I'm considering these as being grandfathered in and it would be nice to fix them at some point but today I'd like to just get the app into a usable state so devs can keep strict mode enabled.
Bug: 64118795
Test: manually navigated bugfood build and observed no/fewer crashes
PiperOrigin-RevId: 165031607
Change-Id: I336212a650a7bd93915ebe56a08e976d37818d68
|
|
Including:
- Upgrade to video call button shown for Lightbringer, IMS, RCS
- Lightbringer upgrade requested
- Has Lightbringer reachable contact when launching Dialer
Test: RcsVideoShareTest, ImsVideoTechTest, LightbringerTechTest
PiperOrigin-RevId: 164899006
Change-Id: I1e5d4aacfb558d4b610842795771cb97c53d2f40
|
|
|
|
Test: TreeHugger
Change-Id: Ia3d122b40ae0ff73f489ee2bcf10ab5d703f2805
|
|
|
|
This reverts commit c427ab1517b3323a9290b3d5d06de1033fdb2377.
Change-Id: I745dacae4b3f4e6f5f4cdb70687e5e86d8402ad1
|
|
|
|
Test: TreeHugger
Change-Id: I11d08148a3f1605c74af2c1dbde7aa7dd7e9d236
|
|
Contacts Tab, Call Log Tab, Call History UI.
Some code refactoring works for using database populating methods outside third party library and add new methods to clean contacts database and call log database.
Some golden images get uploaded.
Bug: 64022871
Test: Ran test cases on emulator and they got passed.
PiperOrigin-RevId: 164804270
Change-Id: I5ad86dda98fde9d9203414a0f14fe94b777afd8f
|
|
Only mutate the thread policy when on the main thread to prevent accidentally changing the policy for a non-main thread. The alternative here is Assert.isMainThread(), but that would make DialerStrictMode more difficult to use.
Also switched one use of #disableDeathPenalty to the more concise #bypass.
Bug: 64118795
Test: verified bugfood build does not crash on launch
PiperOrigin-RevId: 164794473
Change-Id: I58db414cbb003241a1afcddabfd6557612351598
|
|
* Abstracts reference to telecom constant until available in the platform.
* Implements a new "Assisted Dialing" token/icon until final UX mocks are available.
* Adds unit test for outgoing call.
In a subsequent, related change:
* Modifications to fragments that contain contacts, the extra key will be inserted via call details to indicate the outgoing intent should use assisted dialing.
Bug: 64205446
Test: New Unit Test
PiperOrigin-RevId: 164788082
Change-Id: I5d388f7b6c4e55c42773d314d2417b6dbc38b972
|
|
Vodafone specifically wants the ongoing notification to display as "WiFi
call", rather than "WLAN...". It appears that our specific settings for
mcc262-mnc01 are used for mcc2620-mnc02, which is why the string doesn't
show properly.
This CL adds a specific strings.xml file for mcc2620-mnc02 to fix the
issue. Additionally, VF does not want these strings to be translated,
hence the 'translatable="false"'. I confirmed that this string will have
a separare message id from the strings in values/strings.xml and so
won't interfere with the translations.
Since it's just the "WiFi call" which must not be translated, this CL
refactors how we choose the content string for Wifi call notifications.
This change could have applied to the rest of the logic, but was not to
keep the change minimal for OC DR. I filed http://b/64525903 to track
work to fix up the logic.
See the related framework changes:
http://ag/q/topic:wificall_no_tr+(status:open+OR+status:merged)
Screenshot:
https://screenshot.googleplex.com/3DS74zm9bBM
Bug: 64487733
Test: StatusBarNotifierTest
PiperOrigin-RevId: 164765234
Change-Id: Ic3e7a60316cf1748259f61d5c5abd95b0303e69d
|
|
In addition, this also fixes an issue where if a user upgrade their calls
to duo video calls quickly, they would see the post call prompt.
Bug: 62689536,64113693
Test: PostCallIntegrationTest
PiperOrigin-RevId: 164758520
Change-Id: I5f91c40e78ce1ff82521a38b0ce5898095849134
|
|
For Dolly our logging proved to be immensely valuable tool to identify the the framework bug. We were able to co-relate the issue with the backup and restore logging. We are adding this again for Key Value backup and restore.
Bug: 64363054
Test: DialerPersistentBackupAgentTest
PiperOrigin-RevId: 164754911
Change-Id: I15f97e1a2301703ced85df8f808cf20aae59c25e
|
|
This change will centralize getting geo location data for a phone number thus
enable us to disable it completely by compiling it out.
Bug: 64394643
Test: none
PiperOrigin-RevId: 164754103
Change-Id: Ie4b526a05f8b4445ee0507683cd238659273c953
|
|
When Dialer users search for contacts, if they have an enterprise account on
their device, they can also search for enterprise/remote contacts. This change
adds the directory queries/results to the new search fragment.
screenshot: http://screen/S9mpsvnwtCv
Bug: 37209462
Test: javatests/.../searchfragment/remote
PiperOrigin-RevId: 164681686
Change-Id: I88bc5bceb4c745d8f6f7d9651929d49100283756
|
|
This change should help with separating concerns between each module
in searchfragment/. Now cursors returned from each CursorLoader are
expected to insert their own headers if they want to. This also simplifies
the logic in SearchCursorManager and allows for easier implementation of
new cursors.
Future CLs will include abstracting ViewHolders and CursorLoaders.
Bug: 37209462
Test: existing
PiperOrigin-RevId: 164676135
Change-Id: Ib50090c3990c903cfd78f3a168032edd88f0fe56
|
|
Add content description for select all button.
Screenshot: http://screen/kmYYExHOuTp
Bug: 63917180
Test: Manual, refer to screenshot
PiperOrigin-RevId: 164672361
Change-Id: If34f754f68824664270d7a76b1cb17da2f8ef01c
|
|
If a user declined a call with SMS while the answer fragment wasn't attached,
they would get a crash. This change checks to see if the fragment has been
attached or detached before attempting to show the menu. This crash was added
by cl/154094855 which fixed another issue that had been around since v6.
Bug: 64380468
Test: none
PiperOrigin-RevId: 164670788
Change-Id: I37f9c28ab0bb24da630f7f7897ecff55ae859837
|
|
Selection can be used to make complex SQL queries more readable, and pass around incomplete selections for appending.
See cl/162013087 for usage
Test: SelectionTest
PiperOrigin-RevId: 164618236
Change-Id: Ice035211f6b02858255a9e7d18215c9282bf28e9
|
|
In the new search fragment, if you rotated the device, a crash would occur
because we were prematurly closing the cursors on our own. Since the cursors
are managed by CursorLoaders, we don't actually need to close the cursors
ourselves and can leave that to the framework.
Bug: 37209462
Test: SearchFragmentIntegrationTest
PiperOrigin-RevId: 164562508
Change-Id: Id33274ccb23d026dab352e754a5f03ab834d9d14
|
|
This CL ensures that Restore works correctly (to unblock us for ODR system image). As restore happens on the system image and the logic cannot be updated via PlayStore, this CL is time sensitive, to ensure we can get it into the ODR system drop. This CL only backups com.android.dialer.app_preferences.xml for now, but can always be changed to update more shared preference files when needed via an playstore update. Since we are using PersistentBackupAgentHelper, we don't have to worry about not being able to restore additional backed up shared preference files from the future, as PersistentBackupAgentHelper will allow us to restore all the shared preferences that were ever backed up via Key/Value.
Currently I added an end to end unit test, and tested restore via "adb shell bmgr restore com.google.android.dialer", which restored the stored data sets. A follow up CL will include additional files to backup and impression logging.
Bug: 64363054
Test: DialerPersistentBackupAgentTest
PiperOrigin-RevId: 164524465
Change-Id: I5bd65215a42744ba4149a9359e443679306b6cc0
|
|
Test: NONE
PiperOrigin-RevId: 164524149
Change-Id: I7ab941d2d96093647dda3e5321776f43da59ab2b
|
|
This class will be used for Assisted Dialing.
#turndowncontactscommon
Bug: 64205446,37208802
Test: TAP
PiperOrigin-RevId: 164510740
Change-Id: I5dec67d2182b33bf2057953aab69e3b561af5708
|
|
screenshot: http://screen/WpQJZ0Xy1gi
Bug: 37209462
Test: NewSearchFragmentTest
PiperOrigin-RevId: 164407405
Change-Id: I3c66dc289524573e687266217b57b19a8ded8c9c
|
|
video: https://drive.google.com/open?id=0B2Hce9qilHmvYTlqVGU0OTNxNjQ
Bug: 37209462
Test: SearchFragmentIntegrationTest
PiperOrigin-RevId: 164319452
Change-Id: Icc5669be87e97ba5d0e23fc99bada28ca7d2335a
|
|
Bug: 37209462
Test: RemoteDirectoriesCursorLoaderTest
PiperOrigin-RevId: 164295668
Change-Id: I5d9c54fa748d19f09b62a33ff12a7de8a71d64d3
|
|
Bug: 64314754
Test: manual
PiperOrigin-RevId: 164294241
Change-Id: Ic5d56fc0c1e52eb70ab8b8a22a3ad2cefe03cabf
|
|
We want to clean up all the Dialer Backup and Restore. This includes the existing Dolly backup code for settings/preferences (causes a crash) and the Hangouts K/V Backup (does not work).
The idea is to just have a clean simple K/V backup and restore for dialer, which will be in a follow up CL.
Bug: 64363054
Test: Manual. Builds successfully.
PiperOrigin-RevId: 164225991
Change-Id: Ic71cfaeed37a5c9f0002d8d12db757f19c0ddf1e
|
|
There were two outstanding issues in the new search criteria:
- Contacts named "Brandon" would be filtered out by query "b"
- Contacts named "Bob" would NOT be filtered out by query "o"
This isn't how our current implementation of search worked and these issues are
resolved by this change by ignoring case sensitivity and doing suffix checks on
names instead of #contains checks.
Bug: 37209462
Test: QueryFilterUtilTest, SearchContactCursorTest
PiperOrigin-RevId: 164214145
Change-Id: I367ed0d862809d28491ae53e7dd8e1a24c824ec9
|
|
Introduce the concept of a "mutually exclusive button".
Buttons that conflict with a "mutually exclusive button" that
is eligible to be placed, will never be placed.
Bug: 37275934
Test: unit tests.
PiperOrigin-RevId: 164210228
Change-Id: I64af6065c89d143a331ea226f9a6cb1004b5a155
|
|
We have much longer duration than expected especially on NE1 devices. Although we can't reproduce it, we should not reset duration if a call is already disconnected.
Bug: 63930386
Test: none
PiperOrigin-RevId: 164191850
Change-Id: I851d9cc9ce64a7df32bd388e45f6613372670d81
|
|
Updated android enterprise briefcase asset for:
Dialer, Contacts, OTAConfig, Messgenger
screenshots:
contacts search https://screenshot.googleplex.com/zwHRua8Erob
dialer calllog https://screenshot.googleplex.com/qmPUzSHXbvC
messenger screenshot https://screenshot.googleplex.com/HTK8btSQvJB
otaconfig notification https://screenshot.googleplex.com/OY8qUzns6N5
otaconfig statusbar https://screenshot.googleplex.com/GJP7dCjTMiG
Bug: 36497538
Test: Manual
PiperOrigin-RevId: 164121167
Change-Id: I095241c01c121a5a59ae932a012878047c143ebf
|
|
When the share and call button was visible, users using talkback could reach
the media icons hidden underneath.
Bug: 62649310
Test: manual
PiperOrigin-RevId: 164088069
Change-Id: Ic9cd23a78790c119d6d4d2f6e9d6e62c24e20120
|
|
If a user has IMS video calling and Lightbringer video calling enabled, when
they searched for a contact through dialer search, they would perform a
lightbring video call. This was unintended as IMS should have priority.
Bug: 64125770
Test: ContactListItemViewTest
PiperOrigin-RevId: 164058129
Change-Id: Ib2919857ffebd71d7911011274df0a6d07960d5f
|
|
Devices with other default locales would translate '1' and this would cause an
no such column exception in SQLite.
Bug: 64137857
Test: manual
PiperOrigin-RevId: 164048836
Change-Id: I4ecd070f8d38a82ca6567fb23b660d5ebe1f1f18
|
|
If a new call is placed before hiding the current bubble, bubble text will not be reset and the new bubble shows with the text. Fixing it by using different hide method for onUiShowing() and onDisconnect() (reset after disconnecting).
Test: ReturnToCallControllerTest, BubbleTest
PiperOrigin-RevId: 164048596
Change-Id: I7259df57da3aba51960bfb7bb1ea5f840c9501e0
|
|
Previously when setting the color of a network in call details, we assumed the
values were stored as String resource values when in fact they were hexidecimal
integer values. Now we directly set the color instead of doing a resource
lookup.
screenshot: http://screen/d3tQNGBkKNX
Bug: 64300111
Test: CallDetailsActivityTest
PiperOrigin-RevId: 164042030
Change-Id: I858e3665253139b8aab4e4c063bfc4c419f33cc9
|
|
Previously the keep screen on flag is only applied the the activity once when the video call is created. The flag will be lost when the activity is recreated, such as rotating the screen.
In this CL, the keep screen on state is persisted in the InCallPresenter, and will be reapplied every time the activity is created. The flag will be cleared when the call is finished or when the video call has ened
Bug: 64101648,63917358
Test: InCallPresenterTest
PiperOrigin-RevId: 164030247
Change-Id: Ie90f8dd0dfc9b542d691296c729dc3342a8bc2ad
|
|
expanded
Binding a view holder to an expanded voicemail will attempt to mark the voicemail as read and all voicemails as old. If a new voicemail is received when a voicemail is expanded, the new voicemail will cause a rebind and the notification will be canceled right away.
In this CL, voicemails will only be marked as old if the expanded voicemail was not already read.
Bug: 64211487
Test: CallLogAsyncTaskUtilTest
PiperOrigin-RevId: 163912108
Change-Id: Ibe82fe85984d84aad1a674219ca984fdd10c6d89
|
|
Test: TAP
PiperOrigin-RevId: 163911841
Change-Id: I454a649e8e31e744de99c2d9599f5bf291c729f1
|
|
A high res sync update request should be sent to trigger the photo sync.
Without this request, the contact photo will stay in low res until user action
to trigger it in other ways such as click on quick contacts or open it in
contacts app.
Bug: 62390496
Test: manual
PiperOrigin-RevId: 163905019
Change-Id: Iaf47934df02dc15f75e806505dfd425402fde07c
|
|
Visual voicemail playback uses the phone stream, which will cause all sort of audio conflict in a call. This CL forces voicemail playback to fail if a call is in progress.
Bug: 63584851
Test: manual - play voicemail while in call, "Cannot play voicemail" shown.
PiperOrigin-RevId: 163899919
Change-Id: I7350f6904b5a76f9c21a1d541f3c1f39271a5608
|
|
The VVM tab is shown when there are more then one "active" voicemail sources in the voicemail status table. A configuration status of 0 is active, and 1 is inactive. If the configuration state is null, getInt() will return 0 which maps to active, and incorrectly showing the VVM tab.
In this CL, null is checked first. The helper class is also made static.
Bug: 64122858
Test: VoicemailStatusHelperTest
PiperOrigin-RevId: 163858350
Change-Id: I3fca52aaca92492f1969092e2d9f443677cb3b8d
|
|
Failing to set the tag before invoking getContent() causes a strict mode violation.
Bug: 64080588
Test: none
PiperOrigin-RevId: 163785889
Change-Id: Id08886616f353b93df47d090abc9c0b68a09954e
|
|
Bug: 64172993
Test: manual
PiperOrigin-RevId: 163764485
Change-Id: Id66bc075e98cae0bcdb42e1ad82b403e7e0ae0d1
|
|
These numbers cannot be called back so don't show the button.
Bug: 64103891
Test: GoogleCallLogAdapter
PiperOrigin-RevId: 163758778
Change-Id: Ic5d9bd3abe38ff8a9ac84da6c453c924cb1dd6ca
|
|
Test: BubbleTest
PiperOrigin-RevId: 163758306
Change-Id: I391fe411822f01cf29075eab7cf42aeb676fd424
|
|
Move to the new ExecutorFactory classes.
Bug: 63711921
Test: unit test
PiperOrigin-RevId: 163752136
Change-Id: I33bc1e415bd3c48d593be753939d9ba42d8ba156
|
|
We added a new proguard flag recently and for some reason it is causing issues
with Fi calling on dogfood builds. I'm fixing the crash here and will work with
Zach to determine why this is causing issues.
The new flag that is causing trouble was added in http://cl/163521622
Bug: 64206675
Test: manual (mulitple builds confirming no longer crashes)
PiperOrigin-RevId: 163736443
Change-Id: Id30188699f7e9a40fbe23df18700b7104e1b551a
|
|
There was an issue with the duration shown in the InCallUI when a CMDA
generic conference was ended early. This resulted in the duration
showing as a huge number, rather than the proper value. This issue is a
regression caused by cl/157138159, which attempts to only start the
timer once.
This CL fixes the issue by ensuring that the Chronometer's base is reset
every time the timer row updates, instead of just once when start is
called. This matches the logic from prior to cl/157138159.
Repro steps:
1) Disable advanced calling on device with Verizon SIM
2) Place call from DUT to device A
3) Accept call on device A
4) Place call from DUT to device B
5) Before answering the call on device B, hang up the added call on DUT.
Results (without fix):
InCallUI switches to generic conference view (Phone number/name changes
to "Incall"). Duration becomes a huge number. See
https://drive.google.com/open?id=0B5N2YRME1XrUeDJWYnRBWGRQM00
Results (with fix):
InCallUI switches to generic conference with proper duration. See
https://drive.google.com/open?id=0B5N2YRME1XrUaDRtcjRWX3BxMTA
Bug: 64099380
Test: Manual, see steps
PiperOrigin-RevId: 163735661
Change-Id: I98bcd6517b55a21b58e4b32b00d66fdba4c45143
|
|
TelephonyManager will resend legacy voicemail notifications during connectivity changes with a "is_refresh" flag. Such notifications has already been shown before and should not alert the user. Previously the notification will be set to onlyAlertOnce, but if the user dismissed it it will be shown again.
In this CL, if the notification is dismissed, the state will be persisted and the notification will not be shown again. The state will be cleared when a new voicemail arrived and the user will be notified again. Since telephony sends is_refresh=false during boot up, the state will also be cleared with a reboot.
Bug: 62229933
Test: LegacyVoicemailNotificationReceieverTest
PiperOrigin-RevId: 163728161
Change-Id: I7ec6b5a88fed26e0a4459b8803eeba9a37b7b32b
|
|
The duo disclosure takes priority over the nearby places, and will be shown if all the conditions are met:
Disclosure enabled by flag show_duo_disclosure (default:false)
Duo module is enabled
Is in the call log tab
Disclosure is not dismissed.
The auto dismiss after 24 hours is not implemented. The help center article points to dialer_duo_disclosure which is not created yet.
Test: GoogleCallLogAdapterTest
PiperOrigin-RevId: 163714903
Change-Id: I724c6961af2912108c81d69a23d84682b721a58c
|
|
This will help us better understanding where it spends time for bringing up an incoming call ui.
The overhead is very light that could be ignored.
Bug: 62426694
Test: none
PiperOrigin-RevId: 163544107
Change-Id: I5520ed2b4b8085b8611af15e2c15c4c774446bec
|
|
There were some calls to StrictMode#enableDefaults in our codebase that were not guarded by bugfood checks. In testing, #enableDefaults causes warnings to be printed that otherwise would not.
This CL makes it so that we never call enableDefaults on non-bugfood builds, and cleans up and consolidates our usage of strict mode logic by introducing a new class called DialerStrictMode.
Test: none
PiperOrigin-RevId: 163521622
Change-Id: I841b4198a5dd6084ee104dc6907165e3379d0451
|
|
Logger.get() returns a LoggingBindingsStub object instead of a
LoggingBindingsImpl object under strict mode, and we should not log when it
happens.
WANT_LGTM=kedars
LOG_STORAGE_INCREASE(GB/week): 0
Test: manual
PiperOrigin-RevId: 163404058
Change-Id: Ibd466a811126c45eb26bc033367cc86a77066b3f
|
|
Use the drawable dimensions to control clipping.
Before:
Adjusting the screen size from default to largest
would trigger a view reflow. However, because
the bitmap asset was already cached, and the rounding
of the tile was based on the bitmap size, the new, larger
drawable would only undergo a partial circular crop.
Now:
We scale the image uniformly and center it. Also,
use the drawable dimensions to control clipping dimensions.
Bug: 63864703
Test: manual
PiperOrigin-RevId: 163376680
Change-Id: Ic678dff2b18d3308c859818f187a42afd6563e10
|
|
When we calculate transition end values, primaryText might be invisible and
causing primaryButton size smaller than expected. Fix it by always using larger
size (primaryText size).
Conference call ended twice, before:
https://drive.google.com/a/google.com/file/d/0Bz1rQbdSCWSKamYzVTVrbVpBWWM
After:
https://drive.google.com/a/google.com/file/d/0Bz1rQbdSCWSKck9WUm5IUlI2QVU
Test: ChangeOnScreenBoundsTest, BubbleIntegrationTest
PiperOrigin-RevId: 163375425
Change-Id: I251d0e96546742247ee3ce463f0aade65fe302bb
|
|
cl/163140580 filters out audio call from Duo, but will also remove fi voicemails because fi writes null phone account handle.
null NOT LIKE x returns null.
null OR x returns x.
This CL limits the filter only to the call log, and handles the null phone account handle.
Bug: 64060628
Test: manual, leave voicemails in fi. Automated tests in a future CL. Test call log database in progress(see cl162013087)
PiperOrigin-RevId: 163284363
Change-Id: I69ba6cbadbd1a02f05405ca0f5273b0a5ea0e5e9
|
|
We'll want to cherry-pick this onto v11.
Bug: 64073371
Test: manual, verified with QA across multiple scenarios (Fi, Verizon, forced flag enabled)
PiperOrigin-RevId: 163282286
Change-Id: I4b9456ec9a8ed978e93866a5c9dcab46848fee58
|
|
This is caused by handling phone number change during a call.
This change will remember if it's a voicemail/emergency number after phone
number changes and continue to show it as voicemail/emergency number.
Bug: 64009408,63716219
Test: SimulatorConnectionService and real device.
PiperOrigin-RevId: 163276696
Change-Id: Ibcde9ab9b61dc683de3d77dddca789ade3e895ba
|
|
As discovered in b/63711486 it's possible for the number to null when we
expand a call log row. Since the EnrichedCallManagerImpl checks that the
number isn't null when we check capabilities, this crashes when EC is
enabled.
This CL fixes the issue by checking for the null value and working
around it as needed. Since the DialerContact proto requires non-null
numbers, I had to protect it's call as well. There's no affect on
CallDetailsActivity and CallComposerActivity since the proto will return
the empty string if number is unset.
Bug: 63711486
Test: GoogleCallLogAdapterTest
PiperOrigin-RevId: 163225329
Change-Id: Id30ad5076523987f1cc93b803d52e85daa6c0e20
|
|
When Dialer users search for contacts, if they have an enterprise account on
their device, they can also search for enterprise/remote contacts. This change
adds the cursor loader needed to get a list of contacts from a specific remote
directory.
Bug: 37209462
Test: RemoteContactsCursorLoaderTest
PiperOrigin-RevId: 163154108
Change-Id: Ieae2cb2c03e759d7ed6cfdfa2f72a4190d8b844d
|
|
dialpad choose.
This is caused by saved instance state overriding values of showing dialpad
from intent extra when incall activity is being recreated.
Bug: 62046691
Test: manual
PiperOrigin-RevId: 163148086
Change-Id: Ice8974d7ee90ca3adcefca5946ec7489837d0bf6
|
|
Without this CL, Duo audio calls show in the Dialer call log and will either
start phone calls or Duo video calls based on Duo integration being available
or not. Carriers do not want OTT audio calling in the Dialer call log so we
should filter the audio calls out.
Bug: 63089358
Test: Manual: Placed duo audio and video calls, verified they showed without the patch, verified correct calls were filtered out with it. Will want QA verification over other test scenarios including multi-sim if we were to put this into OC-DR.
PiperOrigin-RevId: 163140580
Change-Id: I83c3659f6c356522b62d9ced2002a808ea958c95
|
|
When Dialer users search for contacts, if they have an enterprise account on
their device, they can also search for enterprise/remote contacts. This change
adds the cursor loader needed to get the list of all remote directories
associated with the accounts on the device.
Bug: 37209462
Test: DirectoryCursorLoaderTest
PiperOrigin-RevId: 163139517
Change-Id: If5e626507d5c337633a678fff5e8dac59f85658e
|
|
Repro steps:
1. setup multiple calling account (multi-sim or sip etc.)
2. make a ongoing call
3. click "Add call"
4. make another call in dialer
This is caused by recreating incall activity when adding new call that
will go through its lifecycle thus disconnecting the call with account
selection states automatically.
It's a regression caused by cl/162562378.
Bug: 64014929
Test: manual
PiperOrigin-RevId: 163138094
Change-Id: Ia979f7d63bd85cfaa6550c58e552759d66ec937c
|
|
See go/ec-temp-unavailable. This CL fixes the issues when we get
enriched call capabilities for users who are temporarily unavailable.
Bugle sends an indication that this is the case through the
ACTION_CALL_CAPABILITIES_UPDATE intent, which is saved as part of the
capabilities. When users click on a call log row, we check if the
capabilities were temporarily unavailable and if that's the case, we
request the capabilities again. This ensures that we don't cache the
temporarily unavailable capabilities forever.
manual
Bug: 62609419,37726219
Test: EnrichedCallManagerImplTest, EnrichedCallBroadcastReceiverTest,
PiperOrigin-RevId: 163126355
Change-Id: I45be6f883d9c6596d20382250c220a90fbf5e996
|
|
*** Reason for rollback ***
Checking if this broke the uses-library value for pixel devices
*** Original change description ***
Update merge strategy. The legacy strategy is deprecated.
* Don't allow cleartext traffic in the voicemail module. This was being overridden, anyway.
Bug: 62339559
Test: See below.
PiperOrigin-RevId: 163109133
Change-Id: Id04c51bf3fcb66314c7b27ad96d38b3cae0df230
|
|
Bug: 63686780
Test: ClearCallLogDialogTest
PiperOrigin-RevId: 163096437
Change-Id: Ifc416b8c0ff1baa6ddbef11c26b548af2eb3fc64
|
|
Previously the DIRTY flag is used to track which voicemails has local changes that need to be uploaded to the server. The DIRTY flag is updated by the content provider and is super janky. Whenever dialer writes to the calllog or the voicemail provider the dirty flag is cleared.
When the user modified a voicemail entry, an upload is issued and blindly marking all locally read or deleted items on the server. The content on the server was never check during an upload.
After this CL, the DIRTY flag is ignored. Upload and download is now always done together. The list of voicemails on hte sever will be downloaded first, and if any voicemail is read locally but not on the server then it will be uploaded.
As the full sync when the user opens the voicemail tab was implemented, this additional transaction cost should be neglectable.
Bug: 62867500
Test: Auto test ETA Christmas, 2030. Manual: mark voicemail as read/delete voicemail.
PiperOrigin-RevId: 163093305
Change-Id: I09e918f32b9b1ffdad80731f7c25f894be2826f3
|
|
Pause is not supported on TMO for IMS video calls so we need to disable and
re-enable the camera instead.
Bug: 62962221
Test: ImsVideoTechTest
PiperOrigin-RevId: 163088983
Change-Id: I9b8ba0db877f972f27396969d9e06d54c466d1d1
|
|
When Dialer users search for contacts, if they have an enterprise account on
their device, they can also search for enterprise/remote contacts. This change
adds the viewholder that shows these contacts to the user.
Bug: 37209462
Test: RemoteContactViewHolderTest
PiperOrigin-RevId: 162793301
Change-Id: Ifa409f49c8a0069b0753a138f4762830921cb3f7
|
|
Before:
PhoneNumberInteraction only checked if it could Read CONTACT.
This resulted in a crash when setting super primary number preferences.
After:
PhoneNumberInteration checks for R/W.
Any missing, required permissions are now granted.
Steps to reproduce:
1) Add a contact with two different numbers.
2) Mark that contact as a favorite.
3) Long press on the dialer icon, long press on the contact, and add them as an icon to your screen.
4) Tap on the icon
5) Grant contact permissions.
6) App crashes.
Bug: 63668172
Test: on device, unit tests
PiperOrigin-RevId: 162761620
Change-Id: Ic9aefbb8101bc73294eb871cc9684b0464d4bdcd
|
|
This is caused by no background color is set for the call log activity.
This is regression caused by cl/162392495.
Bug: 63899078
Test: manual
PiperOrigin-RevId: 162758117
Change-Id: I3fbeffa7e5ba2a1149c425c00384ed9dbb330549
|
|
Before the other party answers the call, the swap button won't work for second
call.
Screenshots:
https://screenshot.googleplex.com/MTjD6VHEdxd
https://screenshot.googleplex.com/cVEuoTnRAZ8
Bug: 63083257
Test: manual
PiperOrigin-RevId: 162633661
Change-Id: I79ebcece059fd256e50edb7509ac1703c3145dac
|
|
This is an effort to eventually delete FallibleAsyncTask, since people still occasionally use it by accident.
There are still some instances of FallibleAsyncTask in p13n code which will be cleaned up in a later CL.
Test: existing
PiperOrigin-RevId: 162633637
Change-Id: I79b57dc6284952145f62f556799d15a31888bdea
|