Age | Commit message (Collapse) | Author |
|
Bug: 77835800
Test: Manual
PiperOrigin-RevId: 195861757
Change-Id: I79f99c3468324922560961ea71dcc792a4d83a24
|
|
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
|
|
sheet)
Bug: 77835800
Test: Manual
PiperOrigin-RevId: 195706300
Change-Id: Iccc97d5cc3ab6f196dc917faf1d7b6659b06cf30
|
|
Bug: 71719349
Test: CallLogEntryTextTest, HistoryItemActionModulesBuilderTest
PiperOrigin-RevId: 195694340
Change-Id: Ib53305c36f7ca062ef798ab3f61585d3c71adef3
|
|
Bug: 71719349
Test: EmergencyPhoneLookupTest, PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 195691356
Change-Id: I705721fa6e6a22e5b2d541578b83196181c895eb
|
|
This avoids a cast and generally improves understandability.
TEST=existing
Test: existing
PiperOrigin-RevId: 195457457
Change-Id: Ida9d3fc85bed8ff1e0f8064805e23fab00fdeddf
|
|
Previously the listener is not cleared, and clicking on a private will call whatever the view was previously bound to.
TEST=TAP
Bug: 79219109
Test: TAP
PiperOrigin-RevId: 195332291
Change-Id: I4806ab659099dc7986b90c68f2e52d8efd4f5f5b
|
|
TEST=TAP
Bug: 79089209
Test: TAP
PiperOrigin-RevId: 195317152
Change-Id: I2d456dc786f2ea6555b76d3ef6721140acee7413
|
|
Test: HistoryItemActionModulesBuilderTest, ModulesTest
PiperOrigin-RevId: 195294876
Change-Id: Iac44f965a585975389da7dee758a94a8ad8311d3
|
|
|
|
* changes:
Translation tweaks.
Migrated context menu to be a PopupMenu instead.
Add column for call mapping id to AnnotatedCallLog database.
Don't force open keyboard when RTT is active.
|
|
Bug: 79153175
Test: Compiled and verified that merged manifest had targetSdkVersion=28
PiperOrigin-RevId: 195145440
Change-Id: I12cde947d8fe8594f91bcc3dacdba6f9c72ac84a
|
|
This will ensure call mapping used by RTT etc. won't break when migrating to
new way to generate the call mapping id since they are stored in the database
already.
Bug: 77717594
Test: unit tests
PiperOrigin-RevId: 195132562
Change-Id: Ieb52489b19b37ac2701967eb570a96457ceed4c0
|
|
They are not constant across different Duo implementations.
TEST=TAP
Bug: 76430187,78783816
Test: TAP
PiperOrigin-RevId: 195001650
Change-Id: I4356d04c9eeac50fefd41e1142f3123591e93bc0
|
|
Previously the NUI call log call backs with whatever SIM the call was made/received in, which is inconsistent with the old UI. The Old UI behavior should be kept.
TEST=TAP
Bug: 78291136
Test: TAP
PiperOrigin-RevId: 194878167
Change-Id: If9c5adcbed6a194c801d2b558abb45573b97d2ae
|
|
Bug: 70989584
Test: PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 194494486
Change-Id: I706802c000da953f962786bd07ca5da2fd59dc8a
|
|
Bug: 78291768
Test: ModulesTest
PiperOrigin-RevId: 194114862
Change-Id: Iee367be53ffff5226a818ebb4af69ddd55054812
|
|
call log.
For some reason not understood, startActivity with the call intent causes the current activity (MainActivity) to be paused, resumed, and paused again. This results in an opportunity to double-tap the row which causes the InCallUi to open in bubble mode (this is also not well understood).
In any event, PreCall.start eventually uses TelecomManager to place the call rather than startActivity, which is presumably the thing that fixes the problem.
Also refactored TestPreCallModule to remove the many test implementations of PreCall and remove the static field in the module which could cause test interference.
TEST=manual
Bug: 78187587
Test: manual
PiperOrigin-RevId: 193596093
Change-Id: I933020d33db1c158628f14b30c2681c59c86201b
|
|
Bug: 70988691
Test: ModulesTest
PiperOrigin-RevId: 193434411
Change-Id: I3fe493eeb2869cad0d42ccf08d57018a42b1b84e
|
|
telecom/Duo calls.
Bug: 70988691
Test: ModulesTest, DuoCallModuleTest
PiperOrigin-RevId: 193431749
Change-Id: I2af9979504b99175513cb753a030244f735828be
|
|
Use ShortNumberInfo to identify shortcodes and apply more basic matching for them; without this short codes like '5555' and '55555' would match due to being a SHORT_NSN_MATCH even though they should not match.
Also removed the PhoneNumberUtil argument from DialerPhoneNumberUtil's constructor as it was always PhoneNumberUtil.getInstance(). (This allowed me to do a similar thing for ShortNumberInfo.getInstance()).
TEST=unit
Bug: 71586485
Test: unit
PiperOrigin-RevId: 193288929
Change-Id: Ia16c78e7eee5e0912d3913660952b9ee32713731
|
|
It is not marked "not null" in the system call log and our simulator gives it null data, so handle it more gracefully to be on the safe side.
Also enforce "not null" for IS_READ and NEW in annotated call log as I observed that happening somehow (possibly from older builds though).
TEST=existing
Test: existing
PiperOrigin-RevId: 193271095
Change-Id: I780db20c9d6ea5cf5e1d757def9ea06b492267c1
|
|
Bug: 70989614
Test: NewCallLogAdapterTest
PiperOrigin-RevId: 193101600
Change-Id: I52b0db9dc03d5e44cad7462403c2639fb33b5f33
|
|
call log.
Bug: 77808449
Test: NewCallLogViewHolderTest + existing tests for the call log framework
PiperOrigin-RevId: 193086917
Change-Id: I39244c69acf1d261699610f6010c0cf147ca3492
|
|
Test: tap
PiperOrigin-RevId: 192825959
Change-Id: I814537b08d9afd678c1cb88e6012e60e5511b6bb
|
|
Accomplished by replacing margin with padding.
TEST=manual
Bug: 77812328
Test: manual
PiperOrigin-RevId: 192818386
Change-Id: Iaf58b8460c18259a0472fd154695238c7e93a489
|
|
Bug: 70989614
Test: NewCallLogAdapterTest
PiperOrigin-RevId: 192692744
Change-Id: I42dbb5738558803ad6eae9fe2c2f98b31c49f360
|
|
Bug: 77717594
Test: ContactPhotoViewTest
PiperOrigin-RevId: 192492913
Change-Id: I6db36017fde2cf9dca580d60d5c88bf2ad2dfe16
|
|
the capability is present.
Bug: 70989603
Test: ModulesTest
PiperOrigin-RevId: 192302145
Change-Id: I3162e7d22223aa02709d0d401c70c6fc37a00e3b
|
|
Bug: 77496097
Test: SystemCallLogDataSourceTest
PiperOrigin-RevId: 191845115
Change-Id: Id0d3770e0cd21383cf2f4c5ae5314ca4de258edd
|
|
This makes the old peer read the CallLogConfig#isNewVoicemailFragmentEnabled and show the old or new fragment accordingly.
If the user is viewing the NewVoicemail and the CallLogConfig needs to disable the framework, the new fragment is immediately replaced with the old one. This is necessary because if the user were to scroll the fragment, the AnnotatedCallLog database would be read, which would trigger creation.
I tested this by flipping flags and observing underlying data being removed:
> dialer-cmd configprovider set new_voicemail_fragment_enabled false
> adb shell ls /data/data/com.google.android.dialer/databases/ && echo && adb shell cat /data/user_de/0/com.google.android.dialer/shared_prefs/com.google.android.dialer_preferences.xml
I test flipping flags back and forth on the voicemail tab, call log tab and ensuring that they are independent.
Bug: 77601968
Test: unit and manual. Some tests are failing, so to ensure we can have the voicemail ready for the bug bash tomorrow, I've ignored them temporarily but will be fixed in a follow up CL (tracked by b/77601893)
PiperOrigin-RevId: 191738860
Change-Id: I24ca38b862e98324cf802a3020e7e9df31c0b966
|
|
Duo.
Bug: 77535982
Test: ModulesTest + Manual
PiperOrigin-RevId: 191612821
Change-Id: I417b46ed3ec131bf409c427d82f5b2fa6b791054
|
|
the new call log.
Test: CoalescerTest
PiperOrigin-RevId: 191376690
Change-Id: Id5939175edddd164a1b477319fb20e6d2a9671a9
|
|
Bug: 70988685
Test: DuoCallModuleTest, PlaceDuoCallEndToEndTest, Manual testing
PiperOrigin-RevId: 191372706
Change-Id: I439be71c361eaca722820b81278e5f95322e100c
|
|
We want to be more consistent with other usages of NEW in the app, i.e. NEW should be used primarily by notifications.
Bug: 74821515
Test: unit
PiperOrigin-RevId: 191139559
Change-Id: Ib6fbead8b5589aedd881db26a07f7daed4d83543
|
|
Bug: 70989667
Test: unit
PiperOrigin-RevId: 191099351
Change-Id: I47f1e487e2a0cc23af7b39ae89e20abf993933ea
|
|
Bug: 70988682
Test: Existing tests
PiperOrigin-RevId: 190946639
Change-Id: Iaa8294e8ba6e85ab3c27bb2e67200d7972a240f2
|
|
optional badge.
Bug: 70988682
Test: ContactPhotoViewTest
PiperOrigin-RevId: 190855440
Change-Id: Ib658efa6486b66548c710804049517905dc67b13
|
|
Bug: 70988682
Test: NewCallLogViewHolderTest
PiperOrigin-RevId: 190783830
Change-Id: Ib0b1ec23b7c278b83516019924b6c68ff12adaf9
|
|
This makes the old peer read the CallLogConfig#isNewCallLogFragmentEnabled and show the old or new fragment accordingly.
If the user is viewing the NewCallLog and the CallLogConfig needs to disable the framework, the new fragment is immediately replaced with the old one. This is necessary because if the user were to scroll the fragment, the AnnotatedCallLog and PhoneLookupHistory databases would be read, which would trigger creation.
I don't expect this to be a common case because 1) we hopefully never have to disable the framework and 2) Framework is only updated on Phenotype broadcasts and JobScheduler jobs, which hopefully don't typically happen when user is viewing the call log. However, I still want to make sure that if it happens we don't irreversibly break users when we turn the framework back on.
I tested this by flipping flags and observing underlying data being removed:
> dialer-cmd configprovider set new_voicemail_fragment_enabled false
> adb shell ls /data/data/com.google.android.dialer/databases/ && echo && adb shell cat /data/user_de/0/com.google.android.dialer/shared_prefs/com.google.android.dialer_preferences.xml
I test flipping flags back and forth on the call log tab, speed dial tab, and while the activity was paused (pressing Home after viewing call log).
Note that this CL doesn't address showing missed calls and badge counts correctly with the new fragment; that will come in a later CL.
Bug: 74821995
Test: unit and manual
PiperOrigin-RevId: 190706481
Change-Id: I618d9c1649169abd65733502cfebc662a835e787
|
|
Bug: 72125574
Test: None.
PiperOrigin-RevId: 190572832
Change-Id: I581d3c9e366a1190c1608b369700aeb511fe51d1
|
|
We're not going to have a shortcut for NUI anymore. There are individual flags related to NUI that are controlled in CallLogConfig.
Other related changes to help accomplish this:
-Changed how the call log framework/config/migrator interact; the migrator is now only called on config changes and enabling/disabling of the framework now lives in CallLogFramework.
-Move CallLogConfig an interface, and moved it to its own package and added component and module. This is to simplify tests which just need to check the config status (like PhoneLookupHistoryRecorderTest).
-The "Main" package is also on longer needed since it existed to control the shortcut.
Bug: 74821995
Test: existing
PiperOrigin-RevId: 190251418
Change-Id: I73c8e83aee80295131443a8ffaa7dea716ea89b6
|
|
Manually set to M
- MissedCallNotifierTest (not sure what the issue is here...)
- CallLogGroupBuilderTest (because a check was removed, some NPEs are thrown)
- MainSearchControllerTest (/system/etc/fonts.xml (No such file or directory))
Ignore Tests
- a few random ones in incallui/answer/impl/hint (shared prefs aren't working for some reason)
- VisualVoicemailUpdateTaskTest (disabled the whole test, issue unclear)
Bug: 73902692
Test: tap
PiperOrigin-RevId: 190030202
Change-Id: I1e9b61d758a61582c5a183ee884dd2181d1c10de
|
|
Impls can access appContext via dagger.
Test: existing
PiperOrigin-RevId: 189974157
Change-Id: Ie64d2c6f9ba08fc914d3c31f7e014c2beef3ab00
|
|
Bug: 74821995
Test: unit
PiperOrigin-RevId: 189969399
Change-Id: I8e287cc7884dde7640721bd385fe383a4635f3c8
|
|
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
|
|
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
|
|
Test: Existing tests
PiperOrigin-RevId: 189683790
Change-Id: I0209e7fa839175041da29e9a6d8a590133121376
|
|
Test: Existing tests
PiperOrigin-RevId: 189675976
Change-Id: Ieae92b5ac2aefd3f0397bbb07ebb1c97bd72ed42
|
|
Bug: 74821995
Test: unit
PiperOrigin-RevId: 189670163
Change-Id: Ifdfcab7dc4493cbe688ef77d43df7e7a1400fa27
|
|
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: 74821995
Test: unit
PiperOrigin-RevId: 189648655
Change-Id: I9918bd6f35bf7eb1bebb9862c2d78880457efa91
|
|
Bug: 74202944
Test: ModulesTest, CallDetailsActivityTest
PiperOrigin-RevId: 189204143
Change-Id: I917bac76009522c6a99fdb63299556ec2a454dfa
|
|
This class is responsible for enabling or disabling the call log framework when flags change.
Bug: 74821995
Test: unit
PiperOrigin-RevId: 189143911
Change-Id: I4727645ce621fbc01acbcd0acab523fe955d4075
|
|
Bug: 74402112
Test: none
PiperOrigin-RevId: 188782198
Change-Id: I36c2adcd8f0403c88694343cbbf12e9aba229afb
|
|
Bug: 74202944
Test: Existing tests
PiperOrigin-RevId: 188060790
Change-Id: I4d79a353abf767935383d4149f261f5e96fd7acb
|
|
Bug: 70989667
Test: unit
PiperOrigin-RevId: 187694255
Change-Id: Ie6ec70a70a4c59cbdfe25c34003d21fa2f751564
|
|
This includes:
1) Made RefreshAnnotatedCallLogWorker.refresh() methods return a result which is "not dirty", "dirty but no changes needed" or "dirty and changes need". It will be interesting to see how often these cases occur (will log impressions in a future CL) so I thought we might as well log the latency of each case separately as well.
2) To support 1) added a new method to FutureTimer which allows you to compute the event name from the result of the timed Future. Also needed to update the Metrics interface to support deferring the event name when starting a timer via a generic token.
3) Timing the coalesce operation which is very heavyweight.
4) Made StubMetrics do some logcat logging to easily observe timing information using AOSP
Bug: 70989667
Test: unit
PiperOrigin-RevId: 187691203
Change-Id: I5f19a2fc94d86639486299b65b0edd66eeaab52e
|
|
Bug: 73780748
Test: PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 187404074
Change-Id: I1db81304909fbf63aba00088c12e18922042c3b1
|
|
long method signatures.
Test: Existing tests
PiperOrigin-RevId: 187338094
Change-Id: I0d7a5206d127931d322b5604b2bb81f5202b8de8
|
|
Test: Existing tests
PiperOrigin-RevId: 187254014
Change-Id: I8a57b632d45e87ad075eb8bbb25180858e890f08
|
|
Bug: 73816729
Test: Existing tests
PiperOrigin-RevId: 187230516
Change-Id: I59d70b9676e2972b80f124f29f2c1cb1858efef8
|
|
Bug: 73547944
Test: Cp2ExtendedDirectoryPhoneLookupTest
PiperOrigin-RevId: 187064655
Change-Id: Icb468e0867248f097a77134dd67a53352f7c80b0
|
|
Bug: 70989605
Test: ShowBlockReportSpamDialogNotifierEndToEndTest + Manual
PiperOrigin-RevId: 187047450
Change-Id: I23c3929135bcfe5c14fe317ef65f628dc126027f
|
|
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
|
|
This improves the first time experience by populating the DB when the user is still in other tabs.
Bug: 72119926
Test: Unit tests
PiperOrigin-RevId: 186418788
Change-Id: If011d7191a09fd1aaca489c6e682ccdc643c2139
|
|
Test: existing
PiperOrigin-RevId: 186413083
Change-Id: I96c88c46b0ecc01167b655fa30fc47aaa6a9e351
|
|
Bug: 70989667
Test: unit
PiperOrigin-RevId: 186410938
Change-Id: I0671ab0bbbe957b8f034c673e6309204284756d2
|
|
is truly visible.
Bug: 73347270
Test: NewCallLogFragmentTest, NewVoicemailFragmentTest
PiperOrigin-RevId: 186350076
Change-Id: Ib3e320f02a02795acb8b7d2017818b36df3dd49d
|
|
Bug: 73347270
Test: Existing tests + RefreshAnnotatedCallLogNotifierTest
PiperOrigin-RevId: 186347066
Change-Id: I5a530416bdaa9edc7131a0d5ced44f1b5ee1692b
|
|
Test: ModulesTest
PiperOrigin-RevId: 186006639
Change-Id: I0c37d342d4a6da563b49b3ebe8f8ee2262efde60
|
|
Bug: 73007132
Test: NumberAttributesConverterTest, PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 185545712
Change-Id: I228d8c4e1b6327e38057f73aad63bb7048704d49
|
|
Playing with the existing app, the missed call becomes unbolded when:
1) Expanding the row. The closest analog of this is in the new UI is opening the bottom sheet, I've done that.
2) Swiping away from the call history tab. This can't be done in NewCallLogFragment because it doesn't know if the user is selected a new tab or pressed Home. So, I implemented this in NewMainActivityPeer.
3) After viewing the call log for 3(ish) seconds and leaving the activity pressing Home/Back. This is best done in NewCallLogFragment#onResume since MainActivity doesn't always know when the fragment is being displayed (it could be done after the user comes back to the app after pressing Home for example).
Note that the notification is also removed in all of these cases.
Also note that dismissing the notification makes the call unbolded (but this case already appears to be handled via the system call log content observer).
Also, as part of writing tests for this, I made TestCallLogProvider more realistic.
Bug: 70989622
Test: manual
PiperOrigin-RevId: 185457438
Change-Id: Ib360d3bc73083bd1a018ed98e2b7d9a69fb7fafb
|
|
Bug: 70989605
Test: ModulesTest
PiperOrigin-RevId: 185392711
Change-Id: I709a1e307925f1c99d2740ed52dc2b7784bca986
|
|
Bug: 73077158
Test: CallLogEntryTextTest, GlidePhotoManagerImplTest, PhoneLookupInfoConsolidatorTest
PiperOrigin-RevId: 185017362
Change-Id: I113472482da2213d17a847054272a22249edc578
|
|
This includes:
-Moved call count to after icons
-Bold PhoneAccount for new calls
-Fixed recycling issues in call type icons and phone account
-Fixed cropping at bottom of "y" character (see b/67913060)
-Reduced nesting in layout
-Removed dimens.xml as it shouldn't be shared by voicemail
-Set the alpha for Wifi/HD icons depending on read/unread status
-Don't color call type icons, except for missed
-Call type icons scale with display size
-Call type icons are larger (18dp) in new UI
Note that FrameLayout is used to ensure that icons/callCount view is not clipped, and instead contact name is ellipsized when the content is too wide to fit.
Bug: 67913060,70989593,70989611
Test: unit and manual
PiperOrigin-RevId: 184605728
Change-Id: Ie36c89354cbe4444ad2b42b6b0040430e396691c
|
|
Transcription state column is needed for voicemail transcriptions. This CL adds the support for it in the NUI so that it maybe used by the VM Tab.
Bug: 72491920
Test: Unit Tests
PiperOrigin-RevId: 184335015
Change-Id: I14a71890224216c957e0d6146af9dafaa1550865
|
|
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
|
|
Updated the new call log UI to properly show text based on the presentation.
Bug: 70989592
Test: unit
PiperOrigin-RevId: 183414195
Change-Id: I2123f37cd3c733060125b6e894c1a80be4193ad6
|
|
Methods moved to TelecomUtils
Test: Unit tests
PiperOrigin-RevId: 183305626
Change-Id: Idd6604e58c06a36066bd49870849dd71747969c6
|
|
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: 64655802
Test: n/a
PiperOrigin-RevId: 183149638
Change-Id: Idc58efced8f70311eccd67f403bc5bd98f3f8518
|
|
We currently limit the size of AnnotatedCallLog to 999 via a trigger, but it doesn't exclude voicemails. Since we don't want to ever garbage collect the user's voicemails, exclude them from the trigger.
This means that we can no longer assume a maximum size for the table (the user culd have more than 999 voicemails) so I've updated the places in the code where we did that before.
Finally, I changed AnnotatedCallLog's CALL_TYPE column to be non-null. This is so that we can have more confidence that the trigger will work as intended. Null values cannot be compared in SQLite, so an expression like "where call_type != 4" won't actually match a null call type. Rather than implicitly fail to clean up such rows, we just crash completely when encountering such rows (even though I don't expect that to happen).
Bug: 70989634
Test: unit
PiperOrigin-RevId: 183006714
Change-Id: I9f4394a4812afe4b65c1e8427c355d825356557c
|
|
calllog/database/contract.
The "model" package should be reserved for call history proper (and not voicemail) so it shouldn't contain things needed by voicemail.
Test: existing
PiperOrigin-RevId: 182976719
Change-Id: I463c8ed4600950a8d18db49d991609bfaa49c709
|
|
This is an optimization to reduce "popping" in the new call log. Since we have to do the PhoneLookup anyway to update the UI, we may as well write the result to PhoneLookupHistory so that the next time the AnnotatedCallLog is refreshed, the updated results can be retrieved from PhoneLookupHistory.
I also updated RealtimeRowProcessorTest to use FakePhoneLookup rather than the real Cp2PhoneLookup since RealtimeRowProcessor no longer uses Cp2PhoneLookup directly (it was updated to use the general-purpose PhoneLookup in a previous CL but I didn't update the test at that time).
Test: unit
PiperOrigin-RevId: 182974567
Change-Id: I813e9d69f802ca08757238290fdfcf58e78b3592
|
|
Bug: 72235391
Test: Manual
PiperOrigin-RevId: 182848699
Change-Id: I587f5f4dd770278747114da17581c8fc253651c0
|
|
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
|
|
Bug: 70989598
Test: NewCallLogAdapterTest, CallLogDatesTest
PiperOrigin-RevId: 182567571
Change-Id: Ieabbe709668d843334bc3bf4a128834fddb57cb8
|
|
-Don't ever coalesce rows with different post-dial digits
-Made matching of unparsable numbers a little more intelligent by comparing national/postdial portions which have undialable characters removed (rather than exact string match)
-Read and append the post-dial digits from the system call log when building DialerPhoneNumbers to place in the AnnotatedCallLog. Note: PhoneNumberUtil will parse numbers with exactly one post-dial character, but not more than one.
-Use post-dial digits when building the AnnotatedCallLog's FORMATTED_NUMBER value
-Display the formatted number in CallDetails when the name is missing, instead of the unformatted number
-Don't set the displayNumber in CallDetails when the name is missing, because we are showing the (formatted) number via the nameOrNumber field.
-Treat numbers with post-dial digits as invalid in PartitionedNumbers; batch operations are not possible with these numbers because their normalized representations strip the post-dial digits (and they are significant for contact matching)
Bug: 70989632
Test: unit and manual
PiperOrigin-RevId: 182557754
Change-Id: Idcdefce0946a189e5b350a53ec2a16a96a8d4552
|
|
We currently require two numbers to be a PhoneNumberUtil.MatchType.EXACT_MATCH to coalesce them, but this means that two numbers like "456-7890" and "408 456-7890" won't ever be collapsed.
This is potentially a likely situation since it is possible to dial numbers without an area code so we should better support it (and the old call log coalesces such numbers today).
Bug: 70989626
Test: unit
PiperOrigin-RevId: 182289194
Change-Id: If884d5a1f2631116a2729e0635f9a97aeca3e057
|
|
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
|
|
the new call log.
Bug: 70218437,71867391
Test: ModulesTest & Manual
PiperOrigin-RevId: 182233967
Change-Id: I6eb4bf236230eee6bbecc99b128fef5afddfd1e9
|
|
-Reset the text appearance when recycling
-Clear the secondary call types when recycling
Test: unit
PiperOrigin-RevId: 181824011
Change-Id: I92cf2c570754e60f3559ad6b47157b3538c6e2cc
|
|
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
|
|
Voicemails that are deleted or marked as deleted should not show up in the annotated call log.
Bug: 71885122
Test: N/A
PiperOrigin-RevId: 181719056
Change-Id: I7a5f7769ecbfc5feaaee36f0f1de48155576f458
|