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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Bug: 63686780
Test: ClearCallLogDialogTest
PiperOrigin-RevId: 163096437
Change-Id: Ifc416b8c0ff1baa6ddbef11c26b548af2eb3fc64
|
|
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
|
|
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
|
|
This CL fixes a bug with the FuzzyPhoneNumberMatcher implementation. The
logic should be that if the last 7 digits of two numbers match, we treat
them as the same. The issue was that if we found digits that didn't
match between the number, we reported them as not matching, even if they
had 7 digits in common.
This CL also makes some quality of life changes:
- Renames FuzzyNumberMatcher to FuzzyPhoneNumberMatcher to match the
class name.
- Abstracts the logic of the FuzzyPhoneNumberMatcher into another well
named method, so it's more clear how the code works.
While I didn't check too carefully, I believe this will also help out
issues with capability flakiness in:
- b/62609419 | maxwelb | RCS very unstable when on cellular.
Bug: 63564400,62609419
Test: FuzzyPhoneNumberMatcherTest
PiperOrigin-RevId: 162552340
Change-Id: Ie091d985a34a16000750f6050bde6bb0ea7da4e5
|
|
Quick contact descriptions are added in the ContactPhotoManager, so we can
remove this string duplicate and its only use.
Test: manual talkback testing
PiperOrigin-RevId: 162514532
Change-Id: Ic8345a30b6d69017e72fffa1469b96b10e69cdf8
|
|
Bug: 34512128
Test: VoicemailAudioManagerTest
PiperOrigin-RevId: 162505938
Change-Id: Ie097c0e04562ea5bf915ec61cd686b5ae5e1791c
|
|
Previously if the log is corrupted for any reason(interrupted writes, cosmic rays, bad programming skills), the log reader will get an incorrect entry length and try to read a few GB of data.
In this CL a prefix and postfix is added to each log entry. If it doesn't match or if the entry length is dubious, the logs will be purged.
All existing logs will be purged upon sending feedback as a result of the new format.
Bug: 63678731
Test: PersistentLoggerTest
PiperOrigin-RevId: 162504759
Change-Id: I85f39fbc6e9738b9fb0a251131b77d8a15fe44f6
|
|
As per the documentation, DialerExecutors.createUiTaskBuilder is meant
to be called in onCreate.
As a side effect of this change, if at some point we support sending
both an image and text at the same time, the code will not work. This is
not currently planned, so this CL stays simple, rather than adding the
complexity of plumbing the old MultimediaData through
CopyAndResizeImageWorker.
Bug: 63714992
Test: CallComposerActivityIntegrationTest, manually placed EC call
PiperOrigin-RevId: 162498272
Change-Id: I710e94284b2235684a27afbfa12ea8ddef0690de
|
|
Bug: 63696987
Test: ContactsAdapterTest
PiperOrigin-RevId: 162423318
Change-Id: Ia43bda7857576b4e838372eef79edb1fa233571f
|
|
Background in call log fragment is same as the activity. It's unnecessary and only reduces rending performances.
Verified by hand that it looks same as before.
GPU Overdraw:
Before: https://screenshot.googleplex.com/y1HNFiae1j7
After: https://screenshot.googleplex.com/mQFxyWEhkFm
Performance test:
Before:
Total frames rendered: 668
Janky frames: 35 (5.24%)
50th percentile: 7ms
90th percentile: 11ms
95th percentile: 16ms
99th percentile: 73ms
Number Missed Vsync: 18
Number High input latency: 1
Number Slow UI thread: 35
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 2
After:
Total frames rendered: 736
Janky frames: 32 (4.35%)
50th percentile: 6ms
90th percentile: 11ms
95th percentile: 13ms
99th percentile: 61ms
Number Missed Vsync: 15
Number High input latency: 0
Number Slow UI thread: 31
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 3
Test: manual
PiperOrigin-RevId: 162392495
Change-Id: I726cd06518d282abe68eb1ff16db82c9a3e6d291
|
|
SimpleDateFormatter cannot display times longer than 60 minutes. If
a time is longer than 60 minutes, it will display the time % 60. This
change accounts for that and replaces the truncated time with the correct
time.
Bug: 63709810
Test: CallEntryFormatterTest
PiperOrigin-RevId: 162284780
Change-Id: Ib01b135c028b5d59637850e873e5a218f9c39ae8
|
|
The voicemail icon was rendering at 24 dp with 2dp of padding above it. Removed
the padding and reduced the icon to 16dp.
screenshots:
before: http://screen/Dx2zcVsX10y
after (portrait): http://screen/RUnQP8CR65t
after (land): http://screen/aKCdMTLkOnU
Bug: 62517731
Test: screenshots
PiperOrigin-RevId: 162278290
Change-Id: Iaaf65d9bac3920ff1755da85b6f85752654d86b8
|
|
Bug: 37208805
Test: compiler, on device
PiperOrigin-RevId: 162268272
Change-Id: I98d63d063b9a4dff6a1b1b7462378ef7d0139bd2
|
|
When a user would delete their last contact, the contacts fragment would show
a list with the old contact and the empty contacts background view underneath
it.
Test: ContactsFragmentTest
PiperOrigin-RevId: 162267124
Change-Id: I294f2fe06f08ba6bd31148681647ffe3d536e1bf
|
|
Since we are given the camera permission by default for video calling, we don't
need to request it from the framework. But, for privacy reasons, we still need
to tell the user that we have it.
Since we're changing the preference for call composer, v10.1 users will see this
this toast again if they've never made a video call.
The toast is shown in the following situations:
1. If a user receives a video call
2. If a user makes a video call
3. If the user opens call composer
The toast doesn't show:
1. If the user has already seen the toast anywhere before
2. If the user has revoked the system permission and grants it
with a system dialog
Bug: 36608790,63405063
Test: manual
PiperOrigin-RevId: 162258610
Change-Id: Ie93413c9c2e1f083919e7183eb920100b06fd4a4
|
|
* changes:
Fix Lightbringer call upgrading when Dialer was not in memory before the call
Handle null host for secret code
Dont start a service to cancel missed call notifications, use DialerExecutor instead
Fix NPE when user click on call log.
|
|
instead
We cannot start services while in the background on O. Currently, we start a
service to cancel missed call notifications in the onStop of our Activity. This
is when we are going into the background so it is not safe (as we have seen
from the crashes).
Bug: 63633461
Test: CallLogNotificationsServiceTest
PiperOrigin-RevId: 162029424
Change-Id: Ib0f46aed848ba0898af8cbee1c114b1e41f3ae32
|
|
This is caused by null tag of videoCallButtonView when expanding action view.
Bug: 63710739
Test: none
PiperOrigin-RevId: 162011496
Change-Id: If592be8cd9b05c369e2ff8b51610d93af48834f1
|
|
This CL makes a number of changes to include temporarily unavailable
statuses (go/ec-temp-unavailable) as part ECCapabilities.
- Adds isTemporarilyUnavailable methods, which will be set by
ECBroadcastReceiver upon getting a capabilities update.
- Adds a builder to ECCapabilities as there are now 4 booleans that are
set upon construction.
- Changes the names of getters on ECCapabilities, which was required to
get autovalue to correctly generate the builder.
- Adds an ALL_CAPABILITIES constant to match the NO_CAPABILITIES
constant.
Bug: 62609419
Test: Existing tests, ECCapabilitiesTest
PiperOrigin-RevId: 161890511
Change-Id: I967a9a14793ac12101ecfed59e5f7af1217faf3b
|
|
Before, we were creating a custom thread pool for spam transport, which isn't necessary. Instead, we can just use an application wide thread pool.
Also fixed some instances where we were not clearing the thread stats tag after opening the socket.
Test: manually launched app with data cleared and observed no crash
PiperOrigin-RevId: 161882076
Change-Id: I39bdd31cf5fa8a974d7535e861ec0716c85986f3
|
|
We now have googledialer, aosp dialer, and voip registries for traffic tags which should always be used to avoid reusing tags.
There are comments in each file about the reserved tag ranges.
Note that this moves some traffic tags from one value to another. Traffic data is cleared across device restarts so that shouldn't be a problem.
Test: unit tests verify no conflicts
PiperOrigin-RevId: 161848949
Change-Id: I5b51e6242494a0bc211748f793a415a5fead5097
|
|
The Hebrew translation had an extra single quotation causing an
UnboundQuotationException. This change fixes that temporarily by looking for
that specific translation and adjusting it. This change should be reverted once
the translation is corrected.
Test: release build in hebrew results in no crash, manual test
PiperOrigin-RevId: 161730025
Change-Id: Ifb171e3e795e91a93096493ec770ae339a6ed12f
|
|
A subsequent change will move the ContactPhotoManager related code,
eventually enabling the removal of contacts/common.
Bug: 37208805
Test: TAP
PiperOrigin-RevId: 161724700
Change-Id: Ice0789951ae544f6e27bcdaab0c032b218c83613
|
|
Bug: 37846172
Test: on device
PiperOrigin-RevId: 161720359
Change-Id: I2df2036c6d9941d37511f450f58682cf07e774b0
|
|
video: https://drive.google.com/open?id=0B2Hce9qilHmvdl8xY1hmcDZ0R3M
Test: manual
PiperOrigin-RevId: 161713747
Change-Id: I8185ca897a82479ef7c552a1ce6891e31c4c5aad
|
|
screenshots:
default sizes:
before: http://screen/u29zyepX0OM
after: http://screen/tXGSUbNfWAE
large sizes:
before: http://screen/NH3OmGDRyBp
after: http://screen/W6DVopCxMUp
Bug: 63156716
Test: screenshots
PiperOrigin-RevId: 161693857
Change-Id: I8310336080ae080dc586dcf21d4966260880a627
|
|
Without this change, all video calls are referred to as just "video call". This
CL uses the Lightbringer interface to allow customizing that text.
Before: https://drive.google.com/open?id=0B7uuA4cyYX0xeVZCTGtMUUtoRVU
After: https://drive.google.com/open?id=0B7uuA4cyYX0xMnFhbTBXMDI2VW8
Bug: 63138393
Test: CallTypeHelperTest
PiperOrigin-RevId: 161692812
Change-Id: I36dc1a1fae96dddee91c5efb8892c4a6c7ef67ca
|
|
This issue occurs when users are shown a post call snackbar and their shared
prefs are updated before pressing "send message". This change resolves the
issue by getting the phone number when the prompt is created rather than when
the button is pressed.
Bug: 62294499
Test: PostCallTest#postCall_UpdatedQuickly_PostCallStartedSuccessfully.
PiperOrigin-RevId: 161689241
Change-Id: Ie2c857f6743aa556f993bc3f8e92c8b2b7357c08
|
|
If a user caused their activity to undergo several state changes rapidly, they
could get the contacts fragment into a state where it wouldn't have any
elements but still call onScrollChange. This would result in calls to
getFirstCompletelyVisibleItemPosition returning NO_POSITION (-1) and throw an
AIOOBE when attempting to get a row's header value.
Bug: 63594129
Test: manual.
PiperOrigin-RevId: 161610423
Change-Id: I0c53587a6499c42abe5e51b6ac2b4108c0971545
|
|
before: http://screen/DsVrM1vK89e
after: http://screen/RzGZvPTXRQb
Bug: 63093275
Test: manual
PiperOrigin-RevId: 161609906
Change-Id: If53681b9414dd79dba16371f42be437f1afa2729
|
|
The Call button may have two lines of text. We were not properly setting the
second to GONE in all cases.
Note: We don't need to require Google Dialer being the default Dialer for the Duo integration to work. I added this check so removing it doesn't go against any previous well-considered decision. It also enables the Espresso test work without needing a flag to override.
Before: https://screenshot.googleplex.com/3YXaZdbQk7k
After: https://drive.google.com/open?id=0B7uuA4cyYX0xNThETTJWdTVQQWM
Bug: 63062360
Test: GoogleDialtactsActivityTest
PiperOrigin-RevId: 161606497
Change-Id: I7526a4fc60b84906cc04563b635eaad9f348415e
|
|
If a user took a picture then quickly closed call composer, when the image was
ready we would try to update our view state. Since our fragment is no longer
attached, this cuases a crash when we check that getContext() is not null.
fragment.getContext is never null in robolectric.
Bug: 62687110
Test: manual, cannot test b/c we cannot take photos in Espresso and
PiperOrigin-RevId: 161600278
Change-Id: If9bd98578d221fca4bc99ff17a39f917f3a8bcca
|
|
It was odd that we were casting and was causing some crashes. This CL makes
things work more as is typical in Dialer.
We previously did not do this because there are some parts of the
VideoShareSession which are not open-sourceable. Turns out we can simplify
those parts out of the interface.
Bug: 63523694
Test: existing tests
PiperOrigin-RevId: 161593028
Change-Id: I8f1379fc46f4e9d41413b731787dbf37e0901da9
|
|
The dialer app crashes on launch right now when app data is empty, because we fetch the spam list on app start, and we don't tag the network traffic using TrafficStats, which is a strict mode violation.
This CL tags spam network traffic using TrafficStats, by providing a custom transport executor for the GRPC channel. All activity on the channel is tagged as spam.
This unfortunately required creating a new thread pool. I am not sure if this creates more threads than before, because it is not clear what type of transport executor grpc uses by default. Note that the new thread pool will kill unused threads after 60 seconds so won't consume resources when idle.
Bug: 62388129
Test: manually verified app does not crash on launch with empty data. Can add automated tests upon request.
PiperOrigin-RevId: 161568882
Change-Id: I99da6ebb649fe1a63d634871ab314d8d910658f9
|
|
Add additional null checks during deseriailzation.
Bug: 63575857
Test: unit tests, on device
PiperOrigin-RevId: 161564824
Change-Id: I54f52e12397adb4473b523325f8c006ff534fbd9
|
|
Test: ondevice
PiperOrigin-RevId: 161548092
Change-Id: If4cde06669bc33cca69a9b602f54d873b735c730
|
|
Although we don't know the reason why v.getParent() can be null, we can avoid calling it.
Test: manual
PiperOrigin-RevId: 161442696
Change-Id: I07af0da9b64fb3fa77b01c0b619837a79d593b67
|
|
Methods such as getAccountLabel() is called on different threads which may cause
race condition issue.
This change also delete CallLogCacheLollopopMr1 since it's not necessary that Dialer is targeting M+.
Bug: 63415147,63524435
Test: none
PiperOrigin-RevId: 161440757
Change-Id: Ia609c52e53dabdce78ffb4320f4cd66e38112e47
|
|
OC preview devices are hitting the assert and skewing crash rate numbers.
Bug: 62338925
Test: LegacyVoicemailNotificaitonReceiverTest
PiperOrigin-RevId: 161438516
Change-Id: Ib533947d2cd9e9a87ffd9fb629f09f877f683026
|