When used in a `ViewPager`, fragments that are present on the adjacent,
cached pages will receive context selection dispatches which, depending
on your fragment contents, can be difficult to determine whether or not
the event truly originated from your view.
By using the visible hint we restrict dispatching to only those fragments
which are marked as being visible. Since the fragment pager adapter
updates this setting properly most implementations will be afforded this
fix without any change required. If the user is implementing their own
adapter they likely already understand the implications of these cached
fragments and the reponsibility for updating the boolean falls to them.
Mirrors support library change Ie6a72c1c82c2784774373670007b6f5948fe16da
Change-Id: I1bc6f74e26660ef4a3c20419c077e37992412e94
If a fragment's saved view state is null and the user
visible hint is true then the `result` bundle will have
never been initialized to a value resulting in a
`NullPointerException`.
Mirrors support library change I8ba585bc6b9298841490d64bc22a8219cd261adb.
Change-Id: Iabd5ac293d2ece3771da9ef257479eca0dcd523c
When the external storage is not mounted, the android system won't
wipe out the user data (i.e. "/data") if wipeData() is called with
the flag WIPE_EXTERNAL_STORAGE.
We think that the user data should be wiped out in any options and
also wipeData(int) method currently supports also for a external
storage. So we will also change the API reference comment.
If we should care about backward compatibility of this method behavior
with the option WIPE_EXTERNAL_STORAGE, then we would add an another
bitmask something like a ALWAYS_RESET.
Change-Id: Id7bf673c722bacc0480d32e46553b9a348513879
The documentation is now consistent with the current UI guidelines
for handling notifications, and includes complete sample code showing
the correct way to do this.
Change-Id: I68f0afc62c2af164c3205535e62093679e2a256a
Update some of the platform documentation to directly link to
relevent support lib docs. Yay!
Also improve BroadcastReceiver documentation to more clearly
discussion security around receivers, and how the support
lib's LocalBroadcastManager can help.
Change-Id: I563c7516d5fbf91ab884c86bc411aff726249e42
Bug #5678369
Caching drawables directly in a static map was responsible for runtime
restarts. If two different UI threads requested the same drawable, the
first thread to issue the request would be given a drawable callback
belonging to the second thread. This would cause an exception in
ViewRootImpl on invalidate.
The solution is to store the drawable states and to create a new
drawable instance every time a drawable is requested from the
cache. This is similar to how preloaded resources are handled.
Change-Id: I47e24e2a168cf67a3589185c6cd77b70f9a1c7cf
1. NumberPicker is trying to greedily grow to its max size
but if the max size is not specified the default value
was the max integer which makes the widget get quite
tall in some cases. Now the widget tries to reach the
max size only if it has been specified.
2. NumberPicker was not computing its min width when the array
of display values is set.
3. DatePicker' layout for the old Theme was adding a margin on
the right of the group of spinners and if the calendar view
is not shown the spinners were not centered. Added the spinners
right margin to the left margin of the calendar view.
4. TimePickerDialog was using the wrong conext and was not dismissable
on an outside touch. Same for the DatePickerDialog context.
bug:5646161
Change-Id: Ic15f9b3e6291b76493604230ceb4f783a04d4ac7
This change fixes race conditions that occur very regularly when
content providers are accessed from multiple threads at the same
time.
When a content provider is not already in the application's cache,
the application needs to ask the ActivityManager to obtain it.
Meanwhile, another thread can come along and do the same thing.
This can cause problems because the application attempts to
install two copies of the provider and the reference counts
and other bookkeeping can get muddled.
Similarly, there are races between releasing the last reference
to a content provider and acquiring the content provider. It's
possible for one thread to snatch the content provider from the
jaws of death. We need to handle this explicitly to ensure that
the content provider does not accidentally get released right
after it was acquired by the other thread.
This change ensures that the reference count bookkeeping and
provider map are maintained in parallel while holding the same lock.
Previously because the lock was dropped and reacquired in the
middle of acquisition and removal, it was possible for a
content provider with a zero reference count to be returned
to the application. Likewise, it was possible for a content
provider with a non-zero reference count to be disposed!
This change also performs compensatory actions when races are
detected to ensure that the necessary invariants are maintained
throughout. In particular, it ensures that the application
drops a duplicate reference to a content provider when no
longer needed.
Another way to solve this problem would be to explicitly prevent
the races from happening in the first place by maintaining a
table of content providers that are in the process of being
acquired. The first thread to attempt to acquire the provider
would store a record. The next thread would find the record
and block until the first thread was finished. I chose not
to implement the code in that manner because we would still
have needed to perform compensatory actions in the case where
the same provider binder has multiple logical names. Also,
it could cause deadlocks if the attempt to acquire
a content provider were re-entrant for some bizarre reason.
Bug: 5547357
Change-Id: I2ad39a8acc30aaf7ae5354decd0a0a41e9b9c3da
...LoadedApk.ServiceDispatcher.connected , LoadedApk.forgetServiceDispatcher
Don't be stupid if we receive a new binding to a ServiceConnection after it
has already been unbound.
Change-Id: I85a49de97372bf9af55542a89031f0b7a2ac8fbb
-> On the Xoom, this change gets us back up to 60 fps. The
change is really more of a workaround for the fact that we don't
have vsync, and we ought to be able to change it back once we do.
Change-Id: I80888f18887bf5f2fed72c19641ed430ef6dbfcf
We are tagging these as "watchdog" to make them visible in the
reporting tools.
Also new am command to kill all background processes, mostly to make
it easier to test this stuff.
Change-Id: Ib9dc4747cd8bd44156fdf11d6a087cd4272203eb
Allow a fragment to set a hint of whether or not it is currently user
visible. This will be used implicitly to defer the start of fragments
that are not user visible until the loaders for visible fragments have
run. This hint defaults to true.
Change-Id: Id1349d319886a277ef07301f64f7b9e12c8729bf
stopped if "defer start" is enabled
Only revise the target state in moveToState if it would cross the
stopped/started boundary.
Change-Id: I8f6e400331157eac9343261117cf633611fc1e4d
manager
Remove extra queued dialog dismiss messages when applicable. Log an
error if the app tries to dismiss a dialog when its window has been
destroyed.
Change-Id: Ice8383d4420c052e31fbbd9fcd25051f3bd9b58d
- Don't try to create a thumbnail bitmap on the client side. This
wastes 64k, and isn't needed since we are doing screenshots.
- Optimize View to put all of the callback pointers out of line.
Added a couple new APIs so these don't need to be protected/public.
- Lazily create ViewGroup's cache paint.
- Change FrameworkPerf app to not use HW accel drawing, to give better
comparison with GB.
Change-Id: Iec56d02459820d74a4cc9c7ec9c1856563c82c7b
orientation change when there is a dialog with ActionMode on
Fix a bug closing down active action modes as dialogs are closing.
Change-Id: I0d28e3b3845d5ed50fbb55b180dafa1b11957b81
Fragments now have the setDeferStart method to signal that a fragment
has lower priority than others. Deferred start fragments will not
always be started immediately; they will be started once any loaders
have finished servicing any outstanding requests. This is useful if
any attached fragments are not immediately visible and can wait to
start until later.
Disabling deferStart on a fragment that is waiting for a deferred
start will start it immediately. Start.
Change-Id: Ia1f004877ca5e88d4f10147d21c7e2e97f141c34
This fixes a bug where the clock wasn't being shown in the statusbar while
the music widget is showing.
Change-Id: Ic1c52c4ab7fa1490fe14ddafaf2c494bcf51866d
