This had to be called from native because serialization
was done from native, but now that serialization is in Java
we can move this back to a more logical place.
Also, this allows us to dump the per-UID proxy counts in
this situation again.
Bug: 109888955
Test: sailfish builds, proxy debug info shown on hitting limits
Change-Id: I4e06b3f93e30ed1c7868ec9e018709a7e796e441
To make some future refactoring easier.
Added some JavaDoc (mostly links to android.os.IBinder)
to make checkstyle happy.
Test: builds
Change-Id: If9dd6913868a34ea1e3d14fee1860a4ff368e06b
This method transforms a binder call code to a human readable name.
AIDL generator will have the ability to override this method.
Test: n/a
Bug: 111200705
Change-Id: Ic1d82e9b403ab40c8b625ca977a819ccd521dd97
The BinderProxy class is not thread-safe, and all calls into
it were serialized by holding gProxyLock from JNI code. More
recently, we've been wanting to access BinderProxy from Java
code directly, and having the lock in native complicated things.
This change removes the lock in native code and adds it in the
Java layer. A benefit of this change is that it reduces the
scope of where a lock is held. On the flip side, we no longer
have a cached BinderProxyNativeData object lying around. This
means we now allocate/free a BinderProxyNativeData even if we
already have a Java object lying around for the native object,
which can happen quite frequently. But we deem the impact of
this to be acceptable.
Bug: 109888955
Test: sailfish builds, boots, proxy warnings still show
Change-Id: If2f4dbe5486ec7af0ef8ea42d24ac3a4330cc05a
The goal is to figure out if it would be worth monitoring these
exceptions. If exception types are only caller issues like
SecurityException and IllegalArgumentException, it is probably not worth
it. If we can find NPE or internal exceptions it would be worth
uploading the exceptions through dropbox.
Test: unit test
Change-Id: I779d43a0e6ca1a33535b90809491675420a51726
Combination of moving to existing public API, tagging things as
@TestApi, and bringing utility methods into tests.
Bug: 13282254
Test: atest cts/tests/tests/os/
Change-Id: Ifd24c0d048d200e8595e194890cc1dc53ddc2b3e
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're reading data from credential
protected storage.
When a user is locked, credential protected storage is unavailable,
and files stored in these locations appear to not exist, which can
result in subtle app bugs if they assume default behaviors or
empty states. Instead, apps should store data needed while a user
is locked under device protected storage areas.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: Ia390318efa6fefda8f10ac684d0206e67aa1d3dc
We're almost out of bits, and we don't really need to smash both
thread and VM policy into the same 32-bit value, so use the lower
16-bits for each policy type and the upper 16-bits for penalty.
ActivityManager is only consulting the penalty bits, so we can
remove getViolationBit() and switch CTS over to doing instanceof
checks.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: I760e6a28f56da66dc75b7df9daf2167ff5bdff50
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're implicitly relying on
PackageManager filtering behavior.
For example, if the current Launcher isn't Direct Boot aware, we
hide it until the user is unlocked, which could confuse other Direct
Boot aware apps into thinking it had been uninstalled, which could
cause data loss.
This change helps apps track down places where they're implicitly
relying on the automatic filtering; they should instead carefully
choose a combination of MATCH_DIRECT_BOOT flags to decide on the
explicit matching behavior they want.
To implement this, we partially migrate the updateFlags() methods
out into ApplicationPackageManager, since the checking needs to
happen on the client side to correctly report StrictMode
violations. We don't currently mutate the flags, but we retain
the naming to keep that door open in the future.
Test: manual
Bug: 110413274
Change-Id: Iff6feba19da81ea1b4eeb3af821c3bdfbd9bf17c
Files on disk can sometimes contain content that should be redacted
based on the permissions of the remote caller. (For example, EXIF
data containing location information shouldn't be visible to apps
that haven't been granted the location permission.)
This class provides an easy way to "redact" ranges within an
underlying file, without the overhead of making a duplicate copy
of the file, or the limitations of returning a non-seekable FD.
Bug: 110228267
Test: atest android.os.RedactingFileDescriptorTest
Change-Id: I0b3b9f642573f6165e152e7568cdaf55f0af7134
In some situations, path could be null resulting
in a crash.
Test: no crash
Bug: 109730998
Change-Id: I2ce0410162d1327905d690331f461f9187e20906
(cherry picked from commit 6f6154bf04)
Work on issue #109754053: Implement tri-state location in platform
- New background location permission
- New (temporary?) API level for compatibility with old apps
None of this is exposed yet as a public API, that will be
done in the future.
Bug: 109754053
Test: atest FrameworksServicesTests:AppOpsServiceTest
Test: atest CtsPermissionTestCases:AppOpsTest
Change-Id: I986dc871b9e8ed3bf592d2546eadaefb4fefe099
The service and associated code is unused.
Bug: 80462439
Test: build / boot
Merged-In: Ibdfab1b7d2951a0c45e07bd47850af037990841b
Change-Id: Ibdfab1b7d2951a0c45e07bd47850af037990841b
The BinderProxy class is not thread-safe, hence all calls into it
must be serialized. This was achieved by holding the gProxyLock in
JNI code. However, a recent change added calls into BinderProxy
from ActivityManagerService without holding that lock, causing
ConcurrentModificationExceptions.
Instead of dumping debug info from AMS, make the call directly
from JNI, so we can make sure gProxyLock is held correctly.
Also, only dump on debug builds.
Bug: 71353150
Bug: 109701487
Test: sailfish builds, boots, info gets dumped with lowered limits.
Change-Id: I446a71ce4115b9936a01a170401ef98ba3818c0b
doclava was accidentally suppressing all these broken links
in @see tags. This CL fixes issues so we can start enfocing
checks for broken @see links.
Test: make docs
Exempt-From-Owner-Approval: Fixing @see javadoc link issues that are currently completely broken
Change-Id: I767e9fb9842494e5eccef2a7bdeee3877c488b5d
