The following changes in UserManager are required for ongoing
improvements to CTS/GTS infrastructure.
- Exposed the following as testAPIs:
* isGuestUserEphemeral
* createUser
* preCreateUser
* createProfileForUser
* createRestrictedProfile
* getUsers
* getUserType
- Added permissions to the following APIs:
* CREATE_USERS for getUserName
* INTERACT_ACROSS_USERS for getProfileParent
- Added CREATE_USERS permission to the documentation of
getUsers and the APIs that call it.
Test: Confirmed that a CTS test can call these APIs
Bug: 178695365
Change-Id: Id9105db3bfefb926139715b728acedefd2a5ca3e
Creates presubmit test mapping for BatteryStats-related
files.
These tests can be run manually via
atest FrameworksServicesTests:com.android.server.am.BatteryExternalStatsWorkerTest FrameworksServicesTests:com.android.server.am.MeasuredEnergySnapshotTest FrameworksServicesTests:com.android.server.am.BatteryStatsServiceTest FrameworksCoreTests:com.android.internal.os.BatteryStatsTests
Tests that currently fail are marked to be skipped;
they should be addressed by b/180015146.
This is accomplished by introducing a new annotation, @SkipPresubmit.
Test: treehugger presubmit
Bug: 180016384
Change-Id: If01beaa342468aeded660e5766a14391d3ee9bcc
As ARC is moving from a container to a VM based solution, change the
build method to detect this.
Bug: 139490365
Test: Check that VM works after pushing to device: run play store,
install app.
Change-Id: Ic91a7e5c9a36242d2c905cecffeec72acba8ff45
(cherry picked from commit 2f78de6d0e1428d959f97ea0dd0e3c9c28b6e3fb)
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
Add information about value returned by Vibrator.getId, including a
description of what the default -1 value represents.
Fix description of CombinedVibrationEffect arguments to
VibratorManager methods.
Fix: 180962151
Fix: 180963421
Test: N/A
Change-Id: I3fab2d5fe299be5a951f32bd75eb2e5275ef6e56
Previously, regardless of the downloading progress reported by the client,
right before installation completion, we publish the install progress
as 0.9. For incremental installs, because we will publish the
incremnetal loading progress after the installation completion, we
might see the progress going backward, because the incremental loading
progress is likely less than 0.9.
For a smoother transition, we do not overwrite the client progress.
Instead, during committing, publish the incremental loading progress
while making sure the progress doesn't go backwards. After committing,
the launcher will keep showing the incremental loading progress.
+ Making sure the installer's incremental progress listener is
unregistered after session is committed.
See the demo video for an example. Notice that the progress is changed
during "Installing..." (around 00:35).
BUG: 180040329
Test: manual
Change-Id: I6c30b0dac6758fd103ed6a985ca39b6f8557ba8f
Also, combine WifePowerCalculator and WifiPowerEstimator: they
have a lot more in common than different.
Bug: 158137862
Test: atest WifiPowerCalculatorTest
Change-Id: Ib937102043a1fe04941ecfd09b5077b14058e6ef
... because it is more tied to Context instance that developers
are working with.
Bug: 179308116
Test: atest ContextIsUiContextTest
Change-Id: I41d90c4b5b81b430fc8007a0bdf86c6fd1c54400
Scaling down low amplitudes can lead to one-shot effects with amplitude
zero, which leads to an invalid VibrationEffect and causes
IllegalArgumentException to be thrown on an originally valid effect.
Bug: 179674498
Test: VibrationEffectTest
Change-Id: Ie653084d37f9bfed20aac25f8805ffdf40661e03
