Throughout the codebase, sometimes an integer user ID is called
userId, and sometimes it is called userHandle. Here, we rename the
occurences of "int userHandle" to "int userId" in select files.
Additionally, we add the @UserIdInt annotation in many more places.
This certainly does not cover all uses of userHandle, which is used
widely throughout Android; doing so would be more dangerous and cause
merge conflicts. But at least the core User code can have a consistent
nomenclature.
Bug: 138384792
Test: compiles. presubmit passes.
Change-Id: I9a2684e9bfac637e0476c4b68027008ebb8a160b
Make methods fully public, add documentation, swap what method is public
Test: make
Fixes: 139833596
Bug: 138589409
Change-Id: If39d6423efedcf8578dc2942274f6fbb341d164a
This reverts commit cfe38cdb1c.
The CL 8f712189dfc02285573337e2b4ab17678011db14 in libcore project avoids
the need for adding the new paths in LoadedApk. With the CL, a classloader
does not give up even when loader.findLibrary() has failed due to some
paths are not added to it. Instead, the classloader converts the given
libname into a filename (e.g. foo -> libfoo.so) then calls dlopen()
with the filename. The classloader reports failure only when the dlopen()
call has failed. Therefore, manually adding these paths to the classloader
is no longer needed and thus removed.
Bug: 109720125
Test: System.loadLibrary("adsprpc") is successful in Pixel (because
libadsprpc.so is in Pixel's vendor public lib list)
Test: atest cts/tests/tests/jni
Change-Id: I1970eba7e732728699042a36b89571915ec81451
This decouples the Split and Pinned stack resize flows. The
current goal is to prepare for a leashed resize implementation
for split-screen. For this to work, it needs to be clear
what actual logic belongs to the various docked resizing modes
vs what is for general stack resize or pinned resize. This
also enables PiP and Split to be worked-on in parallel.
As can be seen, general stack resize is actually not required
because freeform and fullscreen modes use task resize.
Bug: 119687367
Test: go/wm-smoke + related CTS
Change-Id: I9cca1910a18b87dda618235e89f2bdc582086f34
Move all of the usage stats data from the regular system storage to
the system CE (credential encrypted) storage.
All events being reported while the user is locked will be stored
in memory and will be processed via the handler after the user is
unlocked. All of these events reported will regularly be persisted to
system DE storage to ensure important events are not lost.
Any query requests will be ignored while the user is locked.
Two new usage events have been added: one to indicate the user has been
unlocked and the other to indicate the user has been stopped.
Also updated documentation for APIs in UsageStatsManager to reflect the
new behavior in R when the user is locked.
Bug: 135484470
Test: atest android.app.usage.UsageStatsTest#testDataIsInCe
Test: atest android.app.usage.cts.UsageStatsTest#testUserUnlockedEventExists
Test: atest android.app.usage.cts.UsageStatsTest
Test: atest UsageStatsDatabaseTest
Change-Id: I18da1a9354b6686472972c5f2304e4c19e28307f
If private user data is send to an app the data provider should note an
app-op. This change adds a new API AppOpsManager#setNotedAppOpsCollector
that allows an app to get notified every time such an private data access
happens.
This will allow apps to monitor their own private data usage. Esp. with
big, old apps, distributed teams or 3rd party libraries it might not always
be clear what subsystems access private data.
There are three different situations how private data can be accessed and
an app op is noted:
1. Private data access inside a two-way binder call.
E.g. LocationManager#getLastKnownLocation. When we start a two way
binder transaction, we remember the calling uid via
AppOpsManager#collectNotedAppOps. Then when the data providing code
calls AppOpsManager#noteOp->AppOpsManager#markAppOpNoted the noted
app-op is remembered in
AppOpsManager#sAppOpsNotedInThisBinderTransaction. Then when returning
from the binder call, we add the list of noted app-ops to the
reply-parcel via AppOpsManager#prefixParcelWithAppOpsIfNeeded. On the
calling side we check if there were any app-ops noted in
AppOpsManager#readAndLogNotedAppops and then call the collector while
still in the binder code. This allows the collector e.g. collect a stack
trace which can be used to figure out what app code caused the
private data access.
2. Very complex apps might do permissions checks internal to themself.
I.e. an app notes an op for itself. We detect this case in
AppOpsManager#markAppOpNoted and immediately call the collector similar
to case (1).
3. Sometimes private data is accessed outside of a two-way binder call.
E.g. if an app registers a LocationListener an app-op is noted each time
a new location is send to the app. In this case it is not clear to the
framework which app-action triggered this app-op-note. Hence the data
provider has to describe in a AsyncNotedAppOp object when an why the
access happened. These objects are then send to the system server via
IAppOpsService#noteAsyncOp and then the collector in the app. There are
rare cases where a private data access happens before the app is running
(e.g. when a geo-fence is triggered). In this case we cache a small
amount of AsyncNotedAppOps (in AppOpsService#mUnforwardedAsyncNotedOps)
and deliver them when the app is ready for these events (in
AppOpsManager#setNotedAppOpsCollector).
Test: atest CtsAppOpsTestCases (includes new tests covering this
functionality)
Bug: 136505050
Change-Id: I96ded4a8d8d9bcb37a4555d9b1281cb57945ffa9
To prepare for enabling MissingNullability Metalava check this CL
works on adding missing nullability issues that metalava flags if
we tell it to flag new things since API 29.
This is not a complete CL, mostly addresses public api and
toString/equals for @SystemApi
Exempt-From-Owner-Approval: Large scale nullability clean up
Bug: 124515653
Test: make -j checkapi
Change-Id: I109260842cfc25f06e40694997fcbb4afa02c867
...rather than relying on in-app code to perform the shutdown.
Bug: 128649910
Test: manual
Test: atest OsHostTests#testForegroundServiceBadNotification
Change-Id: I94d9de50bb03c33666471e3dbd9c721e9278f7cb
Bug: 139458376
Allows tests to increace the exit transition timeout so that
cloud devices don't finish before the exit transition completes.
Test: ActivityTransitionTest
Change-Id: Ib94086f5ab06ff8172b80b26260e41158d428b0c
The bugreport API uses newly added enum for bugreport options
(example: BugreportParams.BUGREPORT_MODE_FULL). So, now we need to
maintain and keep in sync both of these enums as requestBugreport will
use the bugreport API; Need to move towards one enum for bugreport
options.
Currently, the caller of requestBugReport(int bugreport) needs to know
the underlying enum for the bugreport it is requesting. Instead of
changing the enum logic at the caller of requestBugreport(), create
wrapper functions for specific bugreports.
Bug: 137825297
Test: Builds
Change-Id: I62a58511867624f9662287ee39f78a31ff9cd765
Since ActivityGroup logic has been deprecated, it does not make sense to
maintain related APIs in Activity. Deprecate them and make developers
to use fragment APIs or APIs without fromChild suffix version.
Bug: 137825207
Test: build, flash and presubmit
Change-Id: Ia0b6e78079efd4734cacc52bf2c708f628ef323b
The onSharedPreferenceChanged listener will now also be called on
Editor#clear with a null key.
This change is gated behind a flag using the new app compat framework.
Removed the OnSharedPreferencesClear listener interface.
Bug: 119147584
Bug: 138293946
Test: atest android.content.cts.SharedPreferencesTest
Change-Id: Ieea168eb40afb8f1b5830f1541be20d93d6f94b5
Settings doesn't actually need to know whether an application
qualifies for a role, but only whether the default app setting should
be visible for an application. Qualification and visibility differs in
cases such as FallbackHome inside Settings which is a qualifying home
activity but should never be shown in default apps UI.
Fixes: 138636320
Test: manual
Change-Id: I216195c64a7b106e2769b11c1a998741a77fdce2
At the moment isActivePasswordSufficient() can return stale result
immediately after a password change since the latest password metrics
information is pushed from LSS to DPMS asynchronously (this is to
avoid deadlock between LSS and DPMS due to lock inversion). Fix this
by moving the password metrics ground truth to LSS, and make DPMS
query LSS about the password metrics when needed.
Bug: 37090873
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: atest com.android.server.locksettings
Test: atest DeviceAdminHostSideTestApi24#testResetPassword_nycRestrictions
Test: atest DeviceAdminHostSideTestApi24#testRunDeviceOwnerPasswordTest
Test: atest MixedManagedProfileOwnerTest#testPasswordQualityWithoutSecureLockScreen
Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest MixedManagedProfileOwnerTest#testPasswordSufficientInitially
Change-Id: Ib1d1716024b8a6a6554afdb4ee9824d457ed8308
These operations are used by MediaProvider when checking and noting
interactions with specific media types on the device.
Bug: 137890034
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Id452ad121bd8a0b7c1c337a2b7fe030135a9d776
We already have startOp() and finishOp() to provide a mechanism to
mark an operation as being "active". This change publishes a set of
APIs to check the status of these active operations, matching the
naming of similar existing APIs on the same class.
Bug: 139128842
Test: atest com.android.server.appop.AppOpsActiveWatcherTest
Test: atest android.media.cts.AudioRecordAppOpTest
Exempt-From-Owner-Approval: trivial API refactoring
Change-Id: I9fb381d748ff23ff24dd363ed5b117bd661793ab
These are all pieces of data apps could get anyway;
these are code nice-to-haves to reduce code replication
Test: make
Bug: 122138479
Bug: 138589409
Change-Id: Ie8ffacb6c28840f779c68f7aa95f1405e70f5ce5
