Surface some of this information in BatteryStatsHelper. If we are given a
total energy from the WiFi controller, we normalize the computed
energy of each app and blame them for a fraction of the real energy.
Change-Id: I64051b600f5d9f6ac4580d56ef0977971eb4be2d
Converted all compat references to native implementations. Removed all
backwards compatibility SDK version checks.
Bug: 19431364
Change-Id: Ia79ed65bd2d041e4c0de6839b64707b9dba3ac22
SELinux guarantees that only the system_server and permissive domains such as su
are allowed to connect to the zygote socket. Remove obsolete security checks
that were only applicable when other processes could connect.
Bug: 19624279
Change-Id: I1c925d7facf19b3953b5deb85d992415344c4c9f
Issue #19431959: Framework incorrectly assumes that kernel
clock_ticks are 10ms
We now retrieve the time of a jiffy from the kernel, and all CPU
times are now handled in milliseconds.
Issue #19571810: Add per-app breakdown of number of WiFi scans
in batterystats checkin data
Added to the report (the information was already being tracked).
Change-Id: If1702d6b9bcf851704129f1811471e68ed576a5d
Not yet working, unless you turn off SELinux enforcing.
We need to update SElinux to allow the system process
to give apps access to /data/system/heapdump/javaheap.bin.
Currently watching can only be enabled through the shell,
such as:
adb shell am set-watch-heap com.android.systemui 1024
The last number is the process pss size in bytes, so this is
asking us to warn if it goes about 1K which will be all the
time.
Change-Id: I2089e5db2927afca0bf01a363c6247ee5dcb26e8
We are correctly refusing to actually process apps for backup if they have
declared android:allowBackup="false" in their manifests, but we're still
wasting bookkeeping & a certain amount of work in tracking them as part of
the full backup queue. Fix that; now we recognize that they shouldn't be
in the queue in the first place.
When reinflating the queue at boot time we also re-verify the participation
of each mentioned app so that we properly drop ones that have been uninstalled
or altered such that they are no longer full-data backup candidates.
Finally, if an app previously implemented key/value backup, so we think
we'll be running it in that mode in a future backup pass, but has been
updated to use the full-data path instead, we don't want to go ahead and
run a key/value pass on it. Added a backstop check and proceed gracefully
in this situation.
(Also add bit more debug-build logging to LocalTransport)
Bug 19462310
Change-Id: I07ab4f2e68e92766d9e8f2595fa763c91193d743
Currently is only used for tracking the daily charge
and discharge rates. We keep up to 10 days of data.
Change-Id: I54e29e35ff60d9277da9e476cdab22f4a6d540bf
Refactor the ActionBar handling of startActionMode to allow handling by
the ActionModeWrapper, using the previously created infrastructure.
Things pending after this CL:
- Representing the floating type
- Supporting two ActionModes in parallel in DecorView, one of each type
Change-Id: Ic126e004bdef5d91d8be3d6a07eea34aa97a611e
- iconTint and iconTintMode attrs for MenuItem, with
associated setters.
- navigationTint and navigationTintMode attrs for Toolbar
with associated setters.
- overlflowTint and overflowTintMode attrs for Toolbar
with associated setters.
BUG: 18126050
BUG: 19148351
BUG: 19305408
Change-Id: Ibd1fae7cdbc7a7c42809e52541fae5d8beb18e92
Adds support overriding default alert dialog panel elements by including
them in the dialog's custom content view, but no public API (yet!) since
the panel IDs have never been public. Some minor cleanup and refactoring
in TimePickerDialog. Removes Holo styles for "clock" and "calendar" style
pickers since they are new in Material. If the new styles are used against
Holo they will match Material but with Holo primary/accent colors.
Also implements themed color state lists to resolve TODOs in both time
and date pickers.
Bug: 19431361
Change-Id: I095fd8d653e02d9e5d20d66611432a08a7a5685e
We now have a formal concept of the session being shown and
hidden, with it being able to continue running while hidden
as long as there is enough RAM.
This changes the flow that a VoiceInteractionSession will
see: onCreate() is when it is first created, onCreateContentView()
is when its UI first needs to be built, onShow() is called each
time it needs to be shown and has the arguments given when the
show request was made (which has been renamed from startSession to
showSession), and then onHide() will be called when the UI is
no longer shown.
The methods show() and hide() now allow a VoiceInteractionSession
subclass to control when it is shown and hidden, working with the
shown state being maintained by the system.
Change-Id: Ic4a430ec7e8bf76a5441fd0425e2932806170fcc
- When the flag changes, apply an animation from the current value
- When the flag change is caused by an app transition, synchronize
the status bar animation with the app transition animation.
PhoneWindowManager calculates the timings based on some heuristics
of the app transition animations and supplies these timings to
StatusBarService.
Bug: 19233606
Change-Id: I4f99afba8f1eebb3524699ed4d7fbafee5463a37
This is a follow up CL for I7d932e60311b80c05be8f02c9e803f18da0e0054,
which revealed that we could not use deprecated 2-letter code like "in"
to query subtype which has new language codes like "id".
This CL addresses the above issue by normalizing the language code
with Locale#Locale(String, String) before comparing one to another.
Change-Id: I26e3aa0333aa3c76c80a3c1c9090cc2b368c8e10
This CL adds several unit tests for following CLs, both of which enabled
InputMethodUtils (and dependent IMF logic) to handle 3 letter language codes
and conversion from deprecated two-letter codes to new ones correctly.
- Ibb9eb9f65323795d139b16d76b7e7e36a4e0568c
- I6571d464a46453934f0a8f5e79018a67a9a3c845
As described in tests, the input method framework has already been able to
recognize 3 letter language codes. However, there remain inconsistencies
when we use deprecated 2-letter code to query subtype like "in" but the
subtype has new language codes like "id". Subsequent CLs are supposed to
address remaining issues.
bug: 10090157
Change-Id: I7d932e60311b80c05be8f02c9e803f18da0e0054
Every time the battery level changes, a new extended
detailed use data structure is written to the history.
This currently only contains delta CPU use since the
last detailed entry (total CPU and to three uids), but
it gives us the infrastructure for adding more detailed
data in the future.
A detail entry for regular history looks like:
Details: cpu=15730u+2307s (u0a57=11312u+502s, 1000=2344u+701s, 0=473u+991s)
/proc/stat=15377 usr, 1797 sys, 197 io, 0 irq, 8 sirq, 23103 idle (42.9% of 6m 44s 820ms)
u is user-space cpu time, s is system/kernel time.
The equivalent check-in output is:
9,h,0,Dcpu=15730:2307/10057:11312:502/1000:2344:701/0:473:991
9,h,0,Dpst=15377,1797,197,0,8,23103
Also add a new "unplug" command to the battery service,
to easily put it into a state where it always considers
the device to be running on battery.
Change-Id: Ic76d966f11e592b9dd671879977bf999ebc11eef
This CL defines a new interface to be used by ActionModeWrapper.
This allows each client to inject a different primary ActionMode to
the wrapper and keep view creation code next to ActionMode
creation.
The interface method is only called when the wrapper actually
knows that will be the used type, avoinding unnecessary view
creations.
Things pending after this CL:
- Correct handling of ActionModes created by
callback.onWindowStartingActionMode(). This includes all current usages
in an existing ActionBar, as it is handled by Activity. In the current
state, we do not intercept these ActionModes and hence cannot change the
representation.
- Representing the floating type
- Supporting two ActionModes in parallel in DecorView, one of each type
Change-Id: Ic38e209877c3876161d8dd56902e25b51fbe40b6
This change will allow us to create ActionMode representations on the
fly after onCreateActionMode by using the Decorator pattern. The new
ActionModeWrapper will be responsible for the creating the
appropriate ActionMode depending on the type chosen by the client,
and setting it up.
Things pending that are NOT addressed by this CL:
- ActionModes created by callback.onWindowStartingActionMode(). This
includes all current usages in an existing ActionBar, as it is
handled by Activity. This requires some additional refactoring.
- Representing the floating type
- Moving the view creation code specific to StandaloneActionMode
from DecorView to ActionModeWrapper, decoupling DecorView from
StandaloneActionMode completely
- Supporting two ActionModes in parallel in DecorView, one of each type
Change-Id: I1a8db711f53b771eac74f0e6496106acf1ca2727
