step1: PowerProfile.POWER_WIFI_ACTIVE represents energy consumption(mAh) per hour
devied by 3600, then WIFI_POWER ==> energy consumption(mAh) per second
step2: WIFI_BPS represents 1000000 bit per second
then (double)WIFI_BPS) / 8 ==> 1000000/8 Byte per second
step3: as upload and download, so divided by 2;
then (((double)WIFI_BPS) / 8 / 2048)) ==> 1000000/8/2048 KB per second
==> packet per second (where 1 packet = 2 KB)
so WIFI_POWER / (((double)WIFI_BPS) / 8 / 2048) represents mAh per Packet where 1 packet = 2 K.
when divided by (60*60) again , that make WifiPowerEstimator narrow 3600 times.
Change-Id: Ic055a5145b6dfb1129c8969826329a3024c9e2b6
Signed-off-by: yuanhuihui <yuanhuihui@xiaomi.com>
There is no functional change. This is to support adding new types of zygotes
that all operate using the same protocol.
Bug: 21643067
(cherry picked from commit 94e824bc1b)
Merged-In: Ie673ee816cae34ac20ffb8c774ec3e6461c3fd0a
Change-Id: I104e6133a90dc93a9854836b5e92d3cd542163a3
This is a non-functional change that separates out functionality
that should be shared between the system zygote and the WebView
zygote from that which is system zygote specific.
* Move MethodAndArgsCaller to Zygote.
* Split out server socket functions into ZygoteServer.
* Add a new (stub, for now) WebViewZygoteInit class.
Bug: 22084679
Bug: 21643067
(cherry picked from commit ba816e0c9e)
Merged-In: I4c508a42af7ab7b53d10570ad53b846df7782cc4
Change-Id: I54f04c03443d10dabe6426697d1ff8a0cc66b985
As Error Prone states:
Suppressing "deprecated" is probably a typo for "deprecation"
Bug: 27723540
(cherry picked from commit a7f834f1ce)
Change-Id: I0c6a9fc0a160769955cccf97ec7decb1f2b9b8fb
Using transitionTo in exit/enter (except in the terminal state) is
documented as undefined behavior and may cause unexpected results.
The current implementation appears to finish the current transition and
then transition to the new target state.
TEST=flash and play with the phone, no sign of immediate WTFs
Change-Id: I38a34b85c43d53c51514339587fc1269a069a454
(cherry picked from commit 8d3ed21583)
In order to make the tests run a few methods must be made public so that
they can be called from a class loaded by a different class loader.
Fixed: 28217358
Change-Id: I98ce1e952a78528ae6ebd3a0e843c9ddfe937337
(cherry picked from commit 36afe5b5cc)
Removed final from public sendMessage and sendMessageDelayed commands to
unblock unittest development. This allows tests to verify calls to
sendMessage and sendMessageDelayed.
Also fixed one checkstyle error with import order.
BUG: 28593024
Change-Id: I26e02c3d75049d385ded7891c4fc9967273c27be
TEST: builds
TEST: runtest frameworks-wifi
(cherry picked from commit 0dbeb9e01a)
Symptom:
When sharing an image from Album, ChooserActivity can be shown.
But then the app to be located to the bottom part of the list may not
be started even if user tap it.
Root cause:
ChooserActivity uses ResolverDrawerLayout. And ResolverDrawerLayout
can display only some items on the list (known as "Collapse mode").
When the item clipping along the bottom edge is tapped by the user,
ResolverDrawerLayout tries to expand the list and scroll it to a
better position, instead of starting an application.
In this problem case, ResolverDrawerLayout continues to try to expand
the list whenever tapping, so an application will never start.
Solution:
Change a condition so that mOpenOnClick becomes true only when the list
has been collapsed (mCollapseOffset > 0).
Bug: 30153542
Change-Id: I576fb6c8b6a91d79c1e0d46d069146779f4dbd17
(cherry picked from commit 4f3a843ea9)
Use application context to get the screen's display metrics.
Bug: 30127070
Change-Id: I2c453c494ef210c12d89fc7e3ff026728f9ecb0f
(cherry picked from commit afb38c5cc4)
Add the missing XML to byte array conversion method.
While there,
1. Fix writeByteArrayXml method to store the hex chars of the value.
2. Cleanup couple of error strings in |readThisIntArrayXml| method.
BUG: 29039296
Change-Id: I6386f7df7c5c8b7bc3bc5a268196da617209cea9
TEST: Compiles & manual testing.
(cherry picked from commit 651209b597)
commit efa6f355b06675aa4d0879fd279e22c16d5c046c
Author: Mikhail Naganov <mnaganov@google.com>
Date: Wed Aug 10 12:25:13 2016 -0700
MIDI: Use server-side socket in blocking mode for virtual devices
Since virtual MIDI servers may misbehave, blocking mode will throttle
them if clients are not coping with their sending speed.
Bug: 29413812
Change-Id: I9c4a2a7a7ea3ea060c93fedc7d0f033427c557c9
commit 755dfb5f83749d3963c63d98d692307f8271c804
Author: Mikhail Naganov <mnaganov@google.com>
Date: Fri Jul 8 13:26:19 2016 -0700
Protect MIDI framework against client blocks in MidiReceiver.onSend
Make the server-side socket non-blocking when creating MidiOutputPort
for clients. Thus if a client ceases to read from its side of the
socket pair, the server will just fail to write instead of blocking.
One drawback is that the MidiOutputPort on the client can't indicate
that it has become dysfunctional, but it's not possible without
changing the API.
Bug: 29413812
Change-Id: I9dfcbdd214a815cea8fd1365324fd78ca459268a
commit c740b13953761f58233ac651a0b5227733b1bdcc
Author: Mikhail Naganov <mnaganov@google.com>
Date: Fri Jun 17 04:11:25 2016 -0700
UsbMidiDevice: Clean up terminology and fix comments
When working with physical MIDI devices, an *input* stream is used
for reading from *output* port of the device, and vice versa. Thus,
using "input" and "output" without specifying whether it's a stream
or a port is confusing.
Clarify names of counter variables, and fix a couple of comments
that were incorrect due to this confusion. No functional changes.
Change-Id: If561eaca4bade94e9296d2c703c9fcebc91296e2
commit 4269c6417287737624f6165a8bbeb5aa427de9a0
Author: Glenn Kasten <gkasten@google.com>
Date: Thu May 5 18:49:16 2016 -0700
Update MIDI package summary
Bug: 28625060
Change-Id: If552ca8e1a0666d402b5f536699bf3fb09c1e324
commit 862d40b73168bde7d0be5280d997985c18061014
Author: Phil Burk <philburk@google.com>
Date: Tue Apr 19 15:56:24 2016 -0700
MidiDevice: do not open ports on closed device
Fix involves client side mIsDeviceClosed flag.
Bug: 24949216
Change-Id: I666284a787fbb9a710d2372fb424e8e54f6a2825
Signed-off-by: Phil Burk <philburk@google.com>
commit 6f1de358b9f2616e03f4655f01454770915ddd66
Author: Phil Burk <philburk@google.com>
Date: Mon Apr 18 16:05:28 2016 -0700
MidiService: fix resource leak
The proxy object was being used to match when adding or removing objects.
But they are different each time. So now we use an asBinder() object.
Bug: 28153736
Change-Id: I1bccebf1e9464668db757ff08b41902d0cf0e3a7
Signed-off-by: Phil Burk <philburk@google.com>
commit f7386bd535bb8a1d7f8df8f44a1748ab770c991a
Author: Phil Burk <philburk@google.com>
Date: Tue Apr 5 14:19:53 2016 -0700
MidiDevice: fix connectPorts for same Process
If connectPorts() was called for a device in the same process then
the connection would die when the ParcelFileDescriptor was closed.
Bug: 26406775
Change-Id: Id0538452593b4761ac2a93d366ade76d2e35ce73
Signed-off-by: Phil Burk <philburk@google.com>
Change-Id: I4dfc2a2cbaf04bf1a790ae2cb39bf74fb5bb16ac
Let RuntimeInit use an UncaughtExceptionPreHandler to log an exception
rather than relying on UncaughtHandler, which apps can replace. This
makes it easier to diagnose application death, especially during app
compatibility testing for a new version of Android.
Test: Verified manually, with the help of a small sample app (not
checked in), that stacktraces for RuntimeExceptions thrown on main
or background threads are logged even when the app set a default
UncaughtExceptionHandler that swallows the exception with no action.
Note that such an inappropriate UncaughtExceptionHandler will still
cause threads to die without the app being killed, which it should be.
In an exception then happens on the main thread, the app will freeze
until the ANR dialog kicks in after a few seconds. I have manually
verified that this behavior is unchanged from before this CL.
No new integration tests are included because the default system
behavior has not changed.
Bug: 29624607
Change-Id: Ie87377b0bcadc3ba4083a8ab1bedb8f3dd95a4bd
When "handling" an uncaught exception, make an attempt to stop
profiling. In case profiling was active, this will avoid losing
the profiling buffer.
This change is required as a base in order for
https://android-review.googlesource.com/#/c/249721/
to merge cleanly.
(Cherry picked from commit 4c79fea9ef)
Bug: 26291225
Change-Id: I35f352e5f28eafe4702da9eae587c3b65c360b3a
The when the timerfd alarm logic was added to the kernel, an oversight was made
and the interface does not check for the CAP_WAKE_ALARM permissions as required
via other kernel methods to trigger an alarm timer.
In v4.8-rc kernels, the change 2895a5e5b3a ("timerfd: Reject ALARM timerfds
without CAP_WAKE_ALARM") was added by Eric Caruso <ejcaruso@google.com>.
After this change (which may be backported to -stable), the AlarmManager will
fail on the first timerfd_create call, and will not be able to set the time
or handle other necessary functions.
The solution here is to add CAP_WAKE_ALARM to the system_server process.
Change-Id: Ifdb16f3ef42711e553f727165de3922d484b5be4
Signed-off-by: John Stultz <john.stultz@linaro.org>
Bug: 29586513
Also gives BackdropFrameRenderer a direct-destroy
of Choreographer since it's hammering on new Threads
and we don't want to wait for the GC to release
FDs.
Change-Id: Id2ec0af2ee4d5304961c4ab87a104ccb92f35fc2
The PowerProfile in BatteryStatsImpl may not be ready when
resetting stats early in the boot sequence.
Bug:29559031
Change-Id: I51bba762231a08804f1b68505bb1b0523476081d
