Tests need to be able to compare partial log structures.
Bug: 34705522
Test: runtest --path frameworks/base/core/tests/coretests/src/android/metrics
Change-Id: I4e26e43f5f5ea3fbba5a2a2a9563982c7260671b
This adds new flag to virtual display that changes its
behavior when keyguard is shown, but can be dismissed without
entering credentials. This can be applied only to private
virtual displays.
Bug: 34280365
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testVirtualDisplayHidesContentWhenLocked
Test: #testShowWhenLockedVirtualDisplay
Test: #testShowWhenLockedPublicVirtualDisplay
Change-Id: I9c19d36295e62f59bd1db1352af707d54ea51667
* commit 'a19056c35d16ddb5a6c1d3343729701b8939f1e1': (35 commits)
NetworkMonitor: send one DNS probe per web probe
NetworkMonitor metrics: add first validation information
APF: also drop any ICMPv6 RSs
ConnectivityServiceTest: fix testAvoidBadWifiSettings
Fix ConnectivityServiceTest testRequestBenchmark
Switch over to new "time.android.com" NTP pool.
Define API for metering network stats buckets.
Refactored NetworkStatsServiceTest to use Mockito instead of EasyMock.
Use @Ignore to explicitly disable a @Test method.
Fixed NetworkStatsServiceTest and converted it to JUnit4.
VPN network stat accounting changes.
ConnectivityThread: use lazy holder idiom
ConnectivityManager: use ConnectivityThread looper
ConnectivityManager: a simpler CallbackHandler
Indicate the NsdServiceInfo attributes are only filled in for a resolved service.
Add a null check for the OnStartTetheringCallback.
TokenBucket for rate-limiting and throttling
IpConnectivityMetrics reads buffer size in settings
CaptivePortalLogin: set mixed content policy to compatibility.
Add IP conn metrics to dumpsys and bug reports
...
- Virtual displays might have hdr capabilities not initialized,
which lead to exception when checking.
- Dynamic stacks were mistakenly considered an invalid launch stack.
Test: android.server.cts.ActivityManagerDisplayTests
Change-Id: I20356d6e25cf9e5fa4a3d7bd3699a8e82a73f21a
Add a new system service to manage Runtime Resource Overlays. This will
offload the PackageManagerService and allow administration of overlay
packages while affected packages continue to execute.
Overlays can be enabled or disabled during runtime. Running applications
will re-create their ResourcesImpl objects and restart their activities
via the usual activity life cycle.
The order in which a set of overlays is loaded may also be changed
during runtime. The underlying mechanics are the same as for when an
overlay is enabled or disabled.
When an overlay changes state, e.g. becomes enabled, the
OverlayManagerService will broadcast one of the new intents
android.intent.action.OVERLAY_ADDED, *_CHANGED, *_REMOVED or
*.OVERLAYS_REORDERED.
Clients that wish to read information about overlays for users other
than themselves are required to hold the
android.permission.INTERACT_ACROSS_USERS_FULL permission. This mirrors
the protection level of PackageManager.getPackageInfo.
Clients that wish to change the information are required to
hold the permission android.permission.CHANGE_OVERLAY_PACKAGES.
Each pair of overlay package and corresponding target package is
respresented by a new OverlayInfo class. This class mirrors the
existing PackageInfo class.
Overlay packages are handled per Android user. The data is persisted in
/data/system/overlays.xml.
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: I15325e173193df3240b8dc0a58c852fd7a3d5916
Ported from frameworks/support change id
I824eb312fbdfd6b548fe94aa2cd5b03afbaa97c7
When a target fragment was set using Fragment#setTargetFragment, all
bets were off, especially when restoring from instance state. Order of
lifecyle initialization was undefined meaning that two bugs could
occur, both of which manifested as the target fragment was not
initialized by the time the referring fragment's onCreate ran. One
could happen if the target fragment is on the back stack, the other
could happen if the target fragment was ordered unfortunately in
FragmentManager implementation details. (!)
Fix both by guaranteeing that any target fragment gets pushed forward
to at least the CREATED state before we dispatch any lifecycle events
for the referring fragment.
Add some sanity checks that try to keep developers from setting target
fragments across different FragmentManagers or from creating target
cycles, both of which are bad ideas.
Bug: 33653458
Test: CTS FragmentLifecycleTest
Change-Id: If624d4665d29e205d37b9b384322e64d6d6d3615
Some apps are asking StrictMode to detectAll(), but we should only
trigger the violation types that they would expect based on their
target SDK level. (This prevents us from starting to yell about
violations in new API levels that a developer never would have known
about.)
Test: builds, boots, older apps aren't triggered
Bug: 34735225
Change-Id: Idff1bfdf57c635b828236e34a24d55350b9fa556
* Encapsulated application-level auto-fill logic on AutoFillSession.
Currently, Activity.java directly manages the IAutoFillCallback binder
object used to auto-fill its views, but this logic need to be
extended so Views can use it to draw the auto-fill bar.
* Pass auto-fill id and boundaries to requests
So AutoFillUI can display its affordance in the right places.
* Uses a new auto-fill id on View (instead of reusing accessibility's).
That allows moving the logic on whether a new request should be made or
the existing UI moved to the service side.
* Split service methods in 2, for shell cmd and app
And applied the right permission check on both.
* Removed CancelationSignal from onSaveRequest()
Since it's not really needed.
* Etc...
¯\_(ツ)_/¯
BUG: 34637800
BUG: 31001899
Test: CtsAutoFillServiceTestCases passes
Test: manual verification
Change-Id: Ibd0cb2cfff6d0f6bb6b697a423ed5e89df687b82
An upcoming sdcardfs change will offer to automatically change the
GID of files on external storage based on the extension, but we need
to tell the kernel the mapping that we'd like to see.
This change pushes the current mappings used by installd when kernel
support is detected.
Test: builds, boots, works with old/new kernels
Bug: 34733702
Change-Id: I4a13b17f5a8e080a9bea51b01aa9f1cbf575e0ab
We need to strike a balance between rescuing devices of real users
in the field, while also not interfering with debugging or testing
use-cases.
This change uses "charging via USB" as a signal that the device is
under active development, or is in a lab environment. We could try
checking for an adb connection, but UsbDebuggingManager isn't
started until much later in the boot, so BatteryManager is our best
chance of detecting this case.
Note that we continue to always recover "user" builds, and we never
recover "eng" builds.
Test: builds, boots, skips when plugged in over USB
Bug: 34722552
Change-Id: Ib095482a2ed84e8c5dfb3c71d5f9b88457c2b5e6
