Age | Commit message (Collapse) | Author |
|
metrics.
This required creating "CallLogState" which is currently just a boolean value which can only be turned on once (when the annotated call log flow finishes for the first time).
This CL also changes CompositePhoneLookup to no longer implement PhoneLookup. This was done to support a now reverted implementation of CallLogState but it's easier for me to keep the change and it shouldn't be harmful.
Bug: 70989667
Test: unit
PiperOrigin-RevId: 186852257
Change-Id: I3f342737aaf909f8230b8a69d9c21e6e5c19b84e
|
|
Bug: 70989667
Test: unit
PiperOrigin-RevId: 186726722
Change-Id: I1a68ae1e01b101b1624e4f5ede1a8d639d481ad2
|
|
Bug: 73347270
Test: Existing tests + RefreshAnnotatedCallLogNotifierTest
PiperOrigin-RevId: 186347066
Change-Id: I5a530416bdaa9edc7131a0d5ced44f1b5ee1692b
|
|
It turns out the storing the libphonenumber representation of the number is not particularly useful because even formatting these objects cannot be done on the main thread. Rather than propagate the requirement of using PhoneNumberUtil (and background threads by extension) in the call log UI, we now just store a dialer-normalized version of the number which contains all information required by the UI in a way that allows us to avoid any background work in the UI code.
Bug: 72563861
Test: existing
PiperOrigin-RevId: 183463907
Change-Id: I4bdadaccb7a84033b3c72c54fe3833064f587ee3
|
|
There's a problem with the existing implementation of RealtimeRowProcessor; when CP2 information is not present, data from other sources can potentially be erased.
This CL fixes the problem by fetching the latest data from all sources, instead of just CP2. This requires being able to fetch PhoneLookup info without a Call, using only a number, so I changed PhoneLookup#lookup to accept a DialerPhoneNumber rather than a Call.
(The reason that it accepted a Call was to support CNAP so we'll need a revised solution for that later.)
There is a potential concern with performance in RealtimeRowProcessor due to performing a full [Composite]PhoneLookup vs. a CP2 lookup, because the full lookup includes network requests. However, it's anticipated that the real time lookups will very rarely have changes to apply so this might be OK as-is. If not, a mitigation strategy could be improving the performance of CompositePhoneLookup#lookup by short-circutiing slower sources when faster, higher priority sources have already completed.
A follow-up CL will write the result of RealtimeRowProcessor queries to PhoneLookupHistory to further reduce how frequently real time updates need to be applied.
Bug: 72229553
Test: existing unit
PiperOrigin-RevId: 182839130
Change-Id: I8cb26827b4f4dc4702fb416234c8938179cd5ac5
|
|
Empty numbers were not being inserted into PhoneLookupHistory because the URI "content://.../PhoneLookupHistory/" is treated the same as "content://.../PhoneLookupHistory" (w/o the trailing slash). This caused the update (i.e. replace) operation to incorrectly update all rows in the table when it should have updated a single row.
The fix for this was to switch to a query parameter, so the empty number URI now looks like "content://.../PhoneLookupHistory?number="
Also improved some logging while debugging this problem.
Bug: 71866050
Test: unit and manual
PiperOrigin-RevId: 181659081
Change-Id: Idec4fb77e74920cd5485620b0a997db03aa8ff9b
|
|
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
|
|
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
|
|
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
|
|
This class is responsible for prioritizing and selecting data from a PhoneLookupInfo object, which contains information from many phone lookup sources.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177893924
Change-Id: Ib98a4656fe87141162a7ac53af4a0ad421196046
|
|
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
|
|
They should work now that we target guava 20 instead of 18 in AOSP.
Test: tap
PiperOrigin-RevId: 175354039
Change-Id: Id7844c3a1c8e29e5ecb13fa36a92dd80be0cfc7c
|
|
Bug: 34672501
Test: unit
PiperOrigin-RevId: 174532642
Change-Id: I0115fb26f99fe764bc90625e3ed51f3c4c99439d
|
|
IsDirty is implemented by (possibly in parallel) executing all child lookups, and completing as soon as the first lookup reports itself as dirty, cancelling other lookups upon completion.
If a lookup fails for some reason, it is treated as not being dirty.
This required adding a new method DialerFutures#firstMatching.
Bug: 34672501
Test: yes
PiperOrigin-RevId: 174261470
Change-Id: Icb4f7b5d9926094fc446542411d15d02a4b873a3
|
|
Test: none
PiperOrigin-RevId: 174258291
Change-Id: Idf4eb0096fef383bd5f3544fdedba03528d14f41
|
|
Test: no
PiperOrigin-RevId: 174239092
Change-Id: I6672c5b0a41df6426b527d1565f0cb216dc82917
|
|
Fleshed out docs for PhoneLookup.
Added dagger components and modules.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 173977963
Change-Id: If07795d9d3d56a59afd27cdda3e98543bf30fdb8
|