Since NetworkStats related code will be moved to the module.
multiplySafeByRational in the NetworkUtilsInternal cannot be
accessed after that. Thus, create another utils class that
will be moved with NetworkStats code and put the function
into it.
Test: atest NetworkStaticLibTests:com.android.net.moduletests.util.NetworkStatsUtilsTest
Bug: 204830222
Change-Id: I96f3ac02e57b7325ed53988285770f478dee529e
Revert "Suppress NewApi warnings for @SystemApi -> public APIs"
Revert "Add VpnServiceBuilderShim for VpnService.Builder"
Revert submission 1551943-vpn-impl
Reason for revert: <DroidMonitor-triggered revert due to breakage https://android-build.googleplex.com/builds/quarterdeck?branch=aosp-master&target=mainline_modules_x86_64-userdebug&lkgb=8007224&lkbb=8008168&fkbb=8007902 >, bug b/210979001
Reverted Changes:
I0e7aa077a:Add VpnServiceBuilderShim for VpnService.Builder
Ib12f5ab39:Suppress NewApi warnings for @SystemApi -> public ...
I59b9185cf:Unhide RouteInfo#getType and related fields
Ie5b62b2b2:Unhide IpPrefix(InetAddress, int)
I993a32d40:Add CTS tests for exclude VPN routes APIs
Ib24b2d3fb:Suppress NewApi warnings for @SystemApi -> public ...
Ic3b10464a:Add APIs that allow to exclude routes from VPN
Change-Id: I89209357ab4bb206d206adcf9fd6d3498ce6ef4c
BUG: 210979001
Current APIs does not include subId or phoneId to locate which
carrier network reported the change. A patch based on carrier
privilege were deployed in Q to temprarily fix the issue.
However, multiple subscriptions which all have the carrier
privileges will all get notified, even only one of them
has the real change.
To throughly resolve the issue, the subscription is introduced
in the API to distinguish which network actually has the change.
Bug: 131697791
Test: atest TelephonyRegistryManagerTest CarrierServiceTest
Change-Id: Ie7ee25f53da605c15e1a9228482cc8c4e7406d2a
This is a follow up CL to our previous CL [1], which had an off-by-one
bug when determining the return value of
EditableInputConnection#endBatchEdit().
According to the API document of InputConnection#endBatchEdit(), the
following test should pass.
EditText editText = new EditText(context);
EditorInfo editorInfo = new EditorInfo();
InputConnection editableInputConnection =
editText.onCreateInputConnection(editorInfo);
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isFalse(); // (*)
assertThat(editableInputConnection.endBatchEdit()).isFalse();
However, the last assertion marked with (*) actually fails due to an
off-by-one bug. This CL finally fixes it.
The risk of app compat breakages because of fixing this long standing
bug is supposed to be low, mainly because:
* the system has not relied on this return value yet.
* Widgets like WebView have correctly implemented this API.
* IME has always received true no matter what the app returned, which
is the same behavior as other async InputConnection APIs.
This CL adds several notes to InputConnection#endBatchEdit() document
to help developers correctly implement and use this API.
[1]: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
c478c171e9
Fix: 209958658
Fix: 210165648
Test: atest -c CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
Merged-In: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
(cherry picked from commit beda2b7f76)
Add new methods to VpnService.Builder that allow to specify network
routes that should bypass the VPN. Implemented by using RTN_THROW
routes.
Bug: 186082280
Test: atest HostsideVpnTests
Test: atest VpnServiceBuilderTest
Change-Id: Ic3b10464a53a8b56334589acec8f27acdc180ff7
This callback will allow privileged components to listen to changes
around carrier privileged apps in a way that is aware and accounts for
SIM profile switches. This callback will be backed by
CarrierPrivilegesTracker as a follow-up change.
Bug: 205736323
Test: atest android.telephony.cts.TelephonyRegistryManagerTest
Change-Id: I432ed00be16c68303bf5c8e074fb9d6cf83e82c9
In b/203198541, we start to compile standalone system server jars, but
the SELinux policy doesn't allow system_server to load the compiled code
at runtime. As a solution, this change creates class loaders for
standalone system server jars and caches them before switching to the
"system_server" SELinux domain, which essentially loads the jars and
compiled code into the memory.
Bug: 203198541
Test: manual -
1. Patch aosp/1874113, aosp/1876173, aosp/1906158 (in order to have
odrefresh compile a standalone system server jar).
2. Build a system image and flash it to a device.
3. Run "adb shell cat /proc/`adb shell pidof system_server`/maps" and
see "apex@com.android.wifi@javalib@service-wifi.jar@classes.odex"
being mmap'ed.
4. Run "adb logcat | grep avc" and see no denial.
5. atest odsign_e2e_tests
Change-Id: I27fbdaadae2b6f50989b4c534f7fbc80044a6685
Merged-In: I365be766cfb77c6e240d5871f1b3d8ed7abae6f5
(cherry picked from commit 281a2dfaa1)
This allows system_server to search/read tracefs entries. It is needed
for attaching cpu timeinstate bpf programs to tracepoints.
Bug: 208892266
Bug: 209513178
Test: libtimeinstate_test
Change-Id: I4139605eb7c5277887092b3d6a3fb26bf4f8f171
Read priv-app permission allowlists from APEX file and warn if
they're in the /system partition instead.
Test: boots
Bug: 190375768
Change-Id: I37d6deb60f0dffb75dd634075cd95bcf7ddf9684
Merged-In: I37d6deb60f0dffb75dd634075cd95bcf7ddf9684
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
