Age | Commit message (Collapse) | Author |
|
The previous behavior was such that users that had no numbers in the
Dialer block list still had to go through steps to migrate to the
framework blocking solution, even though there was nothing to
migrate. This changes add logic to check if the blocked list is
empty, if that's the cause the user is automatically switched to the
framework blocking solution. This check is performed only once on app
startup.
Fixes: 27704106
Change-Id: I32482003279ef2070c1ebd8b801acf637c48ba8c
(cherry picked from commit ee4e15b40f0d20b5f04f3569efa12c0d26a38645)
|
|
+ There's an edge case crash in the Dialer when initiating the
migration workflow. If the user has blocked a number in the framework
prior to migrating the Dialer and then attempts to block that number
again in the Dialer, the migration workflow starts, completes, and
then the app crashes. This is because prior to migrating, the Dialer
doesn't know that the number is blocked in the framework, allowing it
to block the same number twice.
+ Since this case is specific to the situation where an already
blocked number initiates migration, this CL fixes the problem by
checking if the number is blocked in the framework, prior to blocking
it after the migration.
Change-Id: I31c8978afb871f364e63cab5cc6da3e5fd106b29
Fixes: 27720157
|
|
+ By design, only the primary user has the capability to block
numbers.
+ This CL ensures that secondary users don't see the option to block
numbers in the call log or call details.
Change-Id: I576925510cfbef417c16910218014d9f7b7dd2a0
Fixes: 27366206
|
|
Bug: 26664600
Change-Id: I64e9d1fbd825f25e23124d95b2475fdd6e0830f9
|
|
+ Rather than using a runtime flag which has to be set for the build,
this CL changes the GreatWall feature to be enableable at runtime.
Bug: 26664600
Change-Id: Ib0e3229da41a08c67076b7bd171ebbc4b35a4c69
|
|
+ After the user has migrated to the framework number blocking
solution, the 'Call blocking' setting needs to take them to the
system ui. The branching logic to determine which UI to open is added
in this CL.
Bug: 26664600
Change-Id: I2574f0665d3f0d3d92230e0210c69d1d10b60228
|
|
+ After upgrading to N, users need to be able to migrate their
blocked number list from the Dialer solution to the framework
solution. Prior to migrating, when a user attempts to block a number,
a Dialog is shown prompting them to migrate their numbers. Users
must migrate to continue adding numbers to their block list. Users
that decide not to migrate will still have calls and voicemails
blocked for numbers that are currently on their block list.
+ This CL implements the logic which copies users' blocked numbers
lists to the framework solution.
Bug: 26664600
Change-Id: I44dee1306b5daca6f558c81b2b58252b35013e09
|
|
+ When the user attempts to block a number and they haven't migrated
to the framework blocking implementation, they should be shown a
dialog that asks them to migrate. This CL introduces the Dialog that
is shown and updates the Call log and Call details to open it.
+ As part one of the change, the Dialog is shown every time the user
attempts to block or unblock a number (when the feature is enabled).
A later CL will complete this migration step to ensure that the
dialog is only shown until migration is finished.
Bug: 26664600
Change-Id: Ia4c2d504f8d98679b90d232058eb5ee6ea9b38f1
|
|
+ Users are shown a dialog when they're running on an SDK which
supports the framework blocking solution, but they haven't yet
migrated. In order to determine whether the user has migrated or not,
a SharedPreference value is used. In a later CL which performs the
migration, this value will be updated as the final step.
Bug: 26664600
Change-Id: I5a12be643d0fb3b52ef408215779423bf0a2ddc7
|
|
+ When new filtering is possible, we should hide the add number
button from the blocked numbers management UI.
+ Added method to FilteredNumberCompat to check if it's possible to
use the new filtering implementation. This is needed because prior
to migrating to new filtering, users need to be able to unblock
numbers. Just checking the SDK version is not sufficient, we need to
know if the user has migrated their numbers.
Bug=26664600
Change-Id: I60433465074911f13a26736221ddacc9a8bbcf88
|
|
+ FilteredNumberCompat contains the logic needed to switch between
the Dialer implemented number filtering and the new number filtering.
+ Direct uses of the Dialer Filtering code should be replaced to use
the fields in this class
Bug=26664600
Change-Id: I42db3da4b5ed124a88488713f56ccab7b2290309
|
|
Now that we're no longer backwards compatible with Lollipop we don't
need CallAudioStateCompat. See ag/870962 for more info.
Bug: 26676586
Change-Id: I7c754d89a6c9e13bf5a004b7c5b15b88b9aff9ad
|
|
+ Needed to ensure that N sdk method calls aren't compiled into the
apk prior to the sdk launch
Bug=26542221
Change-Id: Iefc54caa5cb15758f011fc38c50c2ff1efa8c5c2
|
|
+ Add methods to TelecomManagerCompat
- Move TelecomManagerCompat to ContactsCommon because it is called
within ContactsCommon
- Move TestTelecomCallLogCache to the right package so tests pass
Bug: 25776171
Change-Id: I1963959292d8038ab505488d831afd06e6fef6d0
|
|
Bug: 25776171
Change-Id: Ib429e45f939db6fb0e3457467b95db3dab8fe6eb
|
|
The method was a system API pre-M, but a public method in M. Added a
compat method which checks if the method is callable. In the event that
the method can't be called, the compat method is a noop - this matches
the functionality from the L version of the phone.
Bug=25776171
Change-Id: I4a9fc19bb2bf2749d697da2b8643601ebd1eb4a8
|
|
ub-contactsdialer-b-dev
|
|
Added TelecomManagerCompat with methods necessary to start the InCallUI
without crashing.
Bug=25776171
Change-Id: I851f0252bdce9845e5211338637f16826479bc58
|
|
UserManager.isSystemUser() is not available pre-M, so we need to copy
over the logic.
Bug: 25776171
Change-Id: I8e7c8e7215a8b55009283ecb137cc54443e61ab8
|
|
Use alternative means or just return empty lists when calling methods
that require MSIM in pre-LMr1 devices.
Also move compatability checks to ContactsCommon for methods that may
be called in ContactsCommon as well as Dialer
Bug: 25776171
Change-Id: I074bb147dbd53d623f322482ad735391c84ae5ad
|
|
Bug: 25776171
Change-Id: Ia72b3d4a30783592f8894e0eaa890be7c60743ea
|
|
Only if the current sdk version is at least M, do we look up the
CACHED_PHOTO_URI
Bug: 25776171
Change-Id: I79ac81abb4da719ffdb5476476a9a28c287c95f6
|
|
call." into ub-contactsdialer-b-dev
|
|
Since TelecomManager was hidden in L, calls to getDefaultDialerPackage
will crash. Furthermore, default dialer was not even a concept in
Android <M so return false for the isDefaultDialer check.
Bug: 25776171
Change-Id: I05c9f55b69bdbe1e07cf44886dbff29d99f36bbb
|
|
SettingsCompat.System.canWrite returns true for versions older than M
because prior to M, permissions had to be granted prior to installing
the app. It's only in M and above that we check for permissions at
runtime.
Bug:25776171
Change-Id: Iee2250248223e7237f8eaa506b277e301e289cc0
|
|
For DialerCompatUtils first trick, add a function to check whether video
calling is compatible with the current version.
Bug: 25776171
Change-Id: I0d6c8181ec53f00785032ba52b484fb1c8e6ea47
|