OkHttp recently changed the behavior of their caching with
commit e74e3f3bf744ef7f4d8ee724a7cf2347e486cfab - it is now
neccessary to close the inputstream (or disconnect the
HttpURLConnection) for a response to be cached.
This change is (effectively) a no-op prior to the upgrade.
The behavior is undefined as to whether closing the
input stream is required for caching. OkHttp's new behavior
is consistent with other HttpURLConnection implementations
tried.
Change-Id: Iaf57371651296ac84850971ef60a9338cead57c0
If the manifest doesn't specify large heaps, we now call
VMRuntime.clampGrowthLimit to release heap virtual address space
which won't ever get used.
Bug: 18387825
Bug: 17131630
Change-Id: I61fdcd70c70234256637eeebefe3abb22b91095d
mServer cannot set null, because string from resource always returns
non-null charsequence
Change-Id: I8d6a6fdbc34267ee361e7bd20719887268161870
Signed-off-by: Young-Ho Cha <ganadist@gmail.com>
When decrypting a device, a tmpfs is temporarily mounted as /data,
the size of which is usually small. When the zygote, system server
and necessary apps are brought up, they will be compiled into the
tmpfs.
If the system image contains prebuilts, they will be relocated instead
of compiled. This is unnecessary. In this special situation it is
acceptable to run out of the prebuilt oat files without relocation,
which can save space in the tmpfs.
This patch ensures that the boot image is not being relocated.
Change-Id: I42bfb7e3039574b7e4f2772e0d395f093d59ed1b
Signed-off-by: Hyangseok Chae <neo.chae@lge.com>
The --preferred-configurations option was renamed to
--preferred-density in fab5087 but only part of the
usage message was changed.
Change-Id: I89d270990023beca19605901d956d29d0b0b848b
toHex was changed to throw an exception in
I4986a8e806d9066129f696ab9f2e80655424e723, but its caller was not adjusted
accordingly, causing a crash whenever an unencrypted device was booted.
Bug: 18886749
Change-Id: If0505f617001cf5e0d99cf14c8b09e6a6a377167
CallStaticVoidMethod is varargs function, and calling it with
a literal 0 like CallStaticVoidMethod(..., 0) will treat the
argument as a 4 byte int in both 32 and 64 bit processes.
This is incorrect for pointer arguments where NULL should be
used instead.
Reviewed-by: Liao, Bruce <bruce.liao@intel.com>
Signed-off-by: Yong Yao <yong.yao@intel.com>
Change-Id: I9d700d3790a80dbee6826f64baf9ef5d81ca390f
Symptom:
Remain dead process record in mLruProcesses.
Root cause:
When a process dies and needs to restart immediately.
The process record will not be removed from mLruProcesses
in handleAppDiedLocked (return kept=true).
If the restarting process start timeout, the record in
mLruProcesses will not be removed.
Solution:
Call removeLruProcessLocked in processStartTimedOutLocked.
Change-Id: I1935ccc586016cb4e90dfdfac96cc88931553d5f
If width == height and mNavigationBarCanMove is true, the navigation bar
doesn't shows properly. Because wm doesn't know if the device is in landscape
mode or portrait mode.
Change-Id: I2077eacae50e6e498767f5c93b697e0459ad07fe
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Symptom:
Assume a foreground broadcast FG and a background BG.
If a recevier registers both FG and BG. When sending
BG and FG to the receiver, and the receiver BG receiver
completes first, its finishReceiver will trigger next FG
receiver rather than BG, and also deliver wrong result
code/data to the next.
More detail and sample:
https://code.google.com/p/android/issues/detail?id=92917
Root cause:
Due to BroadcastQueue:getMatchingOrderedReceiver will match
by receiver(IBinder), so the caller ActivityManagerService:
broadcastRecordForReceiverLocked will always match the first
queue(fg) if a receiver is both receiving fg and bg.
Solution:
Add a parameter flags to finishReceiver, then server side
could know the finished receiver should belong to which queue.
Another general solution but with bigger scope:
I60dce4a48e20c1002a61a979e4d78b9b0a8b94a0
Change-Id: I913ca6f101ac8ec6c7a8e42754e6781f80247b7f
"Some vendors have there own well defined specifications ...". Should be "Some vendors have their own well defined specifications ..."
Change-Id: I0d770ac0591812c1c61389eb0078493098784323
Signed-off-by: Paul Quei <paulquei@gmail.com>
ICU, zlib & openssl export them using LOCAL_EXPORT_C_INCLUDE_DIRS.
The dependency on libc/dns/include was bogus and can be removed
trivially.
bug: 18581021
Change-Id: I4b8047ff0df1050ab48b61c0c886888b3f2f0c18
Default values for class members mLac, mCid, mPsc would be 0.
Initialize these variables with -1 as 0 is considered as valid value.
CRs-Fixed: 406479
Change-Id: Idb3d1737c7101b97a90eab3dc7436ee1806d0bc4
* We now require that all certs used to sign the apk and all
certs stored with policy be tested for set equality. Prior
efforts required that the cert included with policy only
needed to match one of the certs included with an apk.
* Allowed a new tag to be included with policy describing the
signatures. <cert signature=""/> is now allowed as a child
element of the <signer> tag describing multiple certs. The
old way of describing signatures attached as attributes to
the root signer tag is still supported. The engine now treats
it the same as if they used the new layout with the outer
signature as the first signature value.
* Moved the class which holds all policy from an inner static
to a builder pattern governed by the Policy.PolicyBuilder
class. This will help provide more clarity and allow for
easier enforcement of certain invariants as the policy
representation is being built.
* Loads of new comments.
Change-Id: I38eb00ed8962fdef71bc9f2e7370cb910cadeff4
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
