This reverts commit ba29dbc3b38d9efb743d6fa7f9f8c4bb75c38b28.
The original commit causes apps such as phone and clock to not wake the
device.
Fixes: 37197491
Change-Id: I1b45cafbcbf12991d8e1e716e4d1751cd077c556
DualTimer attempted to detach its subTimer twice when reset(true) was
called, once explicitly and once via a call to the main timer. This
fixes that problem by getting rid of the explicit detach in reset.
Bug: 37208694
Test: runtest -x
frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
and manually looked for "Removed unknown observer" error in logcat.
Change-Id: Ic5ff7d799d46236a74ab0825e108bef40bac0360
- In new shutdown flow, adb is guaranteed to be alive while system server
is alive.
- power manager can be killed before system server is killed.
- This leads into RemoteException for shutdown request to power manager.
- If shutdown is already on-going (=sys.powerctl set), the RemoteException
should be ignored.
bug: 37096155
Test: adb shell svc power reboot|shutdown and check output to adb
Change-Id: Ia90a900d55123bd7c1bf57c90c49d35332ebfdf5
Soong handles these automatically now.
Bug: 33241851
Test: Android-aosp_arm.mk is the same before/after
Test: build.ninja is the same before/after
Test: build-aosp_arm.ninja is the same before/after
Change-Id: Ic10796e75bb886cc3f92c234714ab3e6c85112df
Just in case the kernel or vendor glue don't initialize the system time
sensibly, we now make sure the current time at boot is at least up to the
build time of the system disk image.
Bug 36736983
Test: manual
Change-Id: I46f776300ca4f5ad01396fc17c83fc833e1713f9
Generating splits should be possible to do from the optimize command.
This means that a lot of infrastructure around split APKs can be
shared by both the optimize and link phase.
Bug: 35925830
Change-Id: Ia88b9e4bff300a56353b2f7a4a2547c8eb43a299
Test: manual
Recent changes passed down the nullable array to a method where it
was not being properly checked.
Change-Id: Ibf940f9225e4c9901869188aa55a04d0908015c3
Fixes: 37197666
Test: manual via bug repro steps.
We were relaunching an activity in the docked stack that is been
dismissed because we call ensure configuration on it due to the
resize of it been moved to the fullscreen stack. This isn't needed
as the activity is about to become invisible since it is been moved
to a stack that isn't visible.
We now ensuring the configuration if:
- The stack the activity is in shouldn't be visible.
- The activity is currently stopped or stopping.
Change-Id: I6adac6b11a0db4b100e623e4074e169660206567
Fixes: 37118176
Test: Activity in docked stack isn't relaunched when dismissed.
The BoringLayout measurements for auto-size are
incorrect. Removed those and kept the StaticLayout
measurements.
Bug: 36940118
Test: cts-tradefed run cts-dev -m CtsWidgetTestCases -t\
android.widget.cts.TextViewTest
Change-Id: I772ade08ed26efac05ca56cb7df8cfec0327633b
Callers of addNetworkPolicy() were not taking locks in the correct order
inside NetworkPolicyManagerService:
- addNetworkPolicy() is an internal method that calls
setNetworkPolicies which takes both mUidRulesFirstLock and
mNetworkPoliciesSecondLock in order.
- both callers of addNetworkPolicy, mWifiStateReceiver and
mConnReceiver via ensureActiveMobilePolicy, were taking
mNetworkPoliciesSecondLock before calling addNetworkPolicy.
- this causes the order of locking to be reversed, which can cause a
deadlock when another concurrent codepath in
NetworkPolicyManagerService tries to take both locks in the correct
order.
This patch fixes this issue by wrapping both problematic codepaths into
addNetworkPolicy() with a lock on mUidRulesFirstLock.
Test: build, flashed, NetworkPolicyManagerServiceTest passes
Bug: 36972283
Change-Id: If7888c11aef8b628e1b013224075c4c75eae0022
Previously we used 0 for the id of the "Always-on VPN disconnected"
notification, as did many other system services. In a recent CL, an
effort was made to assign a dedicated id to each of these system
notifications. Unfortunately, this CL only changed the id in the call to
NotificationManager#notify(), but not NotificationManager#cancel(). This
causes the notification to persist even when always-on VPN is turned off
by the user.
This CL changes the id in the cancel() call, thus fixing the issue.
Bug: 37175930
Test: manually enable and disable always-on and observe the notification
Change-Id: I39c7325c78479afe3dc9e1764d54406bd721b067
