ART will refuse to load on-device generated artifacts if odsign
verification status suggests files have been tampered with.
Bug: 180949581
Test: manual
Change-Id: I772b5b7b191310bf7c7797161a304a1ab6f53c5e
Add a new header library, libandroid_runtime_threads_headers,
that exposes javaAttachThread / javaDetachThread.
Also change the return value from int to bool, since the client
may not know about JNI_OK.
Test: boots
Bug: 190450693
Change-Id: Ifedd34a8c8a1847d89c9f2f7919ff7e4b13b7446
This reverts commit 516cb2d025.
Reason for revert: Add back after merging f2fs/f2fs-tools changes removing immutable bit stuffs
Bug: 188928405
Change-Id: I6a6fcde1190bff14abe1a67a75b8e7be95d89072
This reverts commit e41b029d85.
Reason for revert: b/189985437
com.android.tradefed.targetprep.TargetSetupError[APK_INSTALLATION_FAILED|520001|DEPENDENCY_ISSUE]: Failed to install com.android.devicehealthchecks with ...
Change-Id: I06fe7d94f6dab474c74b093de8692f08d4031b62
Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: (added tests for speech reco)
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Merged-In: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Modern f2fs implementations starting in S support compression
natively within the file system. The data blocks of specific
installation artifacts [eg. .apk, .so, ...] can be compressed
at the file system level, making them look and act like any
other uncompressed file, but consuming a fraction of the space.
However, the unused space is not free'd automatically. Instead,
we must manually tell the file system to release the extra
blocks [the delta between the compressed and uncompressed block
counts] back to the free pool.
Because of how compression works within the file system, once
the blocks have been released, the file becomes read-only and
cannot be modified until the free'd blocks have again been
reserved from the free pool. For these installation artifacts,
that is not a concern.
Test: atest CtsAppSecurityHostTestCases:SplitTests
Test: atest CtsAppSecurityHostTestCases:IsolatedSplitsTests
Test: atest CtsAppSecurityHostTestCases:PkgInstallSignatureVerificationTest
Test: atest CtsLibnativehelperTestCases
Test: atest PackageManagerTests
Test: Manual. Boot the device and see cblocks for stub APKs are released
Test: Manual. Disable and re-enable stub APK and see cblocks are released
Bug: 188928405
Change-Id: I4b29dab263d02a79d7b1593d35ae28101d33679a
When tunnel mode is being used (meaning when there
is a sideband stream in one of the layers in SurfaceFlinger), the
blur can't be computed over that layer. In that case, SF blurs are
disabled, which results in a translucent buffer to be drawn.
This CL introduces a listener, which is registered with the
SurfaceFlinger and receives a callback whenever the tunnel mode
enabled state changes. This way, the BlurController can properly send
updates to apps that blurs are disabled/enabled.
Bug: 171457637
Test: atest TunnelModeStateListenerTest
Test: atest TunnelModeStateReporterTest
Change-Id: I6ffba1c342352ad65a32c0efc4ecbc07811245d9
This allows us to collect Java Heap Profiler data directly without
needing to set the flag similar to PerfettoHprof.
Test: Passing Tests
Local Testing
Bug: 160214819
Change-Id: Id4888107c7b12f076de8237fd42bab49319566b5
this property is deprecated and emulator now
populates `dalvik.vm.checkjni` to use instead.
Bug: 182291166
Test: getprop dalvik.vm.checkjni
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Ie94b0d6c2e48b731d9cfe0ead380e0f52f662f37
In order to detect memory regressions caused by improper handling of
dma-buf buffers we need to measure how this memory is used.
This change:
- Introduces DmabufInfoReader which wraps libmeminfo and provides
per-process DMA-BUF stats.
- Specifically, measures buffers mapped to the process address space
(from /proc/pid/maps). This is supported on all devices.
- For devices running 5.4+ (where the system processes can query fdinfo)
also measures the total retained memory (either by mmap or an open fd).
- Introduces a statsd atom that collects this for all running managed
processes. Non-managed processes will also hold dmabufs, but the
likelihood of them causing issues (post-launch) is smaller so I am
trading them off for cheaper collection (if indeed we encounter such
problems, they will definitely be caught by the total dmabuf counters).
Test: manual
Bug: 183708249
Change-Id: I5e0ef58ac1a66ebe2d280c5733de46ba84f75a46
Instead of compiling framework-connectivity source into
frameworks-minus-apex, have the APIs loaded separately from
framework-connectivity.
Bug: 171540887
Test: device boots, has connectivity
Change-Id: I8f07ff2082c3de80821e121807e66a43a870de7b
... by switching from packageName/uid/pid to the Identity class.
This allows up to track which parts of the app trigger audio-recordings.
Test: atest CtsAppOpsTestCases
CtsNativeMediaAAudioTestCases
Fixes: 160150145
Change-Id: I0913a336a862e4a1cb38b9d967cfbdc490513ab0
1. When mmaping {.art, .odex, .vdex} files madvise them to
MADV_WILLNEED
2. Add system properties to limit the madvise size/range
Test: presubmit
Bug: 178853586
Change-Id: I7bd882e3e1021d48f00f297c4dd1d5a8098c087d
Do not return to Java mode between consecutive fork operations.
This greatly reduces the Zygote overhead, since we no longer need to
stop and restart Java daemons.
By not switching back to Java mode, and being careful about what memory
we touch between forks, we also keep the Zygote heaps much more stable,
facilitating page sharing between the zygote and all its children.
Under normal operation we should no longer allocate any memory in the
zygote between forks. That applies to both the Java and C++ heap.
This makes the zygote behave much more like the mental model many
of us had assumed: It has nearly constant memory contents, which are
copy-on-right cloned at each fork. This does not apply to the initial
system server and webzygote forks, that are currently still handled
differently.
This includes
1. Add ZygoteCommandBuffer, and switch the argument parsing code to use it.
This slightly reduces allocation and enables (3).
2. Support process specialization in the child, even when the arguments
are already know, Leverages existing Usap code.
3. Add support for forking multiple child processes directly to the
ZygoteCommandBuffer data structure. This directly uses the buffer
internals, and avoids returning to Java so long as it can handle the
zygote commands it sees.
FUNCTIONALITY CHANGE:
We now limit the total size of the zygote command, rather than the
number of arguments.
Initial performance observations:
[ These are not perfect, since I'm comparing to numbers before I
started. There may have been other moving parts, but they should be
minor. ]
System-server-observed launch latency:
[Not the best metric, but easy to measure. In particular, this
does not represent a significant reduction in application launch
time.]
Based on measuring the last 10 launches in a lightly used cf AOSP
instance, the system server latency from requesting an app launch to
response with the pid (which does not require the child to execute
anything) went from an average of about 10.7(25) msecs to 6.8(9) and
7.9(16) in two tries with the CL. (The parenthetical numbers are
maxima from among the 10; the variance appears to have decreased
appreciably.)
Dirty pages:
The number of private dirty pages in the zygote itself appears to have
decreased from about 4000 to about 2200. The number of dalvik-main
private dirty pages went from about 1500 to nearly zero.
Initially ART benchmarking service claim -1.88% in PSS. But this is not
consistently repeatable.
Drive-by fix:
Call setAllowNetworkingForProcess on usap / native loop path.
Bug: 159631815
Bug: 174211442
Test: Boots AOSP
Change-Id: I90d2e381bada1b6c9857666d5e87372b6a4c1a70
There is a demand to use VerityUtils outside of services from core. This
allows the class to be used from both places.
Bug: 180414192
Test: m
Change-Id: I8da2e3df218547208799a238eab2d54545194d00
Enable consistent Jpeg output support for all present camera
extensions. Extensions with exclusive YUV_420 support will
include an extra SW encoding pass before the processed results
can be queued back to the client surface.
Bug: 179818844
Test: Camera CTS
Change-Id: I461e54024f150925ca1a5a57ff7b327712ce0e96
Hidden api for exposing the fps counter to WM Shell, so that the fps for
a task can be reported.
Bug: 174956756
Test: E2E integration with SurfaceFlinger for angry birds
Change-Id: I9818aded2755ad07fd3abf3f616e8e6940bad268
Move the check whether CPU eBPF tracking is supported to one place to
avoid repeating it in every reader.
Bug: 179485697
Test: existing tests pass
Change-Id: Id6d23614c3d1dde86b66de14bc09f5976f183625
Total CPU time in state added in https://r.android.com/1538886.
Bug: 174245730
Test: cmd stats pull-source 10095
Change-Id: I6cd27ac172e36d2e889429808bd4bd583795d7c9
NetworkUtils is planned to move to a dedicated JAR for connectivity
classes, while NetworkUtilsInternal would stay in the
frameworks-minus-apex JAR, in the com.android.internal.net package.
Bug: 171540887
Test: m, boots, wifi working
atest FrameworksNetTests
Change-Id: I3d38d72ad23a4bf84af823c7baeb6fed25c0665f
Internally String.getBytes() calls libcore.util.CharsetUtils methods
for a handful of common charsets, but that path requires new memory
allocations for every call.
This change introduces alternative versions of those methods which
attempt to encode data directly into an already-allocated memory
region. If the destination is to small, callers can detect and pivot
back to calling String.getBytes().
The included benchmarks reveal these raw performance improvements,
in addition to the reduced GC load which is harder to measure:
timeLocal_LargeBuffer[simple]_mean: 424
timeLocal_SmallBuffer[simple]_mean: 511
timeUpstream[simple]_mean: 800
timeLocal_LargeBuffer[complex]_mean: 977
timeLocal_SmallBuffer[complex]_mean: 1266
timeUpstream[complex]_mean: 1468
Bug: 171832118
Test: atest CorePerfTests:android.util.CharsetUtilsPerfTest
Test: atest FrameworksCoreTests:android.util.CharsetUtilsTest
Change-Id: Iac1151e7cb8e88bf82339cada64b0936e1a7578b
For now, the native implementation is identical to the
Java implementation. The performance improvement is ~20%
in a microbenchmarks.
Bug: 169279846
Test: atest FrameworksCoreTests:com.android.internal.os.KernelSingleProcessCpuThreadReaderTest
Change-Id: I8685a7f0adf9476209e29bb3ee3e89e99f66fa95
