It's difficult to identify native crash/error of 3rd party app.
Because they can control their app with own signal handling.
Therefore I would like to support the way to ignore signal
registration in 3rd party app with the specific property.
To enable this, do just setprop "debug.ignoreappsignalhandler 1".
Test: test app to hook signal, then setprop debug.ignoreappsignalhandler 1
Merged-In: I2af98a0f58e5ac039eab0ebe9c3780357aca7820
Exempt-From-Owner-Approval: Cherry-pick
Change-Id: I2af98a0f58e5ac039eab0ebe9c3780357aca7820
Signed-off-by: randy.jeong <randy.jeong@samsung.com>
(Goodbye, hypno-P and your '90s tech magazine color palette.)
Bug: 123903304
Test: adb shell am start -n android/com.android.internal.app.PlatLogoActivity
Test: adb shell am start -c com.android.internal.category.PLATLOGO -a android.intent.action.MAIN
Test: adb shell am start -n com.android.egg/.paint.PaintActivity # still works
Change-Id: I4865024a14b6a78e7a043c56d2330b5f9dd214c6
Merged-In: I4865024a14b6a78e7a043c56d2330b5f9dd214c6
Users are incorrectly being directed to the settings app when
selecting 'Always', making them unable to actually open an app through
the resolver.
Bug: 132071949
Test: Steps are reported in b/136451610
Change-Id: I11775d7b0b780195f08273ad2b90b8ecd2ee1db4
When mutiple apps share shortcuts and are given to the UI to display,
the ranked order from both the App Prediction Service and the legacy
ranker is inadvertently being discarded. This means that targets the
user almost never uses will now be shown as high priority, causing
confusion and pretty horrible user experience.
Address the issue by adding in a score for shortcuts, based on the
index in the ordered list.
Bug: 136201796
Test: atest ChooserActivityTest and manually compare results from
AppPredictionService to verify order is consistent
Change-Id: I1fe2c2d2e13195f6f6c3a5818fade4844c15488e
In Q, these APIs were either:
- removed from the greylist entirely without good reason
- Moved to the restricted greylist without any public alternative
information added
So they are being moved back to the greylist for Q.
Test: Treehugger
Bug: 136102585
Change-Id: I5ac8b8b9b23c3789d80239cf456072cc7dfa1203
When a URL is detected and all resolved targets are browsers, allow
the user to set a default browser from the Resolver. If one of the
options is an App and not a browser (as defined by
ResolveInfo.handleAllWebDataURI) then direct the user to the settings
page where they can make changes to set the default app for particular
URLs.
On the settings page, highlight the correct setting to change so it's
clear to the user.
Bug: 132071949
Test: Manually resolve URLs with multiple browsers and apps like Reddit/Twitter
Change-Id: Ib8f867a020ecfbb73fa5f1d7db84890c72e4842d
...because only invalidating the root window node will ensure that
onPostDraw() will be called again.
Test: Open com.planeth.rhythm
Fixes: 135207159
Change-Id: I03f814eb7435d91287968f3dcb72f579ab4a35ed
collection to SystemSuspend (ISuspendControl::getWakeLockStats())
Native wakelocks obatined via SystemSuspend when useSuspendCounter is
enabled, will not be reflected in the information available from
/d/wakeup_sources or proc/wakelocks. This information has been
made available via the ISuspendControl AIDL interface of SystemSuspend.
Kernelwakelock stats however are still being collected in the
/d/wakeup_sources.
Change-Id: I208d004aa0fabcf367016faae77ad51388cdf0ea
Bug: 135680393
Test: Observe SystemSuspend service wakelocks in dumpsys batterystats (for
instance, "PowerManager.SuspendLockout"):
`dumpsys batterystats --checkin | grep wl | grep PowerManager.SuspendLockout`
Also adds a phenotype flag to enable handles in the learned state once
per day.
Test: Tested locally
BUG:132983599
Change-Id: I21e422382e62ee098cd6ff76d6b764db98be0cb7
Merged-In: I21e422382e62ee098cd6ff76d6b764db98be0cb7
