EntropyMixer is designed to be triggered in two ways, as either the
result of a self-set timer or of one of three system broadcasts. It is not
meant to be triggered in any other way, so exposing it via servicemanager
is undesirable.
Bug: 18106000
Cherry-pick of commit: 9287e0dd272b85b475e33bcbd7d868517a0f98f9
Change-Id: I9aeb35e7ffde75090f4234ea193514fb883b1425
Two broadcasts could be sent to the same app simultaneously:
one foreground, one background. For example, LOCALE_CHANGED
and PACKAGE_CHANGED are delievered to com.android.vending
at the same time.
1. AMS started new vending process to handle LOCALE_CHANGED.
And set app.curReceiver = LOCALE_CHANGED.
2. Before LOCALE_CHANGED is handled by vending process,
PACKAGE_CHANGED was delievered to vending process too.
AMS set app.curReceiver = PACKAGE_CHANGED. Bad!
3. Vending process finished handling LOCALE_CHANGED.
AMS clear app.curReceiver = NULL. Bad!
And Vending process killed itself without handling
PACKAGE_CHANGED.
4. AMS known vending process has died, but didn't know that
BgBroadcastQueue was still waiting for finish message
for PACKAGE_CHANGED.
At last, BgBroadcastQueue reported ANR for PACKAGE_CHANGED.
This patch adds protection before clearing app.curReceiver,
only set to NULL if the finishing receiver = app.curReceiver
So handleAppDied would know that PACKAGE_CHANGED was not
finished yet, it will abort the broadcast and continue.
Change-Id: Ic4f31b35e21823d4a3c27712391ecbede213a494
Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>
When an app is moved from "/system/priv-app" to another location
during OTA update, the privileged flag should be removed.
Change-Id: I7713382db34697f7b68283dbbbd25a1349cbecdb
If an activity show a Presentation window and this activity is moved
to bottom or top, thus this Presentation window will be removed from
its display window list, and no chance to be added back into window
container; It will cause the incorrect state that Presentation window
is lost from secondary display window list(displayContent.mWindows),
but still exist in app token's window list(appWindowToken.allAppWindows);
Moreover, once this activity resume again, Presentation window is not
shown because it's lost.
In this way, don't remove non-target display app windows due to only
target(or called default) display windows are removed temporarily and
re-sorted then added back into window list later.
Change-Id: I8960ce191f6c662455cba5a0a5e6a1ff9ef03ae1
Signed-off-by: tingna_sung <tingna_sung@htc.com>
Update focus stack frame/layer when focus app is changed to avoid
focus stack/layer isn't updated synchronously with focus app, it's
due to performLayoutAndPlaceSurfacesLocked() is not necessarily
called on focus app change; it will cause sending mismatching
TAP_OUTSIDE_STACK message if there is effectual incoming pointer
event, hence may also result in focus stack is changed again,
therefore erroneous focus app is set by ActivityManager at final.
Change-Id: Ia0ec9a543be887b51a3b29b3e62fdd471c15edf2
Signed-off-by: tingna_sung <tingna_sung@htc.com>
Extend the fullscreen meaning by adding opaque drawn check on
screenshot application; if there is a fullscreen window but not
opaque, we will continue finding behind windows; otherwise ending up
including behind windows. It's able to help avoiding capturing BLACK
screenshot bitmap.
Change-Id: I1c7e8f513c366688ea8001c3d0c799f3522f0ffd
Signed-off-by: tingna_sung <tingna_sung@htc.com>
If pointer is moving to the negative axis direction, pointer movement
distance will always less than pre-defined mMotionSlop, thus
TAP_OUTSIDE_STACK will have chance to be sent, will cause unnecessary
focus stack switch.
Change-Id: Ia4c066bebce250257c7361ef976907a0ca2c6461
Signed-off-by: tingna_sung <tingna_sung@htc.com>
Update DisplayContent.mBaseDisplayRect when device orientation is
changed, it avoids to set incorrect initial value of
mTouchExcludeRegion, that will cause result of calculated
mTouchExcludeRegion becomes an incorrect strange region on
landscape orientation.
Change-Id: I993864653edc2852f91abed7891e6631b4bae15a
Signed-off-by: tingna_sung <tingna_sung@htc.com>
When destroying CanvasContext, the surface can be invalid
state. So the surface should be updated to null prior to
destroying GL resources to ensure that GL functions
are not called with an invalid surface.
Some GL implementation makes an error if GL functions
are called with an invalid surface. (Adreno 3xx)
Change-Id: Ie6f6ea081ec931fc9df30b2c3ed066ec1ae9d294
By design, if the user presses the power key twice within 5 seconds
(panic), it will show immersive confirmation again at the next time
entering immersive mode.
But there is a bug on calculating the time between pressing the power
key. The time get from event.getDownTime() will stop when the device
is sleeping without being charged.
So here uses SystemClock.elapsedRealtime() instead.
https://code.google.com/p/android/issues/detail?id=80772
Change-Id: I4dca9dc260904f1c5b60464834781e2a82a9bcf4
(This is an update after the generator update.)
Both EGL14 and EGLExt have the same initialization codes for
EGL14.EGL_NO_SURFACE, EGL14.EGL_NO_CONTEXT and EGL14.EGL_NO_DISPLAY.
Since EGLExt is initialized later, they are overwritten by EGLExt's
initialization codes.
Therefore, EGL_NO_SURFACE returned by methods in EGL14 is not
actually EGL14.EGL_NO_SURFACE object and it makes several problems in
handling error cases.
For instance, "Let's fish" game application cannot be run on L.
To solve the problem, this patch makes EGL14.EGL_NO_SURFACE,
EGL14.EGL_NO_CONTEXT and EGL14.EGL_NO_DISPLAY initialized just once.
Change-Id: Icce878164ff0b715ad2b5a2cd038a9616c7cf1e9
Don't refer to classes as structs and view versa -- causes warnings in
clang (in code built with -Werror)
Change-Id: I4d7f461bcf6fe4e43a14ad2f28ee0e0ddea95abc
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
The return value of jniRegisterNativeMethods is checked only in
LOG_FATAL_IF, which defines to nothing in the LOG_NDEBUG
case.
Fake a use of the 'res' variable to shut off warnings when LOG_NDEBUG.
Change-Id: I8263610f327c56897f76796fe1fbc2b325b0559f
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
