If the device or profile owner have set a max password failed
attempts policy, the device or profile should be wiped even if
DISALLOW_FACTORY_RESET / DISALLOW_REMOVE_USER /
DISALLOW_REMOVE_MANAGED_PROFILE was set by that admin. However
it should still fail if another device admin set the policy - this
is in line with what wipeData() does at the moment.
Bug: 34450538
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerPlusManagedProfileTest#testWipeData
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.ManagedProfileTest#testWipeData
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testDisallowFactoryReset
Change-Id: Ifac240692ce74432f7b57f3dfbbbac2a7282297b
- DEVICE_OWNER_CHANGED is an event that could happen maximum of 2 times
after device factory reset. The event rarely
happens, and it shouldn't affect any system health
Fix: 34446573
Test: adb shell am instrument -w -e class
com.android.server.devicepolicy.DevicePolicyManagerTest
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Ic1af2016f590e1200bb3e56f63caa0e0b12f71f8
The DevicePolicyManagerService currently supports delegation of
certificate installation and application restriction management, both
of which are individually handled by DPMS.
Upcoming framework features will add four more delegation types,
namely: block uninstall; app permission management; app access
management; and system app enabler. At this moment it makes sense to
refactor the underlying delegation system in DPMS so that current and
future delegates can be handled in a more generic way.
Bug: 33099995
Test: DPMS unit tests
Change-Id: I9e350143572c6690febdd59d1ed5149af8ee4388
Make the multiprocess WebView enabled by default. It can be disabled by
the user in developer settings, but will be re-enabled after the WebView
implementation is updated to keep people testing it.
Bug: 21643067
Test: verify that WebView is enabled by default in developer settings
Change-Id: I100dac6b4d3784678a694352faa6e9fb2fc72078
Implement logic to track the version on which the user last manually
enabled/disabled multiprocess (by storing the version code in the
setting, negated for disabled). This enables us to have the following
logic:
1) If multiprocess is enabled by default, re-enable it for users who
turned it off on a previous version, but leave it off for users who
turned it off on the current version. This lets us collect fresh
bug reports after fixing previous issues.
2) If multiprocess is disabled by default, leave it on for users who
have enabled it manually, but turn it back off for users who were
just relying on the default.
This CL leaves it set to "disabled by default" so there is no immediate
behavioural change, but this enables us to switch the "enabled by
default" flag back and forth freely later.
Bug: 21643067
Test: run WebViewUpdateServiceTest
Test: manually upgrade/downgrade webview, verify behaviour of setting
Change-Id: Ibbecac7e5ee75e9c4a1b6efb84253ace98d1eb1a
This CL adds reverse and seek to AnimatorSet's capabilities.
Structural changes:
1) Child animators are now being pulsed by AnimatorSet in a more
timeline manner, as opposed to the old listener based style.
This timeline based approach avoids the time offset in between
sequential animations, and therefore produces a more accurate
overall duration.
2) Timeline is done by representing start and end of each child animator
in two separate events. All the events are then sorted based on the
time they happen, such that it's clear what should happen in between
last frame and the new frame (i.e. which animations should start
or end).
Test: CTS (in the same topic branch)
Bug: 30993532
Change-Id: If1dc6e8dbc93a4bf5ade8c5b0dcf43d3ee6ba7b5
Plug a memory leak in AssetManager::createIdmap.
Bug: 31052947
Test: use Valgrind and dummy native app
Change-Id: I83af3a40516ed2d50d5a7c8ee175ed960fde9933
Add an installd command to remove an idmap file. This is the inverse of
the 'idmap' command and is intended for clean-up once an idmap file is
no longer needed because an APK was removed, etc.
This commit depends on a corresponding commit in frameworks/native (with
the same Change-Id).
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: Iae19a519803f0c172b02a32faa283ef36f43863c
This adds a new public API for attesting the device's hardware ids
(e.g. serial number and IMEI).
Bug: 34597337
Test: CTS CtsKeystoreTestCases and GTS DeviceIdAttestationHostTest
Change-Id: I2e9c1b4f8eb24afa4a09c71c137ce33a6b87eb27
Implementation of sensor direct report API. In this verison, only
ashmem(MemoryFile) backed direct channel is implemented. Support
of HardwareBuffer class will come in a following CL.
Test: tested with demo app
Bug: 30985702
Change-Id: I29cae5cb2615c7a128fe203ed1545c03010ca4aa
Min priority notifications are now greyed out and in an
even smaller form-factor then before.
Test: add low-priority notifications - observe visuals
Bug: 34469375
Change-Id: I3ce2cbf22dbc3276ac738224a16c1b10165964f3
Test: updated CTS test to check for error conditions if the blob dimensions are
bad.
Bug: 34050596
Change-Id: I3ec6e7a43dae8d0ac2b2d04bc4b38cd3c12f8390
Apps can now declare in their base APK AndroidManifest.xml
that they want to have their split APKs loaded in isolated
Contexts. This means code and resources from the split
get loaded into their own ClassLoader and AssetManager.
<manifest xmlns:android="..."
...
android:isolatedSplits="true"
...
In order to make this more useful, splits can declare dependencies
on other splits, which will all get pulled in to the Context
and run as expected at runtime.
A split declares its dependency on another split by using the
tag <uses-split> in its AndroidManifest.xml:
<manifest xmlns:android="...">
...
<uses-split android:name="feature_split_1" />
...
A split can have a single parent on which it depends on. This is
due to the limitation of having a single ClassLoader parent.
All splits depend on the base APK implicitly.
PackageManager verifies that no cycles exist and that each dependency
is present before allowing an installation to succeed.
The runtime will then load splits based on the dependencies.
Given the following APKs:
base <-- split A <-- split C
^----- split B
If an Activity defined in split C is launched, then the base,
split A, and split C will be loaded into the ClassLoader defined
for the Activity's Context. The AssetManager will similarly be loaded
with the resources of the splits.
A split can be manually loaded by creating a Context for that split, defined
by its name:
Context.createContextForSplit("my_feature_split_1");
All installed Activities, Services, Receivers, and Providers are accessible
to other apps via Intent resolution. When they are instantiated, they are
given the appropriate Context that satisfies any dependencies the split they
were defined in stipulated.
Test: WIP (CTS tests to come)
Change-Id: I8989712b241b7bc84381f2919d88455fcad62161
Activity manager now has constants, starting with two: bg check
and process limit.
Power manager now has constants, starting with one: controlling
disabling of wake locks from cached processes.
Test: manual
Change-Id: I05db42e2104e9d31584f85251412df2d5efb34b6
