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>
We can no longer return the "my_downloads" paths: if those Uris were
shared beyond the app that requested the download, access would be
denied. Instead, we need to switch to using "all_downloads" Uris so
that permission grants can be issued to third-party viewer apps.
Since an app requesting a download doesn't normally have permission
to "all_downloads" paths, DownloadProvider now issues narrow grants
toward the owner of each download, both at device boot and when new
downloads are started.
Bug: 30537115, 30945409
Change-Id: I533125b36444877f54373d88922f2acc777e250b
Add TRANSPORT_WIFI_NAN - specifies a peer-to-peer Wi-Fi NAN data
connectivity request.
While NAN uses Wi-Fi L1 PHY and part of the MAC - it is a different
protocol and constitutes a different transport.
(cherry-pick of commit 7b84987a6a)
(cherry-pick of commit bd9fdbe022)
Bug: 26564277
Change-Id: I975ebc72d8f97a592d18038b3d6465b7a40efa75
getCurrentInputMethodSubtype() acquires InputManagerService.mMethodMap
within its body. There seems to be no reason for holding
InputMethodManager.mH to call getCurrentInputMethodSubtype(). Holding mH
can cause potential deadlock b/w two threads acquiring mH and mMethodMap
in different orders.
Bug: 31247871
Bug: 31273203
Bug: b.android.com/218423
Change-Id: I20cf2c20f49b1b02c0f7a18257b49d4bcc081b5d
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
Explicitly state that "local state" is local to the window
which has started the drag operation.
Bug: 31372686
Change-Id: Idbea7586c4e74097362067fa90390b97744181bb
As Error Prone states:
Suppressing "deprecated" is probably a typo for "deprecation"
Bug: 27723540
(cherry picked from commit a7f834f1ce)
Change-Id: I0c6a9fc0a160769955cccf97ec7decb1f2b9b8fb
The Fragments API guide was moved, but apparently a redirect was
never set up. Also, there are a few links to the old location in
the Javadocs.
Staged the revised Javadocs (see first comment for stage location).
Not going to stage the redirects file since it would trash another,
bigger CL that deals with the redirects file, but it's pretty
straightforward.
bug: 30559011
Change-Id: Ibd65f85c1ebb9789c1d40614fe11fe4ffda97e58