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
Previously, the disabled color was used for the contrast
calculations, which resulted in too dark RemoteInputView
backgrounds.
Change-Id: I99e8b2fa64a22a59fdc5d1be8a6aff5af3523a27
Fixes: 28429720
The transformed view could get updated during the transition
leading to a crash sometimes. We're now handling this better and
make sure the correct values are set.
Change-Id: I1a311cb7c108afeec0fc1c92eb3359c622db7b87
Fixes: 27922191
This plays nicer with SELinux and generally means we can be more robust
about file security policies.
Bug 28403975
Change-Id: I857ee7073c0090c7515421f41c9334025e25bc79
Added endian.h into include list to avoid build error in "docs".
The function "htobe64" in endian.h is used.
Change-Id: Ic76dab25d34c56b58b97849dfa7b103963392568
- 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
