| Age | Commit message (Collapse) | Author |
|---|
|
Bug: 70988915
Test: CompositePhoneLookupTest, PhoneLookupTest
PiperOrigin-RevId: 193592973
Change-Id: I27b6a63049117ce6d31e50aea9c56c14f01d0e1d
|
|
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
|
|
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
|
|
Previously it is unclear what the "county ISO" should be so the originating county of the SIM is used. When telecom writes to the call log the county the user is in is used. This caused the DialerPhoneNumber key in in call UI and call log to differ and info to be lost.
In this CL, the current country is used in PhoneLookupHistoryRecorder to make it consistent with the call log.
PhoneLookupHistoryRecorder is currently the only consumer for telecom call util.getCountryCode().
Additionally, dialer/location no longer depends on dialer/util. dialer/util has too many unnecessary dependencies that will cause cycles.
Bug: 73752730
Test: Unit tests
PiperOrigin-RevId: 189378542
Change-Id: I59773f7745c835a6523efda951c475e2fde9aaf9
|
|
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: 64655802
Test: n/a
PiperOrigin-RevId: 183149638
Change-Id: Idc58efced8f70311eccd67f403bc5bd98f3f8518
|
|
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
|
|
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
|
|
Since PhoneLookup exposes Call, more common access to the utility is required.
Bug: 70355819
Test: TelecomCallUtilTest
PiperOrigin-RevId: 178847628
Change-Id: I6cf55ad4e3566596b7b2e8cffb5a1614e6640a8b
|
|
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
|
