Age | Commit message (Collapse) | Author |
|
Bug: 70989598
Test: NewCallLogAdapterTest, CallLogDatesTest
PiperOrigin-RevId: 182567571
Change-Id: Ieabbe709668d843334bc3bf4a128834fddb57cb8
|
|
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
|
|
Otherwise changes to "incomplete" rows won't take effect until a new adapter is created.
Test: unit and manual
PiperOrigin-RevId: 181823087
Change-Id: I24e1b1b465c8d37cf794312b88b6cdd3ad394b5d
|
|
-Reuse the adapter in NewCallLogFragment to maintain position in call log when returning from call details
-Convert empty values to null when invoking ContactPhotoManager to make photos appear correctly in new call log bottom sheets
-Added CallLogContactTypes to be shared between proper call log and bottom sheets
-Fixed vertical alignment in bottom sheet when there was no secondary text
-Added some verbose logging
Test: unit and manual
PiperOrigin-RevId: 181655715
Change-Id: I9c1a42ad8d529ee2327e15fcc1d32b7b83982014
|
|
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
|
|
Also added ability to click on row to call.
Required plumbing through the original phone number and phone account info through AnnotatedCallLog and CoalescedAnnotatedCallLog, so that clicking to dial doesn't require an additional lookup.
Required some refactoring:
-created autovalue for CoalescedRow.
-created autovalue for ContactPrimaryActionInfo and use it in ContactActionBottomSheet
-moved logic for building primary and secondary text into CallLogUtils so it can be shared between call log list and bottom sheets
-moved clipboard logic to own package for copying numbers
Bug: 34672501
Test: unit
PiperOrigin-RevId: 171760252
Change-Id: I645d89974460b611c1d9668c3ca3e50a716c7f8f
|
|
Previously, Android's Dialer app was developed in an internal Google
source control system and only exported to public during AOSP drops.
The Dialer team is now switching to a public development model similar
to the telephony team.
This CL represents all internal Google changes that were committed to
Dialer between the public O release and today's tip of tree on internal
master. This CL squashes those changes into a single commit.
In subsequent changes, changes will be exported on a per-commit basis.
Test: make, flash install, run
Merged-In: I45270eaa8ce732d71a1bd84b08c7fa0e99af3160
Change-Id: I529aaeb88535b9533c0ae4ef4e6c1222d4e0f1c8
PiperOrigin-RevId: 167068436
|