b/21187932
Dependency from one kernel to another kernel -- where one reads the
other's output to a global allocation -- was not handled correctly.
This CL fixed that. Needed to make a new CTS test pass.
Change-Id: I500f9cac9d89bcaec7c186e942ba4a7d413daadb
(cherry picked from commit 85858718c0fc8f4f17ee18e5d62ec0614a8bc780)
Modified UTF-8 and UTF-8 differ with respect to how they handle
non-BMP characters. Modified UTF-8 uses 2 x 3 byte encodings, one
each for the high and low surrogate, whereas UTF-8 uses a single
4 byte sequence.
File systems don't specify and encoding and therefore the file name
encoding will vary depending on how it's created. All standard
Java APIs (java.io.File / FileOutputStream etc.) use Modified UTF-8
filenames, so we assume that's the status quo.
We will also audit code from the rest of the platform to make sure
that file names are encoded consistently.
bug: 21578056
Change-Id: I8e37af7f7cc442805a48899917f8e61c8f81fba6
We had a device where the touchscreen was reconfigured during system
init, and as a result was assigned a device id that was not 0.
The following message from InputReader.cpp was logged when this occured:
I/InputReader( 762): Device reconfigured: id=4, name='himax-touchscreen', size 1024x600, orientation 1, mode 1, display id 0
Attempting to use the input command for the touchscreen in this state
will fail due to the hardcoded touchscreen device id.
Change-Id: I4e8fad864e7b83cce00c680b254bad06e1200f15
If provided the extra entropy will be added to the device before calling
finish. If entropy is provided and the device does not support supplying
additional entropy then finish will fail with KM_ERROR_UNIMPLEMENTED.
Change-Id: If26be118bf382604f6f8e96e833b76e6f9e94d58
1. Also notify input is restricted or not when IKeyguardStateCallback callback is added.
When first Keyguard is showing after boot, the mInputRestricted is not updated. So,
inKeyguardRestrictedInputMode still returns false, although device is locked.
2. If mShowing remains false during setup time of KeyguardViewMediator, mInputRestricted
is not updated. This is because updateInputRestrictedLocked is called only if showing
value is changed during setup time.
For this reason, when device is not provisioned, inKeyguardRestrictedInputMode returns
false, and device does not restrict key.
3. If one of callbacks causes RemoteException, the other callbacks are not called.
This is because catching RemoteException breaks for-loop.
Change-Id: I0281405127bcc75285b908d01485da3ac9b40b52
Signed-off-by: Dooyoung Hwang <dooyoung.hwang@lge.com>
It was possible for a binderDied() call to occur while the death
recipient list containing the object was being iterated, in which
case we could invalidate an object reference out from under the
iteration, causing a VM abort. We now interlock the binderDied()
deref operation with the list's locking semantics to prevent this.
Bug 15831054
(cherry picked from commit 090c08ff2a7525c830b4edfd1a79aa8ee3893c60)
Change-Id: If0027d3ac4da1153284a425dd9b2819a203481ab
Commit a40d2447b6f516116135ee7f126579771ba98a2c made the
case consistently "as for the beginning of a sentence".
This updates the docs to reflect that. Previously the
result depended on the string returned (e.g. "Tomorrow"
was capitalized in English) and the casing varied
within and between locales.
Bug: 20247811
Change-Id: If4c6b3a13f61bd0cb64c82fc4c96d053130ae4c8
The comparator used variable "when" in IncreasingTimeOrder class.
variable "when" means "elapsed time" or "real time"(RTC) and these types have different unit of time.
so, I recommend that you use a "whenElapsed" which has the equal unit of time as its default value.
Change-Id: I248863ef8a5c49cc7114cb2965f3d6b78f4faa59
Signed-off-by: Jinho Park <jinho.park@lge.com>
Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.
bug: b/20849543
(cherry picked from commit 9e9e2e73c6ec7bece20268196dc89ad0c8bafad4)
Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
We don't dex2oat during application moves, so we must scan
the package again scanPackageDirtyLI to deduce its ABI.
This is unnecessary (since a move cannot change ABIs), but we
need some additional refactoring to avoid a second scan.
bug: 21337469
(cherry picked from commit cd251fa382e887f59c278d4d7cd0a858812c6114)
Change-Id: Id1ed3bdfabb41e05e6a2f7efbd05d2103a67c663
Allows us to proceed without crashing the system process. Also,
complete an incomplete error message. Follow up comments from
change b904863476991d8540d37d5.
bug: 21144503
(cherry picked from commit c52ae28006605fb2da38b305b60b9bb419aa2f80)
Change-Id: I47b8762449714162fcd5c16eba6fcc146b93120b
This requires a minor refactor to extract the ABI detection logic
out of scanPackageDirtyLI.
Note that there's a minor regression here : we ignore the
cpuAbiOverride from the package settings when calculating the
CPU ABI. This is OK (and possibly better behaviour) because this
is only a debug only option (for adb install) AND because the instructions
require users to specify the abi override on every adb install
invocation. Furthermore, the behaviour when an ADB installed app
(with an override) is auto-updated is more consistent.
bug: 21144503
(cherry picked from commit b904863476991d8540d37d542c0a49b78deab680)
Change-Id: I1eb88b808fd2e90e14c32322131659220aafdb7a
Currently installation fails, if an app is located on SD card (inside ASEC).
If an app is located inside ASEC, dexopt output should go to
/data/dalvik-cache. dexopt also needs to be performed at a later stage,
because the name of the oat file contains the absolute path to the dex file.
Bug: 20452651
Bug: 21360107
(cherry picked from commit 94056d1cb8183bde3e942336735b289b9654deb1)
Change-Id: Id1ced7159e5af9c05be0b637437b3b260e859c1d
Just above the SecurityException is a check for r.record == null,
thus dereferencing r.record will cause a null pointer exception.
Found in Android 4.3 with the following steps:
1) Start the music app.
2) Switch to the restricted user.
3) Navigate to Settings->Apps->Running->Music.
4) Tap the stop button.
The security exception should be thrown which results in
a nice message to the user, but instead a null pointer
exception is thrown which results in the settings app
crashing.
Change-Id: I4a306c38650c9d366896e592767dde70adb71c57
Adapt to Jack compilation specifics.
Fix bad import in VideoDumpActivity.
The extra semicolumn is ignored by javac because of
https://bugs.openjdk.java.net/browse/JDK-8027682 but is not
permitted by ecj or Jack.
This includes cherry-picks of the following changes:
248ef6f9c414db26fd1bc7ec3d4ee4f3b87d54cf
705555dc468e46560d02db102dfcedc1e5c70d9e
f50a51fb4c8d5ca973ce910a21bddf9f8466cb51
bf5ad8d9943c0e1b0b3f1b4524c277f369065d08
Change-Id: Ifbe063e3822a7d63b1681921b9788cfca898ba64
Crypto primitives' getSpi has a side-effect which modifies the state
of the primitive: it selects an SPI implementation if it hasn't been
selected yet (e.g., Cipher.getInstance("AES") doesn't select an SPI
implementation until Cipher.init). The new method getCurrentSpi has
no side-effects: it simply returns null if no SPI implementation is
selected. The switch to getCurrentSpi lets us avoid side-effects and
throw a more pertinent exception when no SPI is yet selected.
Bug: 18088752
Change-Id: I6d62eb67f904a15782673d16bcdae240cdc8f979
If user sets a non-secure lock screen, launch an activity which
appends window flag FLAG_DISMISS_KEYGUARD, then insert a PIN lock
SIM card, activity window will become black screen.
This is because mDismissKeyguard keeps on DISMISS_KEYGUARD_CONTINUE
when keyguard secure changes from non-secure to secure like in the
insert PIN lock SIM card case. If mDismissKeyguard is
DISMISS_KEYGUARD_CONTINUE and keyguard is secure, there is no chance
to launch keyguard unlock window anymore.
This patch handles the use case that to reset mDismissKeyguard to a
new cycle from DISMISS_KEYGUARD_START to DISMISS_KEYGUARD_CONTINUE
again once keyguard secure state change suddenly to let keyguard
window has chance to be launched.
https://code.google.com/p/android/issues/detail?id=78806
Change-Id: I0d4fd0b9bdf7d0a39f35427bfd4e1b928d9bca6b
Signed-off-by: tingna_sung <tingna_sung@htc.com>
