Add a DeviceConfig feature that denotes a list of apps we want to force
into scoped storage. This would allow us to test these apps behaviours
under scoped storage at scale.
Also add the feature to StorageManagerService#dump.
Test: manual:
$ adb shell device_config put storage_native_boot forced_scoped_storage_whitelist <pkg>
$ adb reboot
$ adb shell dumpsys appops --package <pkg> # observe LEGACY_STORAGE
mode=ignored
Test: adb shell dumpsys mount
Bug: 151735608
Change-Id: I6a43e987ebf8d14fb64103a74bafde28f5863ae2
The actual cache clearing is not async anymore, so we can report the
status to the calling app. Here, we just change the documentation to
make the caller aware of the 3rd possible activity result: EIO.
This value is returned if an error happens while MediaProvider is
clearing the cache. In this case, we don't know how much of the cache
was deleted, if at all.
Test: build
Bug: 155290762
Change-Id: I3a04a9b5b6b07c6ec61e97a4cb0d3bc8b10b0370
isUserUnlocked and isUserUnlockingOrUnlocked share the same service-side
dependencies, so we can add a cache to the client-side of transaction
and hook into the isUserUnlocked cache invalidation infrastructure.
Bug: 140788621
Test: atest CtsMultiUserHostTestCases while validating cache operations.
Change-Id: Icf11b1e777936ec9922ce4a47f8cfccbd22ad5ef
Since as of R, apps can no longer query other apps by default,
deprecate the isUserAGoat API's undocumented behavior and
always return false.
Fixes: 156543788
Test: atest CtsMultiUserTestCases
Change-Id: I9743d87b762aabb01dc010ba6d5a6c01643a1f92
The referenced object could be destroyed and result in native crash when
mCallback is used.
Bug: 156536687
Test: manual test with registering a section from an app
Change-Id: Ie36c0e6e64be1246539f12999f037c24377686dd
These UserRestrictions' caveats actually apply to the
admin user, not the primary user, so we update the
documentation accordingly.
Bug: 132720870
Bug: 132719585
Test: none; it's just documentation
Change-Id: I9828136fe25537a1065423245fb0706520bf7480
When creating admin users, default
UserRestrictions do indeed apply, so updating
the javadoc.
Test: N/A
Bug: 143491938
Change-Id: Id495599abd4ddee100ca2c761d3b420fff315482
Fix a potential race condtion when the same message object
is being enqueued by two threads.
Bug: 150263007
Bug: 154867444
Test: atest android.os.cts.MessageQueueTest
Change-Id: Id79448ba8719479cbdb054f2cdd172fdcbe86d47
(cherry picked from commit 96a6fec4d6)
Background
* Secondary users should be disabled
when the device is an organization-owned
managed profile device.
* This is because supporting secondary
users would complicate the semantics of
user restrictions.
Changes
* Add DISALLOW_ADD_USER as a base restriction
when the device is an organization-owned
managed profile device.
* Handle removal case when the device is no
longer in this mode.
* Remove the ability of other admins to apply
DISALLOW_ADD_USER.
Manual Testing Steps
* Provision an organization-owned managed
profile device.
* Check Settings > System > Multiple users
and verify that a user cannot be added.
* Check WP TestDPC 'Set user restrictions
on parent' and verify 'Disallow add user'
is not present.
Bug: 155281701
Test: Manual testing
atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I83348fc8b854cef20383803124000540b5b130cb
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
An earlier CL with benchmarks has shown that sending strings as UTF-8
is 50% faster for US-ASCII strings, and still 68% faster for complex
strings referencing higher Unicode planes. (So an improvement in
both cases!)
Since code across the OS still makes heavy assumptions about Parcel
strings typically being UTF-16, we need to carefully migrate
Parcelables by hand, which is what this CLs begins doing.
Bug: 154436100
Test: manual
Change-Id: I9a675473e0ce3a4a5c5e305dd851b40bb1560e1c
ServiceSpecificException might be thrown, but it is not
actionable by the caller. Hence hide the comment.
Fixes: 151156841
Test: none
Change-Id: I07836fe2c5cc361fa81f6fc24851ad2b0721591b
(cherry picked from commit d3abb6d385)
Merged-In: I07836fe2c5cc361fa81f6fc24851ad2b0721591b
We cache the reference to the HAL and use a DeathRecipient to keep track
of whether it's still good.
Adds waitForService and waitForDeclaredService to the ServiceManager
Java implementation because they were missing.
Test: atest LightsManagerTest
Test: atest LightsServiceTest
Bug: 152509747
Bug: 154631113
Bug: 154627432
Bug: 154629168
Change-Id: Ife8471f3a7e47b48bb31015ddf40f1d7fef6240f
- Calling app needs the intent from platform to show UI safely without interfering the bugreport/screenshot generation.
- Currently IncidentCompanionService can only send the intent to app of personal profile when there is work profile.
- But calling app may be from work profile.
- So change to use BugreportManager to send the intent to calling app.
BUG: 153809412
Test: Flash, press bugreport shortcut and confirm calling app of work profile can receive the intent.
Change-Id: I45b2b7ab8e017ba93c1e71ad53f4aa3607af9106
* changes:
[incfs] Cleanup storage creation and don't use temp directory
[incfs] Notify IncrementalService about system startup later
[incfs] Fix bad path::join() path preparation
Recently while investigating some Binder limits, I discovered that
we're still sending Strings across Binder as UTF-16, which is very
wasteful for two reasons:
1. The majority of data flowing through APIs like PackageManager is
already limited to US-ASCII, and by sending UTF-16 we're wasting
half of our transactions on null-byte overhead.
2. Internally ART is already "compressing" simple strings by storing
them as US-ASCII instead of UTF-16, meaning every time we want to
write a simple string to Binder, we're forced to first inflate it
to UTF-16.
This change first updates Parcel.cpp to accept char* UTF-8 strings,
similar to how it accepts char16_t* for UTF-16. It then offers
both UTF-8 and UTF-16 variants to Parcel.java via JNI. We also
update the String8 handling to behave identical to String16.
This change adds benchmarking to show that these new methods are
about 50% faster for US-ASCII strings, and about 68% faster for
complex strings that reference higher Unicode planes. (So an
improvement in both cases!)
Bug: 154436100
Test: atest FrameworksCoreTests:ParcelTest
Test: make core-libart conscrypt okhttp bouncycastle vogar caliper && vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/ParcelStringBenchmark.java
Change-Id: I22a11d3497486d922ec8e14c85df66ca096b8f2a
Since they don't support quota. Also, don't throw an exception if we
can't find a volume for the passed-in path, but warn instead: the volume
may be unstable and have disappeared by the time we do this.
Bug: 152618535
Test: boot emulated image; verify no crashes when inserting media on
public storage
Change-Id: I0e6b8f5c9f9f35b80b7bd5f6255a70e210a30474
Use the existing maxAmplitude and gamma adjustment values to apply the
relative scaling of default vibration intensity settings and user
settings on top of the PrimitiveEffect#scale value.
As a consequence, the relative scaled amplitude of a OneShot or Waveform
vibration effect should match the scaled PrimitiveEffect#scale value.
Fix: 154089649
Test: atest FrameworksCoreTests:VibrationEffectTest
Change-Id: I3ca0042a42675289a2ed8110c9dc3798055ebf4a
To have a way to verify behavior of more directories, mark more
directory getter APIs @TestApi.
Bug: 148664742
Test: atest SysConfigTest#testStageWhitelist
Change-Id: I2d22412935b24ec4c33d8d1b3a7fbb7df4a08841
For incremental installations only, we skip the verification
request broadcast and instead always send a verified broadcast
with the root hash.
Bug: 151240337
Test: Manual. Install APK normally and see the verifier request broadcast is sent
Test: Manual. Install APK incrementally and see verifier request broadcast is not sent, and verified broadcast is sent with root hash
Change-Id: I2599472818b63ea172d2d412741e5540c8a52176
Define new atoms to better log and understand various user journeys,
such as user switches, user starts, and user creation.
The UserLifecycleJourneyReported atom defines a user's journey and
holds a user's information such as their user id, user type, and flags
associated with the user. This atom includes a session-id which is used
to link to the UserLifecycleEventOccurred atom which keeps track of
lifycycle events that occur throughout a user's journey. As more user
journeys are defined, there could be more Events added in the future.
Note: the JourneyReported atom can currently be logged more than once
per user journey since there is no record of the user's ongoing journey.
This will be updated in a future CL.
Bug: 146505521
Bug: 150788910
Test: statsd_testdrive 264 265
Change-Id: Iff3847be64d718fb2ec17e58c33d47f7fa4b627a
