If a job was run before its deadline, and then the deadline landed
while the job was still running, b/c of the 'deadline trumps all'
it would be considered eligible to run again as soon as the previous
iteration completed.
Fix this by checking against the state of the active queue.
Bug 36253320
Test: CTS: job scheduler TimingConstraintsTest
Change-Id: I4f0c1012091bf88776cfe725d7b59f6dcf602c02
This reduces jitter in the WifiTracker and is modeled after a prior
broken implementation which attempted to half-life the rssi each time
AccessPoint.update(ScanResult) is called.
Bug: 34774783
Test: runtest --path
frameworks/base/packages/SettingsLib/tests/integ/src/com/android/settingslib/wifi/AccessPointTest.java
Change-Id: Iab3f9914af40f2fd56e8ae7b45dcbd62176c8a67
The host versions of these were pointing to the target generated
sources, without having proper dependencies added. But the build system
already handles these adding these to your local and exported include
directories, so just remove them.
Bug: 36365556
Test: m -j libhwui incident_report incident-section-gen
Change-Id: I52024508eabd8d10899c307c950fe045ff66ab25
Let's have several separate contexts instead of doing strange things
with package names in one monolithic context representing every single
user on the device at once, sometimes multiple times in the same call.
Syntax looks like:
runAsCaller(callerContext, dpms, (dpm) -> {
assertSomething(dpm.doSomething(caller, param));
});
When a caller calls into DevicePolicyManager here's what happens:
PRE
- a new DevicePolicyManager is created with the caller context
- service context callingIdentity is saved
- the callingUid, callingPid, and callingPermissions are added to the service context
TEST
- client-side test code interacts with DevicePolicyManager using the caller context
- server-side coder under test runs as DevicePolicyManagerService using the service context
POST
- service context callingIdentity is restored to what it was before the test.
This should be easier to reason about.
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I148e3f298b0a958639ce261e9cf91f6eb49fae4d
Replace incorrect call to ArrayMap.get with correct call
ArrayMap.valueAt.
This bug was discovered when removing an overlay from /vendor/overlay
and restarting the device. The OMS settings file still referred to the
overlay, and when the settings item was to be removed, the following
crash occurred.
*** FATAL EXCEPTION IN SYSTEM PROCESS: main
java.lang.NullPointerException: Attempt to read from field 'java.lang.String android.content.om.OverlayInfo.packageName' on a null object reference
at com.android.server.om.OverlayManagerServiceImpl.onSwitchUser(OverlayManagerServiceImpl.java:121)
at com.android.server.om.OverlayManagerService.onSwitchUser(OverlayManagerService.java:257)
at com.android.server.om.OverlayManagerService.<init>(OverlayManagerService.java:237)
at com.android.server.SystemServer.startBootstrapServices(SystemServer.java:580)
at com.android.server.SystemServer.run(SystemServer.java:363)
at com.android.server.SystemServer.main(SystemServer.java:238)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:226)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:726)
Test: adb exec-out stop && adb exec-out rm /vendor/overlay/... && adb exec-out start
Change-Id: I341a8d6eb90555b9169e5cd7dfac87d850b72e9b
Since there is a CTS test depending on it which is currently hardcoding
the string. Let's not do that.
Bug: 30658854
Test: make full -j30
Change-Id: I6f6b1044ac664589b8fe76ced9961e80024b0b29
Its making it inconsistently show up on the lock screen. Until
final behavior is decided, revert to old behavior.
Change-Id: Ifc69f2d5b527cc9ce5a174b16b8b605db26fc35b
Fixes: 36141544
Test: visual
MANAGE_ACTIVITY_STACKS permission allows moving stacks, tasks and
activities between corresponding parents. It makes no sense to
require more strict START_ANY_ACTIVITY permission to launch on
private display, as an activity still can be moved to it.
Bug: 34164473
Test: 'adb unroot' and run android.server.cts.ActivityManagerDisplayTests
Change-Id: I3b59127829c432e42a46630025eeddd152bce1b0
This logging was originally added to track down very large log
messages that were causing Binder transactions to fail. We fixed
a handful of bugs that could have been causing this over in 32575987,
so this logging should no longer be needed in live builds. (In fact,
this logging is being triggered often enough to push other important
debugging information out of logs.)
Test: builds, boots
Bug: 36372780
Change-Id: I640192fbec35693673a2f22b7a82ce54f27937da
Addressing the concerns raised by API council for deprecating this
field.
Bug: 35854198
Test: make update-api
Change-Id: If9ca582f5d3bd8539a226b425662832241a447cc
Adding some documentation to explain the expected contents of this
field.
Bug: 35967623
Test: make update-api
Change-Id: Ia28e2c79834c4d7b0de7350c18d5f32633e6309d
