Add a Y2038 check into the time_detector and add infrastructure to allow
command-line testing to confirm it works.
This is before removing a Y2038 check from NITZ parsing code in the
telephony process. After this change, Androdi will consistently block
>= Y2038 suggestions, not just time signals that come in via telephony.
The initial checks attempt to limit the restriction to devices with
32-bit ABIs, since the main issue we're aware of is that time_t is a
32-bit signed int under bionic, hence there could be issues with that
type in 32-bit processes on 32-bit / mixed 32/64-bit devices.
Bug: 204193177
Test: adb shell cmd time_detector suggest_network_time --reference_time 2480587 --unix_epoch_time 1646473966056
Test: Run with 32-bit + 64-bit only builds, inspect adb shell dumpsys time_detector
Merged-In: Ib9d6472f5ca7a62d59b3224f1845846f99a0b52d
Change-Id: Ib9d6472f5ca7a62d59b3224f1845846f99a0b52d
This will be used to let the application thread
know whether or not to block for network rules to
be updated when coming to the foreground.
Bug: 226299593
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I9bff481a0026fb57af8dbee580e617c8410f9ebe
Merged-In: I9bff481a0026fb57af8dbee580e617c8410f9ebe
It's possible for an app to come to the TOP state before
the oomAdj computation is done and we cannot wait for
oomAdj computation to complete and then inform NPMS about
the state change. So, inform NPMS early about the state
change when we know the app is going to the TOP state.
Bug: 226299593
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I5d582618652cead179c419f7fe084283dd89d514
Merged-In: I5d582618652cead179c419f7fe084283dd89d514
When we know that an app moved to a procstate that is considered
an interaction event, the app will not be in idle state. So, avoid
calling into UsageStatsService for idle state in this case.
Bug: 209338078
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I5648db595d2fd10a151da13e472fd905bcafe182
Merged-In: I5648db595d2fd10a151da13e472fd905bcafe182
Update FLAG_ONLY_ALERT_ONCE docs to match implementation
from Android P and onwards.
Bug: 222328375
Test: atest BuzzBeepBlinkTest
Change-Id: Ic058b8265551362b04b9cd0363e43a4c08ecd736
Analysis:
1.Doing updateOomAdjInnerLSP in backgroud, and it would last for a long
time
2.Now start a new Activity, windowManager save the latest topUid into PendingStartActivityUids
3.updateOomAdj task in step.1 done, and then delete all uids in PendingStartActivityUids
4.The topApp will be rejected by AppOps due to the deleting in step.3
Signed-off-by: huang chaopeng <huangchaopeng@oppo.corp-partner.google.com>
Change-Id: I52c7c2a8d6cb86b27b1f008cb56f670ce7698dc9
Ethernet framework and service source code is going to be moved to
Connectivity mainline module, this CL contains below corresponding
changes to adapt the migration in f/b side:
1. Split out ethernet module-lib APIs to Connectivity module.
Add the ethernet resource filegroup to tiramisu-updatable-sources
filegroup as well, build them together. Also update the module-lib
and system api txt to reflect the APIs change. Remove the hidden
APIs which are moved to Connectivity module. This removal fixes the
api inconsistent issue with Tethering/apex/hidden/.
2. Remove EthernetService from SystemServer which will be registered
from ConnectivityServiceInitializer.
3. Replace the BackgroundThread class(imported from f/b/core/java)
with the one in the modules-utils-backgroundthread lib, which is
visible to Connectivity module.
Bug: 210586283
Test: m
Test: atest FrameworksNetTests EthernetServiceTests
Change-Id: I3e13cb9c0e348333af295c2537d459aa6700ff17
Merged-In: I1956848d3248cc56e9841d221e5e4c160bed65a4
Allow a list of configs to be sent for enterprise slice
Allow device owner to set enterprise slice config
Allow enterprise apn to be configured by profile owner
Bug: 217365439
Bug: 222723840
Test: ran CTS tests
Merged-In: I82c159843d0806cbfc5eea602fbd0304e7ff04ac
Change-Id: I82c159843d0806cbfc5eea602fbd0304e7ff04ac
This is more correct.
Bug: 218802673
Test: Compile only
Merged-In: Ic477c021529a94b4a3665426b7daaf6567fa311a
Change-Id: Ic477c021529a94b4a3665426b7daaf6567fa311a
NetworkStatsService is going to be moved into Connectivity mainlne
module and it will be not visible to SystemServiceResistry after
migration done. Thus:
1. Register service in NetworkStatsServiceInitialalizer, a separate
initializer is needed because the service needs to be created
before NetworkPolicyManagerService's initialization.
2. Call SystemReady at PHASE_ACTIVITY_MANAGER_READY phase where
it needs to be ready before StatsPullAtomService pulls at
PHASE_THIRD_PARTY_APPS_CAN_START.
3. Register manager in ConnectivityFrameworkInitializerTiramisu
instead of SystemServiceRegistery.
Test: atest FrameworksNetTests CtsNetTestCases NetworkUsageStatsTest
Bug: 204830222
(cherry-picked from ag/16688794)
Change-Id: I95020d816ed613ce3480a0720a5b71dcdc7fab72
Merged-In: I95020d816ed613ce3480a0720a5b71dcdc7fab72
Bug: 210890426
Test: Manual test with a test app, received this exception and
made sure cause isn't set.
Change-Id: I94ba39c775cf95074907db6814104289a577d496
Merged-in: I94ba39c775cf95074907db6814104289a577d496
(cherry picked from commit d4396b9a9d)
Merged-In:I94ba39c775cf95074907db6814104289a577d496
TrafficStats has static methods created in API level 8 that need
access to NetworkStatsManager but doesn't take a context.
Previously this was achieved by using ServiceManager, but
with TrafficStats moving to the connectivity module, this
is no longer possible.
Instead, make sure TrafficStats has an appropriate context by
the time any client code can call the relevant methods.
• In app code, this achieved by passing the application
context from ActivityThread#handleBindApplication, before any
app code can run.
• In the system server, this is achieved by passing the context
right after creating service.
Test: atest TrafficStatsTest CtsWebkitTestCases
Bug: 204830222
Change-Id: I251bb8a4431ad12ff61929879ef1363cf06b9244
This is an initial pass over frameworks/core to avoid WeakReference
get(), since that can cause the referent to be unnecessarily retained.
Most of these were found by searching for "get() == null".
Bug: 215259836
Test: Treehugger
Change-Id: I5227b05ca22e83b886ccf6713989961076df3f8c
This reverts commit f6a946bbcd.
Reason for revert: will deliver a better fix for that, ag/16580245.
Change-Id: I9c401b4cbded8753fc89df25a2c4f88a2fe72087
(cherry picked from commit aba1d77ff7)
Merged-In:I9c401b4cbded8753fc89df25a2c4f88a2fe72087
As CL[1] introduced WindowTokenClient for WindowProviderService (aka the
parent class of InputMethodService starts from CL[2]) as a token that
IME context can associate with the windowContainer of
the InputMethod window in server side. Like the activity context,
IME context can adopt configuration/resources update when the IME
window changed by display/window changes.
And, the IME context caller can also create another type of context
with wrapping IME context (i.e. calling createDisplayContext to create
a display context), that makes this context can be mixed the window
token of WindowProviderService since it's the base context.
However, the finalization of the context mixed WindowTokenClient
will detach the token when the attached context type is non-window
context, this action will mis-detach the token when it managed by
WindowProviderService.
So like SoftKeyboard previously using
createDisplayContext in CL[3] to workaround context resources issues,
will in-directly expose this mis-detach token issue as the above.
Beside, the handling of WindowTokenClient#{onConfigurationChange,
onWindowTokenRemoved} does not thread-safe since this is called from
IPC.
As the result, the fix is to ignore the check in ContextImpl#finalize
to not detach the token when it managed by WindowProviderService,
also make sure to post to the main handler when received
onConfigurationChanged/onWindowTokenRemoved in WindowTokenClient.
Note that this fix could help to resolve "The Window Context should
have been attached to a DisplayArea." exception if the token has been
detached as the above case that happens before the next
WindowProviderService#attachToWindowToken invoked.
[1]: I64a1614f32d097785915f6105b1813a929e0fe32
[2]: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
[3]: Ic592a1d2fb2da149220c8b503b522b3e864bcc77
Bug: 213118079
Bug: 211062619
Test: manual as steps:
1) adb install -r EditTextVariations.apk
2) adb install -r SoftKeyboard.apk
3) adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
4) adb shell ime set com.example.android.softkeyboard/.SoftKeyboard5
5) Enable screen auto-rotation
6) Launch EditTextVariations from launcher's shortcut
7) Tap the first EditText field to show IME
8) Rotate the device to the landscape mode
9) Expect the IME should not be shrunk
Change-Id: I7beb7a122af93e596239a36db62073233cea0726
Revert submission 16468379
Reason for revert: Feature development is moving to T.
Reverted Changes:
Id9b9a8930:[3/n] Camera Compat UI: Add a camera compat contro...
Id6be4a954:Enable a camera app compat control on Large screen...
I083aa6718:[2/n] Camera Compat UI: Add interfaces for client-...
Bug: 206602997
Change-Id: I9ad876043fd61f708a8f468fffd1ef371bfa0866
postOnAnimation is not robust enough from remove the onDrawListener
before next traversal, add a flag to to ensure that transfer splash
screen view only been called once.
Bug: 204125440
Test: atest SplashscreenTests
Test: verify SplashScreenTests and SplashscreenParametrizedTest pass
Change-Id: Id0e6d57b901b2dae45f5aa77e5571f9cf81b6e29
Changes:
- Listens to changes from the client coming through IActivityClientController#requestCompatCameraControl to ActivityRecord#updateCameraCompatState
- ActivityRecord#updateCameraCompatState sends updated state via TaskInfo to WM Shell
- ITaskOrganizerController#updateCameraCompatControlState to dispatch the user interactions with the control from WM Shell triggers callback to ActivityRecord#updateCameraCompatStateFromUser
- ActivityRecord#updateCameraCompatStateFromUser remembers the user's choice and asks client to apply treatment through ICompatCameraControlCallback
Feature is guarded with config_isCameraCompatControlForStretchedIssuesEnabled
Test: atest WMShellUnitTests:ShellTaskOrganizerTests, atest WmTests:ActivityRecordTests
Bug: 206602997
Change-Id: I083aa6718bd67456bedd9444e9b78740c041f870
This is a short-term workaround to dump error log instead of throwing
the exception to unblock the test.
Bug: 209744518
Test: build pass
Change-Id: I2ece3b9d85edc1ae43038e6f69b35f59b160a3dd
(cherry picked from commit f8fc1326f7)
