| Age | Commit message (Collapse) | Author |
|---|
|
Bug: 73547944
Test: Cp2ExtendedDirectoryPhoneLookupTest
PiperOrigin-RevId: 187064655
Change-Id: Icb468e0867248f097a77134dd67a53352f7c80b0
|
|
Bug: 73347270
Test: Existing tests + RefreshAnnotatedCallLogNotifierTest
PiperOrigin-RevId: 186347066
Change-Id: I5a530416bdaa9edc7131a0d5ced44f1b5ee1692b
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
