When animating away a fragment, we were not putting it through
the last part of its lifecycle (onDestroy() etc).
Also, retained fragments that have a target were broken. Oops.
Change-Id: I5a669b77a2f24b581cde2a0959acf62edb65e326
Loaders were not being re-initialized correctly when coming back
(this would also impact the back stack). The ListView also wasn't
working correctly, and there were also problems with simply
re-using a Fragment instance after it had been removed.
Change-Id: I534b091ae09c0ef7ffffe9d68049e6840e8926b3
...for Market App iRunner
There were a lot of serious issues with how we updated (or often didn't update)
the display and resource state when switching compatibility mode in conjunction
with restarting and updating application components. This addresses everything
I could find.
Unfortunately it does *not* fix this particular app. I am starting to think this
is just an issue in the app. This change does fix a number of other problems
I could repro, such as switching the compatibility mode of an IME.
Also a few changes here and there to get rid of $#*&^!! debug logs.
Change-Id: Ib15572eac9ec93b4b9966ddcbbc830ce9dec1317
Also fix issue #4519821:
Blank screen displayed on tapping "Battery Use" option in the settings
We weren't correctly doing the full Activity resume code when coming
back from delivering a new Intent or result.
And fix a fragment problem where we still weren't correctly restoring
the state of list views. (I think this was from a bad manual-merge
from master.)
Change-Id: If79dc7e998155c39ab8c04781f6c73a82238a9ef
There was a race in the system process between applying the initial
configuration and executing code in higher-level system services
like the app widget service that relies on the config. For some
reason it starting showing up more after my code changes; it should
now be completely fixed.
Also fix the activity starting window to run in compatibility mode
if its application is going to be in compatibility mode.
And some various cleanup and small fixes.
Change-Id: I0566933bf1bbb4259c1d99a60c0a3c19af1542e5
Change-Id: I40d57e4354e48accc1027c9f90916ea73eb5190d
android:requiresSmallestWidthDp provides the smallest supported width.
android:compatibleWidthLimitDp provides the largest compatible width.
The PhoneWindowManager is now responsible for determing this,
since it needs to do this before we can generate the configuration
since we need to take into account the system bar size we will use.
Also the Display should now report the screen height without
including the system bar.
Change-Id: I82dfcc5e327e4d13d82c373c6c870f557a99b757
To avoid blowing past the Binder IPC limit, change the
PackageManagerService to have a DB-like interaction where the client
tells the service the last "row" that it read.
The fact that we use a HashMap instead of a TreeMap makes this
problematic. For now we're just making a new ArrayList for the keys and
then sorting them for each call. This can make the API slower for callers
of this, but it's probably greatly overshadowed by the cost of the data
transfer itself.
Bug: 4064282
Change-Id: Ia3a8cdaa94581ed9336f2e05694b8c8a5f757bce
We now correctly adjust display metrics, fixing for example issues
seen in Barcode Scanner. In addition the decision about when to use
compatibility mode has a bug fixed where certain apps would not go
out of compatibility mode even though they should be able to.
Change-Id: I5971206323df0f11ce653d1c790c700f457f0582
* New opaque assets (now actually opaque!)
* SearchDialog determines theme to use from parent context
* SearchDialog now disallows action modes
Change-Id: If05fe64d7cc4460678d78412275ee988ddb47e9e
The previous fragment implementation allowed for animations
during fragment transitions, but did not account for the
different behavior of fragments when popping the back stack.
In general, you probably don't want to run the same animation
for putting a fragment on the stack as for popping it off, which
is what happens now. For example, you might fade a fragment out when
putting it on the stack. But when popping ot off, fading it out
is probably not the behavior you want.
The new API (setCustomAnimations() overload with two additional
parameters) allows developers to specify animations to be run
in the popping operation. Otherwise, the animations are null and
the operation will not be animated.
Change-Id: I53bbc6e6ec4e953b7ecdd99e2452d81857917de2
