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
OnComputeInternalInsetsListener is added when initViews is called,
and initViews is called by onCreate and onConfigurationChanged.
But it is removed only by onDestroy.
Therefore listeners are accumulated and it results performance issue.
So before adding, remove mInsetListener that was previously added.
Change-Id: I494d3f1875613d73d3f9b8e2af286b5800f03196
The secondary Abi is for the apps which support the mulitArch feature.
In presence of a native bridge the instruction set supported by
secondary Abi might be different than the one secondary Abi used.
Change-Id: I318fb21e45c34de6cf1bf8ff63519aaa2b1e2520
Signed-off-by: jgu21 <jinghui.gu@intel.com>
The Deutsche Telekom “Mobilbox Pro” App (Visual Voicemail) uses SMS for
provision, these SMSs are free to the user, so the premium SMS notification
creates confusion. To avoid this notification, DTAG has harmonized two
short codes in Germany, 81214 and 81215, which are free in all German mobile
networks and should be whitelisted. Once whitelisted, these 2 codes will be
used by the client.
Change-Id: Id981b1d7abf83c2dc4a5846aa8a40b37e2e12409
Signed-off-by: Marcus Mueller-Jung <marcus.mueller-jung@telekom.de>
Adjust format strings to not produce Clang warnings in both 32-bit and
64-bit builds
Change-Id: I76c29d8d5d0fb4b5e9d9518077652370ffe9e871
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
These strings only ever end up in logcat (at best), so there's no
point having them translated. Also, rename the ErrorStrings class
and move it android.webkit where the last remaining caller lives.
(congrats webview people, this is now your mess to maintain.)
Change-Id: I04dae37c34191b26a69282970318c1b782af1edf
Move the code to the only point of use. Preparatory work for
decoupling apache-http from the frameworks.
Change-Id: Ieee54bb725cbac19d0c7513867635df6fbcf2b49
