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
Make the transport AIDL async and introduce a callback AIDL for passing
back results. A follow-up CL will implement the client-side portion of
the callback class and update BackupTransportClient to use it.
Bug: 202716271
Test: m -j
Change-Id: I79cb376bd2a805bf2739470a3f538207ae6bd9a0
This is a safeguard against cases like Bug 203086369, where the UI
thread can be locked up if IC#endBatchEdit() never returns false no
matter how many times it gets called.
With this CL, the system will have a max retry count on how many times
it attempts to call IC#endBatchEdit(), which is currently set to 16,
then fall back to InputMethodManager#restartInput(View) if it hits
such a limit.
This CL also introduces a volatile type cache to early fall back to
the fallback implementation if the same type of InputConnection
implementation class appears again.
As long as InputConnection#{begin,end}BatchEdit() is correctly
implemented, there should be no developer observable behavior change
in this CL.
See the corresponding test CL [1] about when the fallback
implementation is used.
[1]: Ifb80015ab0f0c32c917a80c4e5f60e836648e7b4
Bug: 203086369
Bug: 208941904
Bug: 209008342
Test: atest CtsInputMethodTestCases:InputMethodStartInputLifecycleTest
Change-Id: I109e0c26d8249fc2e01323e3e1cb36395fa7cc97
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
Migrate the following unsafe parcel APIs in framework-minus-apex:
* Parcel.readSerializable()
* Parcel.readArrayList()
* Parcel.readList()
* Parcel.readParcelable()
* Parcel.readParcelableList()
* Parcel.readSparseArray()
This CL was generated by applying lint fixes that infer the expected
type from the caller code and provide that as the type parameter
(ag/16365240).
A few observations:
* In some classes we couldn't migrate because the class also belonged to
another build module whose min SDK wasn't current (as is the case for
framework-minus-apex), hence I suppressed the lint check
(since I'll eventually submit the lint check to the tree).
* In some cases, I needed to do the cast in
https://stackoverflow.com/a/1080525/5765705 to make the compiler happy
since there isn't another way of providing a class of type
Class<MyClassWithGenerics<T>>.
* In the readSerializable() case, the new API also requires the class
loader, that was inferred to by InferredClass.class.getClassLoader().
* Note that automatic formatting and import rely on running hooked up
to the IDE, which wasn't the case here.
Bug: 195622897
Test: TH passes
Change-Id: I11a27b9bdab7959ee86e90aa1e1cbebd7aaf883c
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)
Thanks to this, we will be able to create a dashboard of the time needed to turn on the screen after unfolding the device.
Test: atest DeviceFoldStateProviderTest
Test: atest KeyguardViewMediatorTest
Test: atest UnfoldLatencyTrackerTest
Bug: 209963184
Change-Id: I078be6431e1053bd9658b5756ab2d54f6f28c630
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 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
