This gives us some buffer time to help transition all the test apps.
See go/immutable-pendingintents for more context.
Bug: 160794467
Test: TH
Change-Id: I2265dc8a5e86ac76e615e659169f8891e8a7ed75
Refactored the PO provisioning logic out of Managed
Provisioning into a new SystemAPI,
this new API will now be called by MP
and CTS tests, allowing us to get rid of silent provisioning.
Most of the code in ManagedProfileProvisioningHelper has been
copied over from the MP tasks with slight modifications to
call internal methods instead of public APIs for example.
The main is difference is a newly added broadcast
ACTION_MANAGED_PROFILE_CREATED to notify MP to take a snapshot
of current system apps and cross profile packages.
Test: atest android.devicepolicy.cts.DevicePolicyManagerTest
Bug: 176973247
Change-Id: I3e234733f400e088a87fcc8b2985eafbb63ef539
Exported components that are not guarded by a signature permission
can receive Intents from any other app on a device. If an app unparcels
and launches an Intent from the Intent delivered to this unprotected
component then a malicious actor can potentially craft an Intent that
could launch hidden components, grant URI permissions, etc. This
commit adds a StrictMode check to report if a component launches an
Intent unparceled from the delivered Intent.
Bug: 160796858
Test: atest StrictModeTest
Change-Id: I763b8a965f91f5b433ce2f4b619e10ef12f5c296
Allows a caller to set the root task for the launching activity.
Bug: 176061049
Test: Existing test pass.
Change-Id: Id101ba8784c8e4151fa5958e6ec2e57e572f0e87
Until now, we showed the collapsed state of DecoratedCustomViewStyle in two different ways depending on the target of the app. In particular, we forced an awkward top line of views above the custom view for apps that didn't target S to ensure the context of the "subtext" was not lost from those notifications. However, that context is available on expansion, and we think it's better if all apps get the same, more visually consistent behavior, regardless of the targeted SDK.
Bug: 163626038
Change-Id: Ie50320566a97c8c05148857a6c4283a8870a833d
Test: manual
The RoleControllerManager takes a Handler for service connection
callbacks, and that Handler has to be a thread other than the main
thread inside system server because we need to block the main thread
before necessary permissions are granted via role.
However, since a recent change that exposed RoleControllerManager APIs
on RoleManager instead to hide this implementation detail from API, we
are creating the RoleControllerManager instance upon RoleManager
creation and implicitly initializing it with the main thread
Handler. This may result in the RoleControllerManager getting the main
thread handler instead of the desired foreground thread handler if
someone else in the system server created RoleManager first, and that
would create a deadlock when we block the main thread.
So revert to the original timing for RoleControllerManager creation by
creating it lazily, so that it gets the correct handler as the only
user of it inside system server is RoleManagerService, and other
services who only need the RoleManager won't affect
RoleControllerManager.
Fixes: 177251364
Test: manual
Change-Id: I649a23fa3b88fbd9120b3de408eee8a590d50a17
flag on creation.
This was previously a log.e, this change enforces this requirement
except when an app is under instrumentation.
See go/immutable-pendingintents for more context.
Bug: 160794467
Test: atest PendingIntentTest
Change-Id: I6506dd311f2e440ad74fdf4f5aa447ea471a02f4
Extends Service, not a base class of it.
Bug: 147564984
Test: build reference docs (m offline-sdk-docs)
Change-Id: Idf0a52d59062be36827e27eea076c744152a676c
Broadcast receiver ACTION_BOOT_COMPLETED, ACTION_LOCKED_BOOT_COMPLETED and
ACTION_PRE_BOOT_COMPLETED are temp allowlisted to start FGS for a duration
of 10000 milliseconds.
The temp allowlist duration can be changed by device_config command, for
example:
adb shell device_config put activity_manager boot_time_temp_allowlist_duration 10000
Bug: 175253292
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Change-Id: I0ff5b405b75a39a65ddb742382a970499ed6546b
Background:
* On organization-owned devices with managed profiles,
the work admin needs to be able to restrict
IMEs on the personal side.
* They should be able to restrict IMEs without having
visibility on the personal side. This is done by
introducing the ability for the admin to set the
permitted IMEs on the parent profile.
Changes:
* Update DPM permitted input methods apis to be
callable on the parent profile.
* Update RestrictedLockUtilsInternal to check the
permitted input methods on the parent profile
Manual test steps:
* Set up organization-owned device and download
IME apps on the personal profile
* Download TestDPC
* Select prefence Set input methods on parent
* Select allow only system IMEs and check Settings to see
all non-system IMEs are disabled.
* Select allow all IME apps and check Settings to see
no IME apps are disabled.
Bug: 170459562
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.settingslib.RestrictedLockUtilsTest
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testPermittedInputMethods
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testPermittedInputMethodsLogged
Change-Id: Iecd19adb6d3ca064a8d7f9ff0c1c41aa64bd6ace
1. add a "type" parameter to AMS.updateDeviceIdleTempWhitelist() which is
called by DeviceIdleController.
2. The default temp allowlist type is TEMPORARY_WHITELIST_TYPE_FOREGROUND_SERVICE_ALLOWED
which allows BG-FGS launch.
3. AMS.tempWhitelistUidLocked() already has a type parameter. Other API
to add temp allowlist can also add type parameter other than the
default.
Bug: 175244558.
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Change-Id: Ib42c445c15966bd260964782a7254ed2a7ffa405
Add a new extra for ACTION_SET_NEW_PARENT_PROFILE_PASSWORD which will
allow the flow to not enforce password requirement coming from the
profile side. This is to enable better password enrolment flow when
the DPC is guiding the user to enrol both a personal and work lock.
Bug: 169832516
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password
Change-Id: Idb33418f3e532dffc96ccb907f5cae0b6185173e
The initial APIs for ui translation. There is no implementation in
this change, we will implement it in the next CL.
Bug: 172969740
Bug: 176871912
Test: manual. build pass and build success.
Change-Id: I4ae0bc7a695076a87bed73e458396312d87f48c5
Test: atest StorageHostTest and also manually using StorageTestApp
to use the API and display the cache size.
Bug: 175016452
Change-Id: Iff0503c1643ee5fc501037e413aa4b5461ca3388
This is called from a GC handler hook in BinderInternal, from the
finalizer thread. It's a call from an app process into system_server. On
some devices, we observed this call taking a long time, causing
TimeoutExceptions on the finalizer thread.
Since this work is not critical, and when the GC runs is anyway
unpredictable, make releaseSomeActivities() oneway instead.
Bug: 118997212
Test: TH
Change-Id: I6b06917493a09a2fba63502c4bd1a203c184a62c
Merged-In: I6b06917493a09a2fba63502c4bd1a203c184a62c
This CL relaxed the UI context checks to only apply on UI related
APIs in WallpaperManager.
Test: build & run
Bug: 176958992
Change-Id: I390e865e31fde48bad6bbddb4203e4c997a1400a
This extra allows the provisioning initiator to determine
whether provisioning should be split into two (provisioning
part and DPC setup part) or be a single flow.
If set to true, it is the responsibility of the provisioning
initiator to resume provisioning. This is basically the
setup wizard.
Fixes: 177330679
Test: this extra will be testsed in ManagedProvisioning code
Change-Id: If8b301ef676bb8b15d974ddc898420978de08f84
