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
Required replumbing and updating the TaskStack bounds calculations
to match the new separation of TaskStack from DisplayContent.
Fixes bug 12780687.
Change-Id: I061c92831c06f4eb3e673ad6296e721b0c0f3202
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
Pull the strategy for determining the automatic brightness levels
into its own class. This cleans up DisplayPowerController a bit and
lets us experiment with different automatic brightness strategies
more easily.
Change-Id: I8f4249da511e38f63260dbef81f97f5507aac948
