Because we move the task to the front in startRecentsActivity, we
always overrode the app transition type. Instead, we should remove
this logic and keep a flag whether the animation was prolonging was
finished already. If it was finished already, don't start the
prolonging when starting the transition.
Bug: 27154882
Change-Id: I1cd9e323867726ebd4b131ed5c13c3834d0f1107
This ensures that IpManager has a complete copy of DHCP state
before configuring the IPv4 address. That way, when the netlink
notification of the IPv4 address arrives, we are guaranteed to
have all DHCP information (including DNS servers and routes)
available and we will never send the IPv4 address before the DNS
servers.
Bug: 27605330
Change-Id: I732424dfe2408be9e40028563e99d610b541e12d
We always update the display info before handling the configuration
change. Thus, we remove this weird interleaving asynchronous beast
of code and handle rotation and density in updateBoundsAfterConfigChange
and everything else in updateDisplayInfo.
Sending an asynchronous message to resize the stack only causes race
condition and issues.
Change-Id: Ifa86f62e816917822a8c1d42d13d4bf1ad9bc5bf
Fixes: 28316517
Bug: 28184044
If we start the forced resizable activity with an existing task,
avoid moving that task to the front. This can cause that a previous
task that was moved to the back gets moved to the front again just
because we started that activity. That's not good.
Bug: 28223489
Change-Id: If8acf31b8be98b82665de1015d5621331c37fb64
We could run into this situation on some devices (eg. clockworks),
the next activity doesn't get launched until we destroy this one.
allResumedActivitiesVisible() will return false if there is no other
activity running at all. Check top running activity and it's visibility
instead.
bug: 28400334
Change-Id: Ib8957e499580a10206fdd4e27da19fbc2bdb5843
processStoppingActivitiesLocked() only removes one record each time, so
instead of stopping on the next window visible (or next idle), it now
requires two such calls to move the app to destroyed, if there's only
one report, the app never gets removed.
bug: 28417200
Change-Id: I7c5eac240074ed0434a72643a8d52f1726ab906c
- update mTempConfig from mCurConfig first to decide if
config is changed or not. This fixes recursion of putting
new config again from reconfigureDisplay
- ignore setNewConfiguration if there is no change in configuration
This fixes another recursion due to config change -> app restart
loop
bug: 28381048
Change-Id: I4c2e6072b269baf9fa11d4b8073f0800c0e0d28d
If an app undergoes restore during install, it is considered 'started'
and the FIRST_LAUNCH broadcast needs to go out. However, this must not
take place until after the restore operation has fully completed, in
order to avoid publishing the app's existence while it may still be in
an incoherent state. We now make this broadcast part of POST_INSTALL
in the restore case.
Bundled apps are in the 'started' state regardless, so no FIRST_LAUNCH
broadcast is ever sent for them -- this CL does not change that
existing behavior even in the case of setup-time data restore of
factory-installed packages.
Bug 28173625
Change-Id: Ibcc3758576662dc447b75476173a0d008a9fe4da
Clarifying region used for magnification as "magnificationRegion",
both in the public API and in the code. There's been significant
confusion about what "magnfifiedRegion" means. Removing
"availableRegion" from everywhere except where it's required, as
that region was identical to magnified/magnification region.
Trying to shut down magnification was a complex situation where
animations in progress and new magnification requests were tricky to
handle correctly. It was not possible to guarantee that the
magnification callbacks were unregistered consistently. There were
at least two situations that led to phone restarts:
1. If a triple tap was detected between unregistering the callbacks
and shutting down the input filter. In this case the magnification
request would go through.
2. If an animation had just started when magnification was turned
off, so the current magnification was 1.0 but the animator was
about to change it. In this case the callbacks would be unregistered,
and then the animator would start changing the magnification.
This change makes registering and unregistering magnification atomic.
It also makes MagnificationController stick around indefinitely once it
is created, registering and unregistering as needed to support
magnification gestures and services that control magnification. Services
that merely query the status of magnification no longer register for
callbacks.
One part of shutting down is turning off the animation and guaranteeing
that it won't try to make further changes. Adding a flag to
SpecAnimationBridge and a lock in that class so we can guarantee that
nothing happens when we aren't registered for magnification callbacks.
Also reconfiguring all accessibility options when a service stops to
make sure that only the features required by the current configuration
are enabled.
Bug: 27497138
Bug: 27821103
Change-Id: If697cbd34b117d82c8eee1ba7d0254089ee4241d
Exports SOC specific low power state info to batterystats service.
BatteryStats service queries the powerHAL module whenever and
updates the HistoryStepDetails whenever setBatteryState is called by the
BatteryService. The stats get appended to the battery history whenever
there is a change in the battery level.
Bug: 26564574
Change-Id: I02b4db00aec0c69d1558492224f3a4dc1c386fa6
This change takes an app's shared libraries specified by <uses-library>
and passes it through to dex2oat to be used during compilation.
Part of a multi-project change.
Bug: 26880306
(cherry-picked from 7b331b6a8a)
Change-Id: I523b1b74775e7ed27072498509e743f1f10b1164
Having the docked stack across user switches currently leads
to issues like wrong configuration state for apps. Dismissing
docked stack for now until we find a better way to handle this.
Bug: 28195260
bug: 28221061
Change-Id: I568a2c69783b1f0d7016fe1a21df959f7c2c9145
* changes:
Unhide getHdrCapabilities and HdrCapabilities.
Plumb HDR capabilities to Display
Revert "Revert "Hook up HDR capabilities from native SurfaceControl""
Previously USER_INITIALIZE was sent before USER_UNLOCKED. This was leaving
BOOT_COMPLETED as the only option for non-directBootAware apps to do one time
initialization.
Now USER_INITIALIZE is sent immediately after the user is unlocked.
Bug: 28278011
Change-Id: Id82eae91af80a66454d4027050120ae841decfeb
When upgrading from version 0 to version 1 of the file
'/data/system/package-usage.list', the PackageManagerService can get
stuck in an infinite loop if one of the listed packages does not
exist, e.g. because it had been uninstalled. Fix the issue by
refactoring the loop.
Bug: 28409278
Change-Id: Ia312bd0d04f696240445b710dd6a68b93c5d5946
- in dump, the array of pending intent was iterated without locking
against logEvent. This can throw a ConcurrentModificationException
if at the same time logEvent sends intents and remove them from the
array.
- in getEvents, the returned reference was reading the reference of the
last event after releasing the lock on mEvents, which can cause
callers to miss events if at the same time logEvent is called and
mLastEventReference is incremented.
Bug: 28204408
Change-Id: I7ff21d4d2c0b02d8e0b47310430dff7d8a87f0bf
