Settings.Secure.LOCK_SCREEN_ALLOW_PRIVATE_NOTIFICATIONS, if
set and nonzero, will show that user's notifications on the
secure lockscreen (assuming LOCK_SCREEN_ALLOW_NOTIFICATIONS
is also set). Note that this applies only to a particular
user's notifications, so if multiple users' notifications
are shown at once (currently this only applies to the
current user and USER_ALL) only that user's notifications
are affected.
USER_ALL is assumed to always allow private notifications in
public (because they can't be user-specific).
Change-Id: I32bb7939066c4919191e74161ca48ead01a88c7f
Previously the userId of the current process used but it
makes the provisioning process cleaner to be able to pass
it in explicitly.
Change-Id: I670c4cf3638f1340f6d0bf856c3e01045df8c29e
The AbsListView sub-scroller knows nothing about layout. That's now
handled by ListView and GridView, with subclasses of AbsListView using
the default PositionScroller. Removes unnecessary (unreleased) APIs.
Also fixes a bounds check that was using the item position rather than
the child view position.
BUG: 13006641
Change-Id: I2adb0f15623e32295facf81f5ada974083ba03ce
- do not make inactive the fragment when its transition animation is ending.
Long explanation:
Context: you need to have a first fragment pushed and then a second one replacing
the first one, and then create a DialogFragment on top of it. The FragmentManager
has then three "active" Fragments.
The mActive ArrayList of the FragmentManager is then containing:
mActive[0] = first fragment
mActive[1] = second fragment (parent of the dialog fragment)
mActive[2[ = dialog fragment
Then suppose you are changing the orientation.
During the restoration of the FragmentManager states, you will see that the
first Fragment is marked "inactive" and the mActive ArrayList is looking like:
mActive[0] = dialog fragment
mActive[1] = second fragment
which leads first to have a call to onCreateDialog() for the DialogFragment and
before it can be able to restore its state thru the calls to onCreate() and
onCreateView() for the parent (the second fragment).
Change-Id: I0268bdf13e4bdd07a783c2c82a13b431d0c5c8e4
We now always turn on network state tracking for mobile,
and push this information down to battery stats.
In battery stats we use this to both log the changes in
the history and keep track of the total time the mobile
radio was active.
Power computation is switched over to using this information
to help determine power use, which will hopefully make it
more accurate (not counting inaccuracies in knowing when it
actually goes down).
Note yet done is aggregating this data per-uid, to better
emphasize which apps are causing the radio to be up. Right
now we just spread the total time across all uids weighted
by the total number of packets they have sent and received.
Also put in the battery stats infrastructure for bluetooth to
address issue #12973036: Improve power_profile.xml
Change-Id: I39d11b7ff6ae4f336f253d1cba308d8569de7e0d
Java plumbing to expose methods to get/set encryption type in
IMountService, and hooking up of those methods to the Settings app
so the type is set correctly.
Needs matching vold changes from
https://googleplex-android-review.googlesource.com/#/c/412649/
Bug: 8769627
Change-Id: I70c0ed72d11f5ab6f0958a7f9c101b6822b13baa
ChromeView generates a large amount of such logs; while the real
root cause is being fixed, reduce the verbosity so other
interesting logs won't get overwritten.
Bug: 10871032
Change-Id: If42116671062d7b2cc2a13384424575da499c493
