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
Added the property profilesystemserver in the RUNTIME_NATIVE_BOOT
namespace. This property is overrides the system one if it is
present.
Bug: 138851258
Test: set the property manually and verify that system server is started
Test: with profiling
Change-Id: Ifd69530e52a717a381b3f91b15a74329614906f2
To com.android.internal.compat.IPlatformCompat. This solves a java9
issue because libcore exported api has the same package android.compat.
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make framework
Change-Id: I0918344f670669cecb04f1e9e54dbcb471b587d5
This CL topic moves the default MimeMap implementation to frameworks.
Libcore starts with a minimal implementation sufficient to pass
CtsLibcoreTestCases, but frameworks can inject the real implementation.
Before this CL topic, the data files and logic (MimeMapImpl) were part of
core-*.jar on device; after this CL, they instead live in framework.jar.
Tests from MimeMapTest that check behavior of that default
implementation also move to a non-libcore CTS test.
Specifically, the logic and android.mime.types now live in
frameworks/base/mime. The default implementation is injected
into libcore from RuntimeInit. I chose to use a separate directory
(frameworks/base/mime/) and build java_library target ("mimemap")
in order to keep this as separate as possible from the rest of
frameworks code, to make it as easy as possible to factor this
out into a separate APEX module if we ever choose to do so.
Planned work for follow-up CL:
1. Make CTS more opinionated, with a plan to assert that all of
the default mappings are present. How exactly the expectated
mapping will be bundled in CTS is still TBD.
2. Add a vendor.mime.types file (defaults to empty) where vendors
can add additional mappings; I plan to make it such that mappings
in that file are parsed last but never override any earlier
mappings, as if each mime type / file extension was prefixed
with '?'.
3. Perhaps enforce that public APIs android.webkit.MimeTypeMap
and java.net.URLConnection.getFileNameMap() behave consistently
with MimeMap.getDefault().
Test: atest CtsLibcoreTestCases
Test: atest CtsMimeMapTestCases
Bug: 136256059
Change-Id: Ib955699694d24a25c33ef2445443afb7c35ed9e7
This CL adds a safeguard in ShareSheet to avoid calls to
AppPredictionService when the service is defined but is not available,
for example in the case of a wrong AiAi apk pushed from GooglePlay.
Bug: 138595943
Test: Manual test by removing the AiAi package from device
Change-Id: I4109c5122faa753d5111ee45698301cb6ccdd7b5
Simplifies the dismissal of the dialog, and allows for better
synchronization of when the client should receive the error. The only time
that BiometricService should dismiss the dialog is when authentication
is canceled due to another client, which is almost always due to
allowed-but-weird app behavior.
Bug: 135082347
Test: atest BiometricServiceTest
Test: atest BiometricDialogImplTest
Test: atest CommandQueueTest
Change-Id: I10daa798115e51af8a854759e30033c28e6636ba
The previous version didn't close its FDs for directories, and called
fsync() on the wrong FDs. To make sure a rename() is persisted, we
need to call fsync() on the FD of the parent directory, because file
names are stored in directory entries instead of inodes.
Also removed the need for dedicated native code by calling the Os
class directly.
Fixes: 139302541
Bug: 138866253
Test: presubmit
Change-Id: I67fe98811814acba5158d760766a2ef3b121225a
Optimizes PackageHelper#resolveInstallVolume to aggressively avoid
querying volume storage statistics unless absolutely neeeded.
The previous implementation queries storage data for each volume on the
device before evaluating which volume to select. The new implementation
defers querying storage stats for a given volume until it is absolutely
neccessary.
For example, if the application is already installed to a particular
volume, only that volume needs to be queried for available space.
In addition, querying for available space on a volume is done in two
steps. The first step does not take into account freeable cache; only
if this pessimistic assessment of available space fails do we call
installd to obtain cache information.
Bug: 138450974
Test: atest frameworks/base/core/tests/coretests/src/android/content/pm/PackageHelperTests.java
&& atest cts/tests/tests/os/src/android/os/storage/cts/StorageManagerTest.java
Change-Id: I403318de364d41019cb3d43e93b91cdd06fe1b9c
