summaryrefslogtreecommitdiff
path: root/java/com/android/dialer/phonelookup/composite/CompositePhoneLookup.java
AgeCommit message (Collapse)Author
2018-05-09Added getLoggingName() to CallLogDataSource and PhoneLookup interfaces.zachh
Use it when logging performance metrics. Unfortunately the class names returned by Class#getSimpleName() are obfuscated by proguard and make viewing the metrics difficult to impossible. TEST=none Test: none PiperOrigin-RevId: 195749831 Change-Id: I40320f388d34e059c9a913e2b72a1acf1a727f60
2018-04-19Support extracting info from a Call in PhoneLookuplinyuh
Bug: 70988915 Test: CompositePhoneLookupTest, PhoneLookupTest PiperOrigin-RevId: 193592973 Change-Id: I27b6a63049117ce6d31e50aea9c56c14f01d0e1d
2018-03-22Removed appContext from CallLogDataSource and PhoneLookup.zachh
Impls can access appContext via dagger. Test: existing PiperOrigin-RevId: 189974157 Change-Id: Ie64d2c6f9ba08fc914d3c31f7e014c2beef3ab00
2018-03-20Added "clearData" to CallLogDataSource and PhoneLookup interfaces.zachh
This is necessary to disable the call log framework via flags. This isn't yet called anywhere. Bug: 74821995 Test: unit PiperOrigin-RevId: 189838957 Change-Id: I926c02c41151528eabc208c874acbfe7897a2f93
2018-03-20Added unregisterContentResolvers() to CallLogDataSource and PhoneLookup.zachh
This is needed to support flag changes which should cause the call log framework to become disabled. It's not called anywhere yet. Bug: 74821995 Test: unit PiperOrigin-RevId: 189761665 Change-Id: I914c690448f03ebacd7d05c9ad082aba7bf1a4ce
2018-02-23Track initial call log building metrics separately from incremental building ↵zachh
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
2018-02-22Added some logcat and metrics logging for new call log.zachh
Bug: 70989667 Test: unit PiperOrigin-RevId: 186726722 Change-Id: I1a68ae1e01b101b1624e4f5ede1a8d639d481ad2
2018-02-22Use a broadcast receiver to refresh the annotated call log.linyuh
Bug: 73347270 Test: Existing tests + RefreshAnnotatedCallLogNotifierTest PiperOrigin-RevId: 186347066 Change-Id: I5a530416bdaa9edc7131a0d5ced44f1b5ee1692b
2018-01-26Reworked the internals of DialerPhoneNumber.zachh
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
2018-01-22Changed PhoneLookup#lookup to accept a DialerPhoneNumber.zachh
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
2018-01-11Fixed bug in handling of empty numbers in new call log.zachh
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
2018-01-05Implement dialer blocked number phone lookuptwyen
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
2017-12-27Parameterized PhoneLookup with submessage type.zachh
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
2017-12-22Added copySubMessage method to PhoneLookup interface.zachh
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
2017-12-07Renamed PhoneLookup#bulkUpdate to #getMostRecentPhoneLookupInfo.zachh
This is just to more clearly convey what the method does. Bug: 34672501 Test: existing PiperOrigin-RevId: 178188575 Change-Id: Id02f34b1d79346ecd8ca9eebc043fe9b3063264b
2017-12-07Added bindings for ListeningExecutorServices.zachh
Use them where appropriate. Bug: 34672501 Test: existing PiperOrigin-RevId: 178182298 Change-Id: If454225e0d636c7cb14b5af02d46780d7732abf0
2017-12-07Added PhoneLookupSelector.zachh
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
2017-12-07Removed timestamps from PhoneLookup APIs.zachh
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
2017-11-11Use lambdas in CompositePhoneLookup.zachh
They should work now that we target guava 20 instead of 18 in AOSP. Test: tap PiperOrigin-RevId: 175354039 Change-Id: Id7844c3a1c8e29e5ecb13fa36a92dd80be0cfc7c
2017-11-11Implemented CompositePhoneLookup#bulkUpdate.zachh
Bug: 34672501 Test: unit PiperOrigin-RevId: 174532642 Change-Id: I0115fb26f99fe764bc90625e3ed51f3c4c99439d
2017-11-10Implemented CompositePhoneLookup#isDirty.zachh
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
2017-11-10Fixed AOSP breakage due to incompatible guava api.zachh
Test: none PiperOrigin-RevId: 174258291 Change-Id: Idf4eb0096fef383bd5f3544fdedba03528d14f41
2017-11-10Set the ceiling at O.erfanian
Test: no PiperOrigin-RevId: 174239092 Change-Id: I6672c5b0a41df6426b527d1565f0cb216dc82917
2017-11-01Added CompositePhoneLookup and added and implemented "lookup" method.Zachary Heidepriem
Fleshed out docs for PhoneLookup. Added dagger components and modules. Bug: 34672501 Test: unit PiperOrigin-RevId: 173977963 Change-Id: If07795d9d3d56a59afd27cdda3e98543bf30fdb8
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-15 16:14:52 +0000