| d7c9289f935992f4ae2fc032747f9e04bb86a7d0 |
|
28-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17289876: startActivityFromRecents appears to launch the wrong task
It would be good to actually bring the task to the front.
Also, make the flow when inTask is provided better match what happens when
we go looking for a task on our own.
And this includes another fix that was supposed to be part of a different
change but I forgot this class is part of the framework project now.
Change-Id: I3cf05f2e585c0fd7a0dbb7c7cf9fb1655764dd93
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| d953c53d3b04d772bb1b62ede1c2011641ca82b5 |
|
17-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #16629489: Google (Play?) Services eating through battery
There is a bug in how we deal with name overflows combined with resetting
the battery stats data. If we do a reset while a wakelock is being
actively held that has been put into the overflow bucket, then we can
end up reducing the number of known wake locks in the list so when after
that it is released we try to release it under its real name rather than
the overflow name.
This means we need to keep track of which wake locks have been placed
in the overflow bucket while they are actively being used, so we can be
sure to properly handle it as part of that bucket until it is eventually
released.
This makes things... somewhat more complicated. So now we have a class
to take care of all these details, and also use it for other places where
we have the same overflow semantics sync and job stats.
Also fix potential deadlock -- BatteryStatsHelper needs to call on to
ConnectivityManager to find out of there is telepohny, however we use
that class when doing a dump while the battery stats lock is held. To
fix this, we check the connectivity state up in the battery stats service
before acquiring the lock and propagate that information through to the
dump code.
Change-Id: Ib452206af5c36f4b0f03cc94d2845d36613d1ba5
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| 0068d3dcf1f1a804554a1a09e3b173ac12651786 |
|
07-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue @16555033: Battery history overflowing too much
- No longer track process starts/stops normally.
- Increase buffer size to 256KB.
- Buffer size increase requires reworking how battery stats
are retrieved, since it is going to be hitting IPC limits.
- Also, store the last full stats after a reset, to be reported
at the next checkin.
- Also, discharge and charge times are tagged with the screen
and battery save state during that time.
Change-Id: Ie108ac9b626846108a9bb858101ac2b93276ac16
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| fee756ff91ab4d8f0e09ddb050d22d88ebb66ae7 |
|
17-Jul-2014 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #16330060: Inform ActivityManager about WebView...
...state changes.
Add a new API to tell the activity manager about a new dependency
one process has on another package. Start using it already for
when apps is Context.createPackageContext() to load code from another
app.
Also do some work on getting the monitoring of proc/uid states
in shape so it can be used by unundled code, along with an
AppImportanceMonitor class for doing so.
Some small fixes and additions to VoiceInteractionService.
Improve handling of unaccounted/overcounted battery use so that
they aren't shown to the user unless they are significant.
Change-Id: I22dd79a73f4e70103d3f8964494aebc8a31f971c
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| c3b07a0c9ce9b1a2af644112e678f3963226fad2 |
|
01-Jul-2014 |
Zoltan Szatmary-Ban <szatmz@google.com> |
BatteryStatsHelper.refreshStats for multiple users
Battery usage list is now populated for apps belonging to a list of users or profiles.
Change-Id: Ie899af74a4b3a0f3cd6ae3c93394f01f4f54a5c7
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| 61659e5daaea80104d4d0fd567e78b5f757b5df4 |
|
10-Jul-2014 |
Dianne Hackborn <hackbod@google.com> |
Add tracking of uid process states in battery stats.
We now keep track of how long each uid had processes in
various states: foreground, active, running. This is based
on a collapse of the various activity manager process states
into these three bins.
You'll see these in a checkin like this:
8,10013,l,st,61504,61504,83109
Also fix issue #16021555: App showing up as on "top" even
when the screen is off. This is "fixed" by just saying we
always report the current app at the top of the activity stack,
regardless of the state of the screen.
Change-Id: I1204904225101243eb00b43425d9806bffdd2ab9
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| abc7c499133fe640d6ece2b28d43b52e66cdaa9a |
|
01-Jul-2014 |
Dianne Hackborn <hackbod@google.com> |
Issue #15986092: Add power tracking of flashlight.
Not yet hooked up.
Change-Id: Id95e44ecc365e9f38169c0a629b0a48ddb29aa06
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| 2ffa11e4b71c545e34533ef827bdc1a07fbe8246 |
|
22-Apr-2014 |
Dianne Hackborn <hackbod@google.com> |
Start collecting mobile radio activity from the radio.
Hook in to the new radio API to find out when the radio
is active and use that to track its state in batter stats.
We also still have the data being tracked from the kernel's
emulation, and continue to use that if we don't get data from
the radio.
Currently this monitoring is turned off until some issues
in the radio can be fixed that are providing bad data.
Also add a new API to get estimated drain and charge times.
Change-Id: Ifc4900fabb8f848f9cda361dce698664ea75f175
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| 97ae538554e5d894774ddd55c266434ce1d67492 |
|
06-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
Formalize time bases in battery stats.
Battery stats used to revolve around a single time base
it maintained, "battery uptime and realtime." This is derived
from the system's uptime and realtime, but only increments while
the device is on battery. It is used to update its timers for
things like the screen being on, wake locks, etc only while the
device is not plugged in to power.
This change formalizes that time base into a separate class that
maintains all of its state. This is used to introduce a new
time base, "battery screen off," which only increments while the
device is on battery *and* the screen is off. Wake locks are now
based on this time base, so we don't count them while the screen
is on -- it is misleading to have them increment while the screen
is on because the device is defined to always stay awake anyway
during that time, so what they are doing is irrelevant.
Change-Id: I020e20c930d8dca2953c6c3ddef1dc93c24161a5
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| 77b987f1a1bb6028a871de01065b94c4cfff0b5c |
|
27-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Hold a wake lock while dispatching network activity events.
Also add new API for determining whether the current data network
is active, and thus better scheduling network operations. This
API is designed to not be tied to a mobile network -- regardless
of the network, apps can use it to determine whether they should
initiate activity or wait. On non-mobile networks, it simply always
reports as the network being active.
This changed involved reworking how the idle timers are done so
that we only register an idle timer with the current default
network. This way, we can know whether we currently expect to
get callbacks about the network being active, or should just always
report that it is active. (Ultimately we need to be getting this
radio active data from the radio itself.)
Change-Id: Iaf6cc91a960d7542a70b72f87a7db26d12c4ea8e
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| d45665bf0b26fddf5716a0fd43036848d9301960 |
|
26-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Collect per-uid mobile radio usage.
We now compute radio active time per application, by distributing
the active time across all applications each time the radio goes
down, weighting it by the number of packets transferred.
Per-app radio power use is now computed using this radio active
time.
This also gives us a new metric "ms per packet", which give an
idea of how effectively an application is using the radio. This
is collected and reported as a new set of stats in the human-
readable checkin. (It can be computed from the raw checkin data).
Also improve sync reporting to include the sync source as used
in wake locks, not just the component name.
Change-Id: I0b0185fadd1e47ae749090ed36728ab78ac24c5e
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| fb7b50a0263e500a6a8d2bbd7366b06d1fc91fe3 |
|
25-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix some issues with network usage in battery stats.
Change-Id: I8b354872511fcb55cecb2e09aada2eab41a1e202
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| e13c4c0b664dabdc069ca8f9601d96a337eb02f9 |
|
12-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Start tracking radio up time.
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
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| eaf2ac464b1cd741d7d0fe700771b1b7c00ddb29 |
|
07-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Battery stats: more events, fixes.
Add new history events for top application package and
foreground application packages.
Doing this involved a fair amount of improvement to history
events. The event code is now separated out to have "start"
and "finish" identifies, and we use that to now keep track
of which events are active. With that, when resetting the
stats, we can spit out all of the currently active events at
the front of the new history.
Also fixed some problems when I re-arranged the history delta
int bits that were conflicting with the packing of the battery
status bits. These packing structures are changed to work
together correctly.
Change-Id: Ic8b815060dd8a50ff4a0a209efc2e1044215cd88
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| 099bc627c463d9941e23e480f25a78a154429c55 |
|
22-Jan-2014 |
Dianne Hackborn <hackbod@google.com> |
Battery stats improvements.
- Adjust total power use when there is unaccounted power so that our
percentages don't end up > 100%.
- Fix accounting of isolated uids to be against the owning real app
uids.
- Rework how we put cpu use into the battery stats to no longer need
this uid name cache that can confuse the uid it is associated with.
- Finish implementing events in the history, adding a string pool and
reading/writing/dumping them.
- Add first two events: processes starting and finishing.
- Fix alarm manager reporting of wakeup alarms to be adjusted by the
WorkSource associated with the alarm, so they are blamed on the
correct app.
- New "--history" dump option allows you to perform a checkin of
only the history data.
- Fixed BitDescription bug that would cause incorrect printing of
changes in some states.
Change-Id: Ifbdd0740132ed178033851c58f165adc0d50f716
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| ae19a06e030e55b4db3cb20f1e564d49a78a395e |
|
17-Jan-2014 |
Dianne Hackborn <hackbod@google.com> |
Whoops, we were counting everything twice in the totals. :(
Change-Id: Ia8a5adec4db7d692691b2d7e471c446f963a5c21
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|
| a7c837f043c1ca0bdecd42645ba7da8c5717566d |
|
16-Jan-2014 |
Dianne Hackborn <hackbod@google.com> |
Add battery power use reporting to batterystats service.
Move the BatteryStatsHelper class (which computes power use based
on the raw battery stats) out of the settings app and in to the
framework. It is now used by batterystats dump output to print
the computed power information from its current stats.
This involved a lot of refactoring of the BatteryStatsHelper code
to remove all of the UI dependencies. I also did a bunch of cleanup
in it, such as making all power computations be in terms of mAh.
Change-Id: I8ccf2c9789dc9ad34904917ef57050371a59dc28
/frameworks/base/core/java/com/android/internal/os/BatteryStatsHelper.java
|