Age | Commit message (Collapse) | Author |
|
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
|
|
This data source determines if the call is to the voicemail inbox.
isVoicemail() is removed from NumberAttributes and PhoneLookup. It is yet decided how in call UI should handle voicemail calls in the future.
TAG_CHANGE_OK=proto not in prod yet. Please clear app data.
TYPE_CHANGE_OK=above
Bug: 70989587
Test: Unit tests
PiperOrigin-RevId: 189650273
Change-Id: Iafebf1abb18c74301b62a72d1d04deecd6d78d29
|
|
Bug: 73780748
Test: PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 187404074
Change-Id: I1db81304909fbf63aba00088c12e18922042c3b1
|
|
Bug: 73887387
Test: Existing tests
PiperOrigin-RevId: 187225355
Change-Id: I65de553078e147a46d933daf34dfd912fc8aa74c
|
|
Bug: 73547944
Test: Cp2ExtendedDirectoryPhoneLookupTest
PiperOrigin-RevId: 187064655
Change-Id: Icb468e0867248f097a77134dd67a53352f7c80b0
|
|
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
PiperOrigin-RevId: 186475562
Change-Id: I622b52f4d74b26fd084b6588da6321c46458aa9d
|
|
Bug: 73347270
Test: Existing tests + RefreshAnnotatedCallLogNotifierTest
PiperOrigin-RevId: 186347066
Change-Id: I5a530416bdaa9edc7131a0d5ced44f1b5ee1692b
|
|
Bug: 73007132
Test: NumberAttributesConverterTest, PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 185545712
Change-Id: I228d8c4e1b6327e38057f73aad63bb7048704d49
|
|
Bug: 72108777
Test: Unit tests
PiperOrigin-RevId: 185058075
Change-Id: I161b5127fdc94c0b77536d2901e2c24d7f1eeb7c
|
|
Bug: 73077158
Test: CallLogEntryTextTest, GlidePhotoManagerImplTest, PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 185017362
Change-Id: I113472482da2213d17a847054272a22249edc578
|
|
Bug: 70989534
Test: SpamPhoneLookupTest
PiperOrigin-RevId: 184738576
Change-Id: I63743e5df155a8d31ffa5e2ee3b88e2446023a28
|
|
There will never be contact information for an empty number, so don't bother trying to look them up at render time.
This also prevents a crash in the new voicemail fragment that occurs due to an assertion that voicemail rows will never be incomplete, when it may be possible for a voicemail to exist with an empty number.
Also, don't set short numbers in VoicemailPopulator, since we don't expect this to be possible and would like to avoid crashing in the aforementioned assertion when using simulator.
Test: unit
PiperOrigin-RevId: 184615402
Change-Id: I5286112b57179e002f04de81c04475f30b3e1833
|
|
These are frequently used attributes of numbers that we can compute once at parse-time.
Also did some general cleanup of DialerPhoneNumberUtil:
-Removed unused Future version of parse()
-Remove formatToValidE164 now that the new fields are available
-Inlined normalizeNumber()
Bug: 72563861
Test: existing
PiperOrigin-RevId: 183720128
Change-Id: I702dc265360e590439c5352c493ae8a858f36812
|
|
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
|
|
Bug: 70989534
Test: SpamPhoneLookupTest
PiperOrigin-RevId: 183174131
Change-Id: I46e819a0710ccce293195594e2f249e91d74551a
|
|
CallLogPhoto.getPhotoUri() returns a URI to a drawable so it will be easier to transition into glide. Meanwhile ContactPhotoManager will just show the drawable directly.
Bug: 70989547
Test: Unit tests
PiperOrigin-RevId: 183163818
Change-Id: I4ee4ff98782e35d2be03dfe14f8bf3dfd6ded074
|
|
Bug: 70989534
Test: Existing tests
PiperOrigin-RevId: 183145910
Change-Id: I60b0122fb236a7e7ee7b746867c40fefe0a3b487
|
|
This CL implements looking up blocked number in the Android system blocked number provider, which is available after N. Dialer and system blocked number will return empty if requirements are not made (N+ and migration completed is needed for system, otherwise dialer should not be used).
Bug: 70989543
Test: Unit tests
PiperOrigin-RevId: 182852672
Change-Id: I1360b7eed7c18f459292d769529ffcfceb61a7ed
|
|
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
|
|
Test: Unit tests
PiperOrigin-RevId: 182813080
Change-Id: I952f49352fb57c02c4efb9cc4ede84dc7c32c893
|
|
Test: unit
PiperOrigin-RevId: 182280850
Change-Id: I51a89f50d56af344425d5f67c6bcaa3928b457e9
|
|
This is an optimization to reduce popping in the new call log. Currently when Cp2LocalPhoneLookup determines a number to be "incomplete" (because it is an invalid number and there are too many invalid numbers in the call log to efficiently bulk update) we clear the existing data, which has been populated in PhoneLookupHistory (for example, from InCallUi). This means that we will show the number initially when displaying the call log, and then when the query completes we will "pop in" the new information.
This change makes it so that we don't clear the existing data from PhoneLookupHistory, and just add the "incomplete" bit. The result of this is that we immediately display the available information when initially displaying the call log (even though it may be out of date). When the query completes, the row will be updated with the most recent information; in most cases this is likely to be the same as the information used to initially display the row, and no update will need to be applied.
Additoinal changes to support this functionality:
-RealtimeRowProcessor is now just responsible for returning an updated row, and NewCallLogView holder will compare the result to the originally displayed row and only update the UI if there are differences.
-NewCallLogFragment now calls clears the RealtimeRowProcessor's cache and notifies data set changed during onResume. This is to account for the fact that AnnotatedCallLog no longer contains the complete set of information necessary to show the call log; there may be changes we need to show which can't be detected by the cursor loader. We now show those potential changes in onResume.
Additional notes:
-If there is real-time data that changes after onResume it won't be detected but there shouldn't be such cases; changes made to contact information from dialer are always done through contact cards which pause the fragment.
-This change has the effect that whatever information was written to PhoneLookupHistory during the previous invocation of InCallUi will always be (initially) shown. For example, if the contact name for number "123" is "Joe" when the call comes in, we'll write "Joe" to PhoneLookupHistory. If the user changes Joe's name to "Jane", the UI will pop from "Joe" to "Jane" until PhoneLookupHistory is updated (which is currently only done from InCallUi). If this turns out to be a problem it could be mitigated by writing updated results to PhoneLookupHistory from the UI.
Test: unit, manual
PiperOrigin-RevId: 182277145
Change-Id: I3d9916b7747390ff956f399fe84b26d578e5a07f
|
|
PhoneLookupInfoConsolidator is designed for the following two purposes.
(1) Different sub-messages in a PhoneLookupInfo proto can contain information for the same purpose. For example, all of cp2_local_info, cp2_remote_info, and people_api_info have the information for a contact's name. PhoneLookupInfoConsolidator defines the rules that determine which sub-message should be used to display the name in the UI. This is the same as PhoneLookupSelector.
(2) Avoid mixing info from different sub-messages when we are supposed to stick with only one sub-message. For example, if a PhoneLookupInfo proto has both cp2_local_info and cp2_remote_info but only cp2_remote_info has a photo URI, PhoneLookupInfoConsolidator should return an *empty* photo URI as cp2_local_info has higher priority and we should not use cp2_remote_info's photo URI to display the contact's photo. This is what PhoneLookupSelector is unable to do.
Bug: 71763594
Test: PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 182236013
Change-Id: If19cdc1a9e076f3ebc8f9e2901f050b519e273f2
|
|
Test: none
PiperOrigin-RevId: 181816649
Change-Id: I4e951366e9458899181fb95230a2815ed5fcdaa8
|
|
We don't actually parition by "formattable", we parition by "valid". An invalid number like 456-7890 can be formatted to E164 ("+14567890") but what ParitionedNumbers actually does is parition by valid/invalid (and then converts the valid numbers to E164).
Also added a new sharded test suite for phonenumberproto tests which had occasionally been timing out on TAP.
Test: existing
PiperOrigin-RevId: 181800443
Change-Id: Id64fc32c893025b0115dd350dd87e3277607f21c
|
|
Bug: 71763594
Test: Cp2LocalPhoneLookupTest, Cp2RemotePhoneLookupTest
PiperOrigin-RevId: 181681435
Change-Id: I2e091371b6705390adf4be63c78344f78bd19d6e
|
|
This allow extra information from PhoneLookup to be more easily added. Only PhoneLookupSelector and the proto will be affected for new attributes.
Test: Unit tests.
PiperOrigin-RevId: 181675568
Change-Id: I4e0bc1c6005b58a9b684b030b55bea6223af9ce3
|
|
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
|
|
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 column is filled by PhoneLookupDataSource using PhoneLookupInfo#PeopleApiInfo.
Bug: 70218437
Test: AnnotatedCallLogDatabaseHelperTest, PhoneLookupDataSourceTest, RowCombinerTest, CoalescedAnnotatedCallLogCursorLoaderTest, PhoneLookupSelectorTest
PiperOrigin-RevId: 180839783
Change-Id: I8d5ddb940670724fd4bf6dd6a50dcf408f91da9d
|
|
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
|
|
This CL rewrites com.google.android.dialer.reverselookup and uses gRPC instead to perform People API queries.
Bug: 70355819
Test: PeopleApiPhoneLookupTest, PeopleApiPHoneLookupInfoTransformerTest
PiperOrigin-RevId: 179122466
Change-Id: I769c8b420b9d71b9787d844380b2aceb7ff2c63c
|
|
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
|
|
Required adding applyBatch functionality to PhoneLookupHistoryContentProvider so that the updates can be performed in a transaction. This code was just copied and modified from AnnotatedCallLogContentProvider.
Also removed the trigger which limited the size of the PhoneLookupHistory, since we now delete rows from PhoneLookupHistory when the last occurrence of a number is deleted from AnnotatedCallLog. Since AnnotatedCallLog is bounded to 1000 rows PhoneLookupHistory is now indirectly bounded by that as well.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 178323464
Change-Id: I233163fe70641b0e4b1d4c5c0e8970ad0b4b167d
|
|
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
|
|
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
|
|
Rewrote FakePhoneLookup to be more realistic.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 177376374
Change-Id: Ifcd52b16b7046f39d1bfc0e8b8e76452a9daadd2
|
|
When a user types a phone number into the search bar, there isn't an intuitive
way for them to place a call when the number doesn't match any existing
contacts in the new search UI. This change adds the option to place a voice
call from regular search, like the old UI.
Bug: 69385190
Test: NSFT
PiperOrigin-RevId: 176189153
Change-Id: I6c1561bcce104c56855d996570a79b34da7230ff
|
|
Also extracted FakePhoneLookup to a testing package.
Bug: 34672501
Test: unit
PiperOrigin-RevId: 175923790
Change-Id: I866708a676e788051b369a024344967975c05979
|
|
They should work now that we target guava 20 instead of 18 in AOSP.
Test: tap
PiperOrigin-RevId: 175354039
Change-Id: Id7844c3a1c8e29e5ecb13fa36a92dd80be0cfc7c
|
|
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
|
|
Bug: 34672501
Test: yes
PiperOrigin-RevId: 175243488
Change-Id: Iec3b5eb0e81f6e6cc04c64c3ea65c9c7fcb33fe3
|
|
Bug: 34672501
Test: unit
PiperOrigin-RevId: 174532642
Change-Id: I0115fb26f99fe764bc90625e3ed51f3c4c99439d
|
|
Test: Cp2PhoneLookupTest
PiperOrigin-RevId: 174525877
Change-Id: I7888f3b6adc58416c560271166ec6bd85306d58b
|
|
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
|
|
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
|