Age | Commit message (Collapse) | Author |
|
PhoneLookupInfo.cp2_local_info.
To support remote CP2 contacts, there will be a new PhoneLookup ("Cp2RemotePhoneLookup") and a new field in proto PhoneLookupInfo ("cp2_remote_info").
In proto PhoneLookupInfo, cp2_local_info and cp2_remote_info will be of the same type ("Cp2Info").
Bug: 71763594
Test: Existing tests
PiperOrigin-RevId: 181405798
Change-Id: I6c43b486229d4e9ae7b55c579d9c9997a2884c80
|
|
DialerFutures#firstMatching now fails if one of its provided futures fails before a match is found.
This is to accomodate the case where no source returns true for isDirty, but one or more fail; we want to be notified of the failure in that case and not silently treat that case as not dirty.
Also fixed a bug in NewCallLogFragment where the failed future wasn't causing the application to crash.
Also improved some related logging in RefreshAnnotatedCallLogWorker and Cp2PhoneLookup, and fixed a bug where empty numbers were not being handled correctly.
Bug: 71504246
Test: unit
PiperOrigin-RevId: 181401710
Change-Id: I23e207ac334ff80ac95b08a8f4f775a528a8c511
|
|
This is for performing work inside of the call log's RecyclerView, when the view holder is bound. Most of the time, this should be a no-op but there are possible edge cases where the call log data cannot be updated efficiently through the standard batch mechanism.
One example of this is when there are too many invalid numbers in the call log; the CP2 information for invalid numbers cannot be efficiently batch updated so we fetch this information at display time. (Note that we do handle up to 5 invalid numbers in the batch update mechanism, but if there are more than that we fallback to this realtime processing.)
Test: unit, manual
PiperOrigin-RevId: 181400016
Change-Id: Iea6b380742e757b48d19f319fe46dc5fae837604
|
|
"Invalid" numbers are identified according to PhoneNumberUtil.isValidNumber.
This is necessary to support loose matching for such numbers. However, ContactsContract.PhoneLookup only supports looking up individual numbers, which means that we cannot issue batch queries and must issue individiual queries for each invalid number.
The hope is that these numbers won't appear frequently so performance should still be acceptable.
However, as a failsafe, if there are more than 5 invalid numbers we just give up trying to bulk update the invalid numbers and signal that those numbers are INCOMPLETE so that the UI can query for their CP2 information on the fly (the UI will be updated in a future CL).
It was necessary to convert much of the class to use futures to support parallelization of the queries.
Bug: 71504246
Test: unit
PiperOrigin-RevId: 181216674
Change-Id: I3bec477d305772b4ca3e46d0bd326cfebf9fa313
|
|
This CL implements looking up the dialer internal database for blocked numbers when the system database is not available yet.
Data is only invalidated when dialer is alive since that is the only time blocked numbers can be set and removed.
Bug: 70989538,70989547
Test: DialerBlockedNumberPhoneLookupTest
PiperOrigin-RevId: 180956355
Change-Id: Ie7acf091bf58a074d0a1ee39613fad035d2e6e60
|
|
This allows indvidual PhoneLookups to define and deal mostly with their own submessage type (with the exception of trivial setter and getter methods for converting from/to PhoneLookupInfo).
This also simplifies the FakePhoneLookup and tests which use it a bit, I think.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 179976215
Change-Id: I2db1fc85771621be2f2afcd6af114d82680e30d0
|
|
Bug: 34672501
Test: unit
PiperOrigin-RevId: 179726904
Change-Id: I6a81ef28675af7f95139193b69f87decddc4c844
|
|
The existing way that protos are merged in CompositePhoneLookup is not correct because foo_submessage from BarDataSource may incorrectly contribute old information to the merged message.
The new copySubMessage method makes it so that each PhoneLookup is responsible for defining which submessage it is responsible for and prevents the problem.
Test: unit
PiperOrigin-RevId: 179707015
Change-Id: I566305cf64c46c698f14812d9241d166ac75a6d3
|
|
Bug: 34672501
Test: unit
PiperOrigin-RevId: 179278530
Change-Id: If629aa2c31efad790c8c70e8066dc9a5612d1fc3
|
|
This is necessary to support the case when the user has just upgraded to the new UI and there is no PhoneLookupHistory data yet, or they have cleared their data.
Bug: 70570635
Test: unit and manual
PiperOrigin-RevId: 179261139
Change-Id: I1e521d2e86bd3f8643c5c0bb537a52c41f1ceb6d
|
|
Bug: 34672501
Test: unit
PiperOrigin-RevId: 179012381
Change-Id: Icb78c73e243702a71f1a48692151b696ae2ac95f
|
|
We're not going to use the "cached" columns from the system call log any longer, and instead will write them using PhoneLookup.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 178788155
Change-Id: I9255dd3cb727eef3b45bc05aeb3c6fd6fd513d63
|
|
This is just to more clearly convey what the method does.
Bug: 34672501
Test: existing
PiperOrigin-RevId: 178188575
Change-Id: Id02f34b1d79346ecd8ca9eebc043fe9b3063264b
|
|
Use them where appropriate.
Bug: 34672501
Test: existing
PiperOrigin-RevId: 178182298
Change-Id: If454225e0d636c7cb14b5af02d46780d7732abf0
|
|
When a call is added in InCallUi, it fetches the current PhoneLookupInfo for the call and writes it to PhoneLookupHistory.
Required updating PhoneLookupHistoryContentProvider#update to use "replace" to (presumably) atomically insert when a row is missing.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177896892
Change-Id: I43f9ded240a81156722be816a9635d586de642a1
|
|
Also added onSuccessfulBulkUpdate method.
It is safer for each PhoneLookup to keep track of its own last processed time via shared prefs where the value saved is the actual last processed timestamp from the underlying data. This is because it is difficult or impossible to select a single time that spans lookups due to queries being run and processed at different times.
The onSuccessfulBulkUpdate method is provided as a hook for PhoneLookups to persist their shared pref once they know the result of bulkUpdate have been successfully saved.
Finally, removed usage of the lastModified timestamp from PhoneLookupHistory in PhoneLookupDataSource since I believe the cases it was originally intended to cover are now handled by populateInserts().
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177891586
Change-Id: I072409fc217e4d7e36816548862e8b358aebf165
|
|
Rewrote FakePhoneLookup to be more realistic.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177376374
Change-Id: Ifcd52b16b7046f39d1bfc0e8b8e76452a9daadd2
|
|
PhoneLookupInfo should contain one message per PhoneLookup implementation for clarity. Instead of having a repeated Cp2Info field, we now have a single Cp2Info field which wraps a repeated Cp2ContactInfo field.
Also added ApdlInfo to the message to make testing of CompositePhoneLookup more realistic, in that it tests merging across submessages now. (ApdlInfo is more or less a placeholder until ApdlPhoneLookup is implemented.)
Test: yes
PiperOrigin-RevId: 175316738
Change-Id: I196c2eaa885e1268ff80ebaad6d85840a9cc7a15
|
|
Test: Cp2PhoneLookupTest
PiperOrigin-RevId: 174525877
Change-Id: I7888f3b6adc58416c560271166ec6bd85306d58b
|
|
Fleshed out docs for PhoneLookup.
Added dagger components and modules.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 173977963
Change-Id: If07795d9d3d56a59afd27cdda3e98543bf30fdb8
|
|
Checks if a cp2 contact has been modified or deleted.
Bug: 67605130,64099602
Test: Cp2PhoneLookupTest
PiperOrigin-RevId: 173499443
Change-Id: I1fa267c05732fba09f00113232d4370b159aa735
|
|
Bug: 67605130
Test: Cp2PhoneLookupTest
PiperOrigin-RevId: 171757865
Change-Id: If92e759567456dda09a925e9c625df001f2d573f
|