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
All below cases should return to home but the top will be Settings.
The initial steps are
1.Launch Settings from home
2.Press home key
3.Launch activity A in task X from home
Case 1
4.A starts activity B in task Y and calls moveTaskToBack
Case 2
4.A starts activity B in task X and calls moveTaskToBack
5.B calls finish
Case 3
4.A launches activity B in task Y
5.B launches A with NEW_TASK (bring existed task)
6.A calls finish return to B
7.B calls finish
Case 4
4.A launches activity B in task X
5.B launches C in task X
6.C launches A with flag NEW_TASK and CLEAR_TOP
7.A calls finish
Solution:
Transfer return-to to next adjacent task.
Change-Id: Icdad980eec64e081d15679600da07cf4431e40d6
* 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>
Symptom:
Watchdog timeout.
Reproduce code:
String action = "lets.deadlock";
Uri baseUri = Uri.parse("content://i.am.bad");
Uri uri = ContentUris.withAppendedId(baseUri, 1);
Intent intent = new Intent(action, uri);
sendStickyBroadcast(intent);
IntentFilter filter = new IntentFilter(action);
filter.addDataScheme(baseUri.getScheme());
filter.addDataAuthority(baseUri.getAuthority(), null);
filter.addDataPath(uri.getPath(), 0);
registerReceiver(null, filter);
In target provider's getType:
Invoke AMS function will result deadlock.
Or sleep a long time will also trigger watchdog timeout.
Root Cause:
If broadcast is sticky with content scheme intent.
Register receiver will trigger access provider when
matching intent with IntentFilter, and it executes
in ActivityManagerService's lock.
Solution:
Obtain necessary data to local to split lock block.
Change-Id: I0fb94472cdc478997e40ba2a60a988c5f53badb2
Symptom:
The ActivityRecord's waitingVisible is not set to false for
all cases when the ActivityRecord is removed from
mStackSupervisor.mWaitingVisibleActivities.
Solution:
Set the waitingVisible to false when it is removed from
mStackSupervisor.mWaitingVisibleActivities
Change-Id: If0f0683971d70a6866b0167e91dd95feebaac178
Copy region from DisplayContent.mTouchExcludeRegion instead of
directly refer to the same object of DisplayContent, and able to
protect it by lock of self class, don't have to lock out mWindowMap
on every tap.
This fix is to avoid racing condition of mTouchExcludeRegion.
Change-Id: I7401968167c2e539b4da2afe71e3020038fbfcbf
Signed-off-by: tingna_sung <tingna_sung@htc.com>
