...the repeated hour in DST transition
Record the last crash info that caused an app to be marked as a bad app.
Also for the battery work, add a system property tuning parameter to be
able to control the background service start delay, so we can easily
run experiments with it turned off if we want.
Change-Id: Ic33dc464d8011c918a39b912da09ea4f0fb28874
Previously inserted requirment that an activity be visible in order to
block visibility of the home screen is removed.
Fixes bug 11515761.
Change-Id: Ia47cfb4a0b6d90bbbca2b42e12a6048b1644d7cb
To support "giant" phones which are really just normal phones
strapped to external HDMI displays, add the property
persist.demo.hdmirotates. It defaults to false, but when it is
set to true, the FLAG_ROTATES_WITH_CONTENT to set on the
display. This allows the external display to show the same
display as the built-in display as the "giant" phone display is
rotated.
Note that previously, FLAG_ROTATES_WITH_CONTENT was only set on
the built-in display. The code that checked the flag also
explicitly ignored it on any display that was not the built-in
display. This added check was removed to allow the flag to be
functional on other displays.
Change-Id: I55b249140b1f61fb98cac586f7e4d48e2f5b3e30
Signed-off-by: Scott Anderson <saa@android.com>
Tethering currently inherits from the AIDL interface
INetworkManagementEventObserver, so it has to provide no-op
implementations of all the interface's methods. Inherit from
BaseNetworkObserver and get rid of the no-ops.
Bug: 9180552
Change-Id: I74859b0d77951005651aaaa418185857e40eeedb
Apply the test for configuration change to all windows. A year ago
this was the test but CL ag/247731 which fixed b/7428221 limited the
test to just Keyguard windows. A week later CL ag/248223 which fixed
b/7444971 applied the test to Wallpaper as well. Then two days after
that CL ag/249762 which fixed b/7453222 reverted the wallpaper. This
fix reverts the Keyguard qualification and restores the test to all
windows.
This fix has been tested against the repro steps for all three bugs
above. In addition this fixes bug 11033407. The fix for the bug is
described in the bug.
Change-Id: Ie0f4c7cd4697c1689c4f331d572359cf7ce934cf
1. The up event for a long press was not properly adjusted as the
long pressing finger may not be on top of the accessibility
focused item.
2. There was a scenario where two finger swipe leads to a crash.
One finger moves, second finger goes down but no finger moves,
the first finger goes up, and now the second finger moves. All
this has to happen before we decided that user is touch exploring.
Very hard to happen, this is why we could not easily repro the
crash.
3. We use the two finger vector angle to determine whether the
user is dragging or not. However, in some cases we were
unnecessarily waiting too long before performing the check
and as a result the notification shade on Manta was not
expandable.
bug:11341530
bug:11189225
Change-Id: Ieea39783444a1c20581f8addfd518d1c11485099
Actually, the state representation seems fine, but there was a problem
we are now hitting where the restart interval could get reset back to
0 when it shouldn't be. Also tune the restart parameters a bit.
Change-Id: I364f38e52f5387b2ec3f81009ccc78976ff48891
...not to work on KitKat (was: Janky exit animation)
Reworking the LRU list (splitting it into an activity vs. empty
section) accidentally broken the old behavior of "client activity"
processes being prioritized with activity processes. In fact, we
were no longer marking "client activity" processes at all.
In this change, we rework how we manage "client activity" processes
by putting them on the main activity LRU section. This is generally
simple -- ActiveServices now keeps track of whether a process is
a "client activity" process based on its bindings, and updateLruProcess
treats these as regular activity processes. However, we don't want
to allow processes doing this to spam our LRU list so that we lose
everything else, so there is some additional complexity in managing
that list where we spread client activity processes across is so
that the intermingle with other activity processes.
The rest of the change is fairly simple -- the old client activity
process management is gone, but that doesn't matter because it wasn't
actually running any more. There is a new argument to updateLruProcess
to indicate a client process it comes from (since we now need to update
this based on bindings) which is just used to limit how high in the
LRU list we can move things. The ProcessRecord.hasActivities field is
simply removied, because ProcessRecord.activities.size() > 0 means the
same thing, and that is actually what all of the key mechanisms are using
at this point.
Finally, note there is some commented out code of a new way to manage
the LRU movement. This isn't in use, but something I would like to
move to in the next release so it is staying there for now for further
development.
Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18
