When empty the usap pool, the usap processes may be blocked by
usapPoolSocket.accept(), which cause the usap process fail to kill
immediately. So we can move the position of blockSigTerm after
usapPoolsSocket.accept() and delele the old blockSigTerm in the while
loop.
Test: manual test.
1.setprop persist.device_config.runtime_native.usap_pool_enabled true.
After 1 min, trigger fill usap pools.
2.setprop persist.device_config.runtime_native.usap_pool_enabled false.
After 1 min, trigger empty usap pools.
3.repeat step 1.
Signed-off-by: zhangjianqiu <zhangjianqiu@oppo.com>
Change-Id: I657940b30f71cdc717c673be6d70738e61e2bb68
This CL fixes a regression caused by [1] which introduced
<uses-native-library> tag [2]. With the change, public vendor libraries
[3] became accessible only when they are listed in the caller's
AndroidManifest.xml using the new tag. However, this caused a problem to
the places where AndroidManifest.xml doesn't exist: framework and
system_server classes. For those cases, [1] incorrectly used a null list
as the requested native libraries, and as a result, no public vendor
libraries were accessible.
This CL fixes the issue by not doing the filtering for the class loaders
created for non-app contexts like zygote or system_server. Specifically,
it uses the magic keyword "ALL" which let libnativeloader.so
accept all public vendor libraries.
[1] 6a5b8b1f6d
[2] https://developer.android.com/guide/topics/manifest/uses-native-library-element
[3] https://source.android.com/devices/tech/config/namespaces_libraries#adding-additional-native-libraries
Bug: 205164833
Test: libcuttlefish_fs.so is loaded when built with the other CLs in the
same topic
Change-Id: Id92c59642773851d70d05a05f43eb5873e9de86b
This is useful if/when it's desired that an application contains the same
fully qualified class name that's also in the library.
The shared libraries that are treated in this manor are controlled by the resource
com.android.internal.R.config_shared_libraries_loaded_after_app
Bug: 179429740
Test: atest SharedLibraryLoadingTests
Change-Id: Ia37ff9bd545918d1e0f1f38548dcd86f177559d5
APEXes can already contain RRO APKs by using the 'rro' apex Soong
module field. However, these RROs were not being loaded properly by
Zygote or PackageManagerService.
For all RROs inside APEXes, the RRO uses the same overlay config that
is used for other RROs on the APEX's preinstalled partition.
For RROs targeting 'android', which are installed by Zygote
using AssetManager:
1. OverlayConfig looks for active APEXes in the apex-info-list file,
which is already accessible to Zygote.
2. OverlayConfig passes the APEX module names to OverlayConfigParser,
for each preinstalled-partition.
3. OverlayConfigParser uses OverlayScanner to scan the
each /apex/<APEX>/overlay directory.
For other RROs:
1. PackageManagerService already parses and provides RROs inside APEXes
to OverlayConfig.
2. RROs inside APEXes used to have no config rule applied because their
path prefix (/apex/) did not match any partition rule. Now, their
preinstalled path is used instead.
Bug: 199200417
Test: Define a static RRO targeting 'android' inside a /vendor APEX.
Define a static RRO for settings provider inside a /vendor APEX.
Observe APEXes are enabled by default.
Test: Make a change to an RRO inside a /vendor APEX.
m <apex>; adb install <apex artifact>; adb reboot;
Observe change has taken effect.
Change-Id: I2bce9bc704789329b8c6aac6d476f17ff6718e0f
Merged-In: I2bce9bc704789329b8c6aac6d476f17ff6718e0f
If the lists of custom power components do not match, a crash will occur.
Instead of causing a crash, simply skip incompatible snapshots.
Bug: 196040329
Bug: 200511361
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryUsageStatsProviderTest
Change-Id: I87ba605371a5f3119dcff33f6109e94ee46ab57d
(cherry picked from commit a1ea9ecd56)
Whenever suspension conditions change, if there is a user-visible
suspension-related dialog, dismiss it to ensure the user is never
looking at stale information.
Bug: 169137795
Test: atest SuspendPackagesBroadcastTest#sendPackagesSuspendModifiedForUser
Test: manual (steps below)
-enable EBS, tap on suspended app to see dialog
-enable Focus mode, ensure dialog is dismissed
-tap on suspended app again to see relevent dialog,
disable Focus mode, ensure dialog is dismissed
-tap on suspended app again to see relevant dialog,
disable EBS, ensure dialog is dismissed correctly
-can permute enable/disable steps to further verify
Change-Id: Ib1650f910f7441498424ab4bc92185ce432ac405
(cherry picked from commit 25e73a8b9e)
Use the passed-in user instead of the current user to determine
whether or not to add the work profile badge to direct share
target app icons, so that personal share targets do not have the
badge (even when sharing something from the work profile) and
work/managed share targets do have it (even when sharing something
from the personal profile).
Test: manual; tested appearance sharing from personal->work and
from work->personal
Bug: 197388251
Fix: 197388251
Change-Id: Ieee50d46e8058a92efa5be8aae9859447531c270
Today's flow of events is like this: key goes to focused app
(ViewRootImpl::processKeyEvent), the view hierarchy does not handle the
event, so ViewRootImpl uses FallbackEventHandler to invoke the fallback
action for this key.
The problem is that for many keys the app itself is closing system
dialogs before taking the appropriate action (often launching an
activity, eg. dialer for KEYCODE_CALL), but this is now prohibited in S
due to abuse of said action.
The long-term plan is to return to InputDispatcher the fact that the key
wasn't handled by the app and have ID call out to the policy, which will
launch the appropriate action and adjust the UI as it sees fit (close
system dialogs).
However, we need to prevent apps from crashing because of this, hence
this change for S still. The unfortunate effect is that system dialogs
won't be hidden in these cases, but this livable with until we properly
implement the infrastructure.
Bug: 199173862
Test: Simulate code-paths with affected keys and make sure apps don't
crash:
1. adb shell input keyevent --longpress KEYCODE_CALL
2. adb shell input keyevent --longpress KEYCODE_CAMERA
Change-Id: I44ad41ac1eac9acc8320298ceb4c1b21bde8af5d
