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
Applications now get the display size from the window manager. No
behavior should be changed yet, this is just prep for some real
changes.
Change-Id: I47bf8b55ecd4476c25ed6482494a7bcc5fae45d2
Activity manager now does all dump requests into apps
asynchronously, so it can nicely timeout if there is an
app problem. Also lots of general cleanup of the am
dump output.
Change-Id: I99447b87f77a701af52aeca984d93dfe931f065d
Back-port new fragment detach APIs from support lib.
This allow a much cleaner implementation of things like the
fragment pager class.
Integrate from support lib: fix restore of list state.
The FragmentManager/ListFragment impl was restoring the list
state before setting its adapter. This caused the list view to
lose the state, since it gets cleared as part of setting the
adapter. Now the fragment manager waits on restoring the view
hierarchy state until after it has done onActivityCreated(),
at which point we have set the adapter.
It would be nice to make list view less fragile in this regard,
but that is for a different change.
Change-Id: I38606ef7d0b06478995f3fb7726aead67420e172
