The previous change only hid the fragment when the transition animation
ended. But if there is no animation, the fragment would never be hidden.
This change adds an else clause that handles the non-animating case.
Change-Id: Ie35b2ae98cb5c21193dadefbef71b8542fcf5f7d
...android.app.Fragment.startActivityForResult(Fragment.java)
Make sure to remove all pending messages when AbsListView is detached
from its window.
But... that's not enough.
It turns out that when a fragment's views are animating away, they of
course don't get detached until after the animation is done. However
the fragment itself is immediately destroyed, leaving its live views
still going after that.
Here's a possible solution: when fragment manager initiates an animation
on a fragment whose views are being removed, it makes note of that so
it can hold off on destroying the fragment until the animation is over.
There are a lot of interesting race conditions here, if further operations
happen on the fragment while it is being animated. I think the code here
does something sensible, and it does seem to work for the situations I
have tested, but it is hard to know all of the edge cases that may happen.
Change-Id: I4490ce8862a9bb714c7ea54baca3072c62126388
These can be included as desired by particular devices to configure
their Dalvik heap in a standard way.
Change-Id: I487c751d7c583b0e93552f16ab43a93314219778
Prior to this change, saveInstanceState would
call directly to Activity.onSaveInstanceState(),
rather than performSaveInstanceState().
This meant that saveManagdDialogs() was not called,
so Activities running under a LocalActivityManager
do not get their dialogs restored on configuration changes.
Change-Id: Id45110a8716a86958c14f4b1ea5a84c9cdf107f1
in HC, using DownloadManager public API, download directories
named by the constants Environment.DOWNLOAD_*
may ot exist. theyneed to be created or
the download request should fail ASAP.
bug:3297328
Change-Id: Ic87023d8fe98bd240744f66607a5400b7825e17e
list UI is not ready yet
This involves some reworking of Loaders.
Loaders, in particular CursorLoader, are now expected to retain
their current data after being stopped. This allows applications
to keep that data across onStop() -> onStart(), so when the user
returns to the app it doesn't have to wait for the data to reload
and thus cause flicker.
This includes various API changes to better reflect the new
semantics, plus a new LoaderCallbacks method to tell the application
when it is actually time to stop their use of a loader's data.
Note this is somewhat half-done, to help checking in the extensive
application changes that are required without causing build breakage.
Change-Id: Ib4b3bf8185a6da46e7f06ca125521d65e2e380a1
Issue #3169193: com.google.android.youtube: java.lang.NullPointerException
at com.google.android.youtube.async.UserAuthorizer$3.onCancel(UserAuthorizer.java:324)
A little protection against calling onCancel() after a dialog has been
dismissed.
Change-Id: I7a64c94703da012ce303308563e4a8ed3cb125d3
Also, changes to make this testable with CTS:
-- special PENALTY_DEATH StrictMode fast path that doesn't use
the Looper idling to "time" the violation. Only used when
death is the only violation,
-- make PENALTY_DEATH throw a RuntimeException instead of
killing its process with a signal. this means we can catch
it in CTS tests, but it's also more consistent with
PENALTY_NETWORK_DEATH in Honeycomb.
-- make FileUtils.getFileStatus() invoke StrictMode, which isn't
(yet?) aware of I/O in native code. so help it out.
CTS test for MODE_MULTI_PROCESS is in I6154edab
Change-Id: Icf93f9dfb0ece06b16781e4803dd2c17df3cf1b3
Bug: 3236568
This adds a way to insert a title as well as get a callback when that title is clicked.
It is not really on the backstack and clicks must be handled via the listener interface.
Also issue #3281400: Rotating a retained instance fragment leaks the fragment manager
And turn off fragment debug logging.
Change-Id: Ibdd7db82bb35618021bcba421ba92ced7cd691c2
If the dimensions of the original are sufficiently different from the
device's preferred dimensions, just don't restore the image. This
avoids bad letterboxing / clipping on e.g. phone <-> tablet data
migration.
The expansion/shrinkage ratios used here allow restores of saved
wallpaper images among HVGA devices, among WVGA variants, and
among tablets; but skip restoring wallpapers across those
categories (where severe clipping or letterboxing would occur).
Bug 3261863
Change-Id: I75e75d6401d18f1df10d75796ee04e21d2302cfa
Plus a bunch of debug output improvements.
And some new Intent helpers for dealing with restarting an app.
Change-Id: I50ec56bca6a86c562156b13fe8a6fdf68038a12e
This gives NFC service a handle to the application context.
Deprecate NfcAdapter.getDefaultAdapter(), it does not provide a context.
Using this method will print a warning, and will later throw an exception
if a method that requires a context is called. No 2.3 API's will fail, but
new API's that do require a context might fail.
Also add helper NfcAdapter.getDefaultAdapter(Context).
Change-Id: I9a6378de4ef4b61ad922f8d53e64e2a1a1d5d60c
Privileged callers can now ask the transport for a string describing
its current state, and for an Intent that can be passed to startActivity()
in order to bring up its exported configuration UI. These will be used
in Settings in order to e.g. show the user the currently active account
being used for backup, and allow the user to choose an account.
The data being funnelled through IBackupManager here are the ones
already exposed by the transports in their implementation of the
IBackupTransport interface.
Bug: 2753632
Change-Id: I2227a2b111d8d0ddf221d63020e20c1316fff55b
* Allows an app to detect that it needs to have additional policies granted
* Add "refreshing" parameter to setActiveAdmin() to handle this case
* Minor cleanups to eliminate warnings (mostly for unused things)
Bug: 3253179
Change-Id: I4bf639bf560557130bf98e8cfb75f996fac416f1
3257701 Preference headers have duplicated "title" and "summary" if
title is not loaded from a resource
3267312 Fragment.onConfigurationChanged doesn't get called
Change-Id: I76e346ba88aa632ebb9aa413a2ce2645ebf357cd
The goal is to fix a bunch of fragment-related bugs caused by various
things trying to do fragment transactions after onPause()... which
currently throws an exception, since this is after the activity's state
has been saved so the new fragment state can be lost.
The basic change is relatively simple -- we now consider processes
hosting paused or stopping activities to be unkillable, and the client
code now does the onSaveInstanceState() as part of stopping the
activity.
For compatibility, if an app's targetSdkVersion is < HONEYCOMB, the
client side will still call onSaveInstanceState() prior to onPause()
and just hold on to that state until it needs to report it in once
being stopped.
Also included here is a change to generate thumbnails by taking
screenshots. The code for generating thumbnails by re-rendering
the view hierarchy is thus removed.
Change-Id: Iac1191646bd3cadbfe65779297795f22edf7e74a
