| Age | Commit message (Collapse) | Author |
|---|
|
/external/robolectric-shadows" into main am: 3a1ad8c70d am: fe73e96198 am: 6d8b448d3d
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2889455
Change-Id: Ie81e770aac077cdf4844c6321f1209c3b2d21187
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
/external/robolectric-shadows
We maintain /external/robolectric (keep it in sync with github/google3) and are getting ready to delete /external/robolectric-shadows
Bug: 314757990
Test: atest same failing tests before and after in services/robotests.
Flag: NA
Change-Id: Ie3d2e902ffcba6b9d159b78592f7d6ce31288a2f
|
|
1. Move implementations and related utils to internal
2. Make calling SystemConfig methods from ParsingPackageUtils.Callback
to avoid calling from the client side.
3. Move isMatch and isEnabled from ComponentParseUtils to PackageInfoUtils
4. Move string from SELinuxUtil to SeinfoUtil
5. Move some methods from AndroidPackageUtils to AndroidPackageLegacyUtils
6. Copy some methods from PackageInfoUtils to AppInfoUtils
7. Use PackageParserException instead of PackageManagerException for
validatePackageDexMetadata method
Bug: 309596860
Test: build pass and boot to home
Test: atest PackageManagerServiceServerTests
Test: atest PackageManagerComponentOverrideTests
Test: atest PermissionServiceMockingTests
Test: atest PackageManagerServiceUnitTests
Test: atest PackageManagerPerfTests
Change-Id: I3de48d0d8adf714447823408673e07ed379f27ab
|
|
This is the third attempt to merge ag/25043811.
Wired routing means choosing where media plays among the
non-bluetooth routes. You can find details of the design
in go/wired-device-routing. You can find a summary of the
change here:
- Changes are guarded by the
enable_audio_policies_device_and_bluetooth_controller
flag in the media_solutions namespace.
- All wired and active bluetooth devices routes are
obtained from AudioManager.
- Bluetooth route ids are obtained from BluetoothAdapter,
regardless of whether the route corresponds to an active
or inactive bluetooth route.
- When necessary, audio routing strategies are used to
route the audio away from the default audio output.
Existing tests became invalid due to changes in the
dependencies of AudioPoliciesDeviceRouteController. New
tests are being added in the following commit where we
need to need to make changes in our dependencies so as
to enable testing.
Bug: 305199571
Test: atest MediaRouter2HostSideTest CtsMediaBetterTogetherTestCases
Change-Id: I060d0e67191750fb1b92c5fc7a102871840a776e
|
|
|
|
This reverts commit dc78995b35b549a37ca50ce6abf565effe5e0fce.
Reason for revert:
Reason for revert: Potential culprit for b/314133482 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I718f00008043add508563a4e3e496deefc0fd310
|
|
|
|
This is a revert^2 of ag/25043811.
Wired routing means choosing where media plays among the
non-bluetooth routes. You can find details of the design
in go/wired-device-routing. You can find a summary of the
change here:
- Changes are guarded by the
enable_audio_policies_device_and_bluetooth_controller
flag in the media_solutions namespace.
- All wired and active bluetooth devices routes are
obtained from AudioManager.
- Bluetooth route ids are obtained from BluetoothAdapter,
regardless of whether the route corresponds to an active
or inactive bluetooth route.
- When necessary, audio routing strategies are used to
route the audio away from the default audio output.
Existing tests became invalid due to changes in the
dependencies of AudioPoliciesDeviceRouteController. New
tests are being added in the following commit where we
need to need to make changes in our dependencies so as
to enable testing.
Bug: 305199571
Test: atest MediaRouter2HostSideTest CtsMediaBetterTogetherTestCases
Change-Id: Ia051829189f14ab2eb8310bee74bd17203c0b294
|
|
|
|
This reverts commit da1e5bb6acdf498d61499e1ab11306c24302b4f5.
Reason for revert: b/313914778
Change-Id: I6f97f2e056202035cb31e0a50d8b783c3805725b
|
|
|
|
Wired routing means choosing where media plays among the
non-bluetooth routes. You can find details of the design
in go/wired-device-routing. You can find a summary of the
change here:
- Changes are guarded by the
enable_audio_policies_device_and_bluetooth_controller
flag in the media_solutions namespace.
- All wired and active bluetooth devices routes are
obtained from AudioManager.
- Bluetooth route ids are obtained from BluetoothAdapter,
regardless of whether the route corresponds to an active
or inactive bluetooth route.
- When necessary, audio routing strategies are used to
route the audio away from the default audio output.
Existing tests became invalid due to changes in the
dependencies of AudioPoliciesDeviceRouteController. New
tests are being added in the following commit where we
need to need to make changes in our dependencies so as
to enable testing.
Bug: 305199571
Test: atest MediaRouter2HostSideTest CtsMediaBetterTogetherTestCases
Change-Id: Ib6f2f2cfd3f65cde4be6a425158487b58c561d7c
|
|
Move interfaces under pasring/pkg/ and pkg/parsing/ to
the framework internal path.
Bug: 309596860
Test: build pass and boot to home
Test: atest PackageManagerServiceServerTests
Test: atest PackageManagerComponentOverrideTests
Test: atest PermissionServiceMockingTests
Test: atest PackageManagerServiceUnitTests
Change-Id: I7bc4eae1c9feaca725f9b8bc4e11764d978ef6c6
|
|
apps on user 0).
Also correctly makes DISALLOW_DEBUGGING_FEATURES global to block adb on
HSUM
Test: Manual use of connected apps settings on HSUM
Fixes: 264853055
Fixes: 266542871
Change-Id: I5caecdeeefa42671f1410a07ce06646610256905
|
|
Bug: b/255495104
Test: atest AudioPoliciesBluetoothRouteControllerTest
Change-Id: I814a776dd80ff1f02b09db91a4174244bcd8ded0
|
|
am: f626b58472 am: 39d74defdc
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2446527
Change-Id: I6d6c7adc94f4f6b92ef00a4994c0211331561d7f
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Bug: b/255495104
Test: N/A
Change-Id: I11b0cb8fa3a143b4d9af74f0464ff3737393c9fd
|
|
|
|
Add a new NetworkTimeHelper impl and changes to support it in the
time detector service code.
Background:
When the location code that became NtpNetworkTimeHelper was first
written, Android devices were not guaranteed to be requesting the time
regularly from network time sources: it was only done if the user had
enabled automatic time detection.
That changed a few releases ago, and so the location code should always
be able to ask the time detector for the latest network time signal.
This is part of a wider goal to remove several dependencies in the
Android platform on low-level NTP client code (NtpTrustedTime class).
The NTP protocol usage should be an implementation detail, not something
that is widely known to unrelated classes that want an accurate time.
With the new impl, the SDK SystemClock.currentNetworkTimeClock() call
will ask the time detector service for the latest network time too, and
not interact with the NTP client singleton directly as it does today. It
currently needs to use the NTP client because both the location code and
time detector use the NtpTrustedTime singleton independently and it is
therefore the closest thing on Android today to an authority of "what is
the latest network time the device has obtained?".
Once the time detector is the authority on "latest network time", it
will allow the platform to apply stringent checks to things like time
sync accuracy, which is currently not well checked and heavily dependent
on network round-trip time and network delay symmmetry.
This refactoring is also potentially important for form factors like
Wear, which disable NetworkTimeUpdateService and therefore won't trigger
NtpTrustedTime while attempting to sync. There's a good chance the
location time sync is also broken on Wear (if present) because of the
unusual networking constraints. The API
SystemClock.currentNetworkTimeClock(), which was added to the public SDK
in Android T, may be unreliable or broken on Wear. In future, Wear could
call suggestNetworkTime() on the time detector service from its own
equivalent of NetworkTimeUpdateService and restore
SystemClock.currentNetworkTimeClock() behavior, while also supporting
the location stack's needs (if that is also used on Wear).
Centralizing network sync under NetworkTimeUpdateService will mean that
fewer components on devices will be syncing time for their own ends,
potentially reducing load on time servers too.
This centralization also supports options for changing how "network
time" is obtained in future, e.g. allowing easier integration of newer
protocols like NTS or Roughtime, or partner plug-ins to support
proprietary protocols.
New implementation details:
The TimeZoneDetectorNetworkTimeHelper implementation retrieves the
latest network time suggestion from the TimeDetectorInternal API. It
attempts to pass time to the GNSS code as often as the original
implementation, even when a new time signal isn't available and its
potentially repeating itself, in case GNSS code has become reliant on
that. Generally, it's hard to tell what the contract should be,
particularly with the unusual behavior around "on demand" Vs "periodic"
and the historic bug there.
The new implementation should become the default when it is considered
safe to do so, i.e. after testing when we are confident that
NetworkTimeUpdateService is behaving as well as the old
NtpNetworkTimeHelper impl when detecting connectivity, etc. This can be
done with a single boolean compile-time flag.
Other changes:
The time detector is now a dependency of the location stack, so the
SystemServer service bootstrap ordering has been adjusted.
Bug: 222295093
Test: atest services/robotests/src/com/android/server/location/gnss/TimeDetectorNetworkTimeHelperTest.java
Test: atest services/tests/servicestests/src/com/android/server/timedetector/TimeDetectorStrategyImplTest.java
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/TimeZoneDetectorStrategyImplTest.java
Change-Id: I2f9a14776e9fafe426213df7cb0307a3fe541fad
|
|
Test: btest android.devicepolicy.cts.ProvisioningTest#createAndProvisionManagedProfile_setsCrossProfilePackages -si
Bug: 261834806
Change-Id: I1e611a16dc10704a386cce4fd3a1d596e1c65f36
|
|
|
|
Refactoring to support an alternative source of network time for passing
to the GNSS component. The new implementation will be submitted in a
follow-up.
NtpTimeHelper has been replaced by NetworkTimeHelper in
GnssLocationProvider. NetworkTimeHelper provides the stable interface
between GnssLocationProvider and the original / alternative impl for
what was NtpTimeHelper.
NtpTimeHelper has been renamed NtpNetworkTimeHelper.
These changes are not intended to change any behavior. There are some
minor changes between the interaction between GnssLocationProvider and
the NetworkTimeHelper class, but these are not expected to alter the
runtime behavior.
The NetworkTimeHelper.setPeriodicTimeInjectionMode() method touches
a pre-existing bug: The method name reflected the effect of the method,
which is the near-opposite of what the capability name would suggest.
This appears to be due to an accidental logic inversion, not by intent.
As can be seen in the changes for GnssLocationProvider: the
enablePeriodicTimeInjection() method was called when
mGnssNative.getCapabilities().hasOnDemandTime() was true. The existence
of bug 73893222 supports the fact that there is a long-standing bug
here. The intent with this commit is not to fix it or alter behavior,
just to make it more obvious, as it is unclear if the current behavior
is relied upon somewhere. Comments and field names have been improved to
try to clarify the actual behavior.
Bug: 73893222
Bug: 222295093
Test: atest services/robotests/src/com/android/server/location/gnss/NtpNetworkTimeHelperTest.java
Change-Id: I0b1ba43a55ff531df343c022650e3f5721dda7f1
|
|
This remerges ag/20838898 that was reverted due to breaking a
robolectric test in BackupFrameworksServicesRoboTests.
Test: 1. atest BackupFrameworksServicesRoboTests
2. atest CtsBackupHostTestCases
Bug: 259953764
Change-Id: I11c7dbe9959f5b5d1acf53e7830b7256357768e2
|
|
Not having the implementation causes B&R robolectric tests fail with a NPE.
Bug: 263981306
Test: atest BackupFrameworksServicesRoboTests
Change-Id: I47bf7ba42cf3bd23e472f8c9a21e4e657053ad42
|
|
Makes it so that the non-suffixed name is the to-be system API,
renaming the internal class with an _Internal suffix.
This will also happen to all other exposed internal package data
types in future changes.
Test: presubmit, just a naming change
Change-Id: I8695e7f1644ff5af9303bb32ddec3480bd155bf8
|
|
To fix cross user package visibility leakage, this CL filters out
packages that aren't installed in the calling user before the API
returns results to the caller.
Also adding a user id parameter to the API for the system modules to
specify the correct user id when querying the appop permission packages.
NoNonSdkCheck: Keep @UnsupportedAppUsage for new signature api
Bug: 229684723
Test: atest CrossUserPackageVisibilityTests
Change-Id: I9d3de91b0195d3396d2737673cb23ef899e23467
|
|
TransportManager#onPackageChanged was not correctly handling the
circumstance where broadcast ACTION_PACKAGE_CHANGED was received
with EXTRA_CHANGED_COMPONENT_NAME_LIST containing only the
package name, instead of >=1 component names. When that happens
it indicates that a package-wide change has occurred, such as
the package being enabled or disabled.
If the package in question contains backup transports, they
should be unregistered if the package is disabled, and re-
registered if the package is enabled. But the current
TransportManager#onPackageChanged doesn't know enough to do so.
We can determine the enabled state of the package by calling
PackageManager#getApplicationEnabledSetting. This commit modifies
onPackageChanged to do that, and then (un/re)-register the
packaged transports as appropriate.
To test I extend the Roboelectric ShadowApplicationPackageManager
so that the {get,set}ApplicationEnabledState() methods are
exposed for use in the test setup.
Note, this is a retake of ag/15301455, with handling added for a
race condition which caused flakiness in CtsUtilTestCases: the
onPackageChanged method must handle a possible exception thrown
by the PackageManager if the package has just been removed.
Bug: 162725876
Fixes: 162725876
Test: 1. atest -v TransportManagerTest
2. atest CtsBackupHostTestCases|CtsBackupTestCases|CtsUtilTestCases
3. manual test on device:
1 device:/ # bmgr list transports
2 device:/ # pm disable com.google.android.gms
3 device:/ # bmgr list transports
4 device:/ # pm enable com.google.android.gms
5 device:/ # bmgr list transports
observe logcat showing BackupTransportManager MORE_DEBUG:
step 2: Package c.g.a.gms was disabled.
step 4: Package c.g.a.gms was enabled.
Transport c.g.a.gms/.b.c.D2dTransportService registered
Change-Id: I1ba20a50dfb9a6918605bbd3216a08f0047e2c10
(cherry picked from commit d68bb3786d6431411973ae1a54ac43de93552b90)
|
|
TransportManager#onPackageChanged was not correctly handling the
circumstance where broadcast ACTION_PACKAGE_CHANGED was received
with EXTRA_CHANGED_COMPONENT_NAME_LIST containing only the
package name, instead of >=1 component names. When that happens
it indicates that a package-wide change has occurred, such as
the package being enabled or disabled.
If the package in question contains backup transports, they
should be unregistered if the package is disabled, and re-
registered if the package is enabled. But the current
TransportManager#onPackageChanged doesn't know enough to do so.
We can determine the enabled state of the package by calling
PackageManager#getApplicationEnabledSetting. This commit modifies
onPackageChanged to do that, and then (un/re)-register the
packaged transports as appropriate.
To test I extend the Roboelectric ShadowApplicationPackageManager
so that the {get,set}ApplicationEnabledState() methods are
exposed for use in the test setup.
Note, this is a retake of ag/15301455, with handling added for a
race condition which caused flakiness in CtsUtilTestCases: the
onPackageChanged method must handle a possible exception thrown
by the PackageManager if the package has just been removed.
Bug: 162725876
Fixes: 162725876
Test: 1. atest -v TransportManagerTest
2. atest CtsBackupHostTestCases|CtsBackupTestCases|CtsUtilTestCases
3. manual test on device:
1 device:/ # bmgr list transports
2 device:/ # pm disable com.google.android.gms
3 device:/ # bmgr list transports
4 device:/ # pm enable com.google.android.gms
5 device:/ # bmgr list transports
observe logcat showing BackupTransportManager MORE_DEBUG:
step 2: Package c.g.a.gms was disabled.
step 4: Package c.g.a.gms was enabled.
Transport c.g.a.gms/.b.c.D2dTransportService registered
Change-Id: I1ba20a50dfb9a6918605bbd3216a08f0047e2c10
|
|
Several other related classes are also updated to have a
dependency on OperationStorage, which removes a number of
tight bindings on UserBackupManagerService.
BUG: 161089758
Test: atest BackupFrameworksServicesRoboTests
atest CtsBackupHostTestCases
atest CtsBackupTestCases
atest GtsBackupTestCases
Change-Id: I644ef2cd1a3e8d8c35a269c140df8cc5f3654e16
|
|
|
|
The change is auto-generated through IDE rename function and makes the
following naming changes:
1. TransportClient -> TransportConnection
2. TransportClientManager -> TransportConnectionManager
3. + corresponding test files
TransportConnection is a more appropriate name for the class as it's
exactly what it does - manages the connection to the remote
BackupTransport service implementation.
This is a preparatory change to making the BackupTransport AIDL async.
TransportClient name will later be used more appropriately for a class
that wraps the actual communication with the transport.
Bug: 202716271
Test: m -j
Change-Id: I76a98edc7102c8fcffdb050208e9e65543e6e10c
|
|
Changes IPackageManager.aidl methods to use long flags instead of int.
Public API change to be followed.
BUG: 204432643
BUG: 204433659
Test: manual
Change-Id: Ib5c42fef998f0116e312c71d620e1a15329e26e0
|
|
This reverts commit 33139c16611fed10883afe8cae5f03c8a69570b4.
Reason for revert: A CTS test is now flaky, see b/197093424
Change-Id: Ife432938448cc24bb2a61fa30873270bcf2ee1a7
|
|
TransportManager#onPackageChanged was not correctly handling the
circumstance where broadcast ACTION_PACKAGE_CHANGED was received
with EXTRA_CHANGED_COMPONENT_NAME_LIST containing only the
package name, instead of >=1 component names. When that happens
it indicates that a package-wide change has occurred, such as
the package being enabled or disabled.
If the package in question contains backup transports, they
should be unregistered if the package is disabled, and re-
registered if the package is enabled. But the current
TransportManager#onPackageChanged doesn't know enough to do so.
We can determine the enabled state of the package by calling
PackageManager#getApplicationEnabledSetting. This commit modifies
onPackageChanged to do that, and then (un/re)-register the
packaged transports as appropriate.
To test I extend the Roboelectric ShadowApplicationPackageManager
so that the {get,set}ApplicationEnabledState() methods are
exposed for use in the test setup.
Bug: 162725876
Fixes: 162725876
Test: 1. atest -v TransportManagerTest
2. manual test on device:
1 device:/ # bmgr list transports
2 device:/ # pm disable com.google.android.gms
3 device:/ # bmgr list transports
4 device:/ # pm enable com.google.android.gms
5 device:/ # bmgr list transports
observe logcat showing BackupTransportManager MORE_DEBUG:
step 2: Package c.g.a.gms was disabled.
step 4: Package c.g.a.gms was enabled.
Transport c.g.a.gms/.b.c.D2dTransportService registered
Change-Id: I7bd397f0f1eadbbca6f371c3c9710df5386aca13
|
|
Extracts large parts of the GNSS HAL into a central GnssNative class,
which can be faked for testing. This is a large step towards making all
GNSS code unit testable, and allows for more modular HAL configurations.
Begins to break up the GnssLocationProvider god object and pull
functionality out into other classes. Changes include:
-Making GnssCapabilities parcelable so it can be part of the API
-Splitting out the NMEA listener from status listeners, which
substantially reduces the burden of supported NMEA listeners as well as
the amount of GNSS<->AP communication.
-All GNSS listeners now respond properly to HAL restarts.
-Partially extract out emergency call detection.
Bug: 153129152
Test: manual
Change-Id: Idee0d548f38c6adf921cd6c28b5d815bbd366f8a
|
|
Delegate the resetting of the INTERACT_ACROSS_PROFILES app-op to
DevicePolicyManager, which knows whether it should be pre-granted and
knows to apply it equally across all users in the profile group.
Further unit tests for DevicePolicyManagerInternal will be added in
b/175440570 when we have the better infra for that.
The CrossProfileAppsServiceImpl changes look more complex than they are.
They consist of the following:
- Inclusive language changes to 'allowlist'
- Static imports of permissions to improve readability
- Previously, the setInteractAcrossProfilesAppOp method would set the
app-op for every user within the profile group of the 'calling user'.
However, given that we are now exposing this as a server-side internal
API where we need to pass in a user ID (from AppOpsService), we don't
necessarily have the guarantee that the 'calling user' is in the same
profile group. So we split it up: the client-side API and AIDL API still
set the app-op for the calling profile group, whereas the internal API
sets the app-op for every user within the profile group of the provided
user. The changes simply abstract away references to the 'calling user
ID'.
Fixes: 166561076
Bug: 175440570
Test: atest services/robotests/src/com/android/server/pm/CrossProfileAppsServiceImplRoboTest.java --verbose -c
Test: manual
Change-Id: I2181fe66022aaf6c3e6d784c0569d2f41ab66537
|
|
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1522299
MUST ONLY BE SUBMITTED BY AUTOMERGER
Change-Id: Ic48a74d51cf700cf8c737c27cd8f94b6ac25d404
|
|
Change-Id: I0c3debf00a28d4ca930582fb23bd34159ef1ddd4
|
|
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
|
|
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
|
|
|
|
-Moves batching APIs from SystemApi to Public, and makes them
multi-client safe.
-Adds equals/hashcode to Location.
Bug: 171512333
Test: manual + presubmit
Change-Id: I6ee28f8229fdf49386cd370ea785de63b97e7cde
|
|
Test: on device
Bug: 168111993
Change-Id: I2ee4414fbc1fcb7abe8a3d5b1099a3e6e58a6777
|
|
Log a much wider variety of important events in memory for bugreports
and dumpsys. This will make debugging much easier, hopefully at a
minimal memory cost. Memory cost could be improved in the future as
well.
Test: manual + presubmits
Change-Id: Iab867575f783f1c5f41a405da66f72d5f52691bf
|
|
This method was added to operate as an internal variant of the
public getPackageUid method since pmInternal#getPackageUid already
exist. However, pmInternal#getPackageUid method just called to the
public interface, and enforcing permissions and visibility checks.
Since we don't expect any UID/permission checks in a local service,
any callers to this method requiring permission checks should be
migrated onto the PackageManager public method. Remove the original
pmInternal#getPackageUid and rename #getPackageUidInternal to take
its place.
Bug: 148235092
Test: Build pass and boot
Change-Id: Ibd4aa8a6a7743ff378a23e21c68efc52692580c7
|
|
Bug: 161241479
Test: atest RunBackupFrameworksServicesRoboTests
Change-Id: I7705d441947b1e2143f5da3c298294f5a67377f0
|
|
After refactoring AppBackupUtils into BackupEligibilityRules (see the
other linked CL), update the usages throughout the code.
Bug: 161241479
Test: atest UserBackupManagerServiceTest
atest TarBackupReaderTest
atest BackupHandlerTest
atest PerformUnifiedRestoreTaskTest
Change-Id: I2a90c4f5b951fa3e3c564a1065ad10a88cc16273
|
|
* changes:
Add BackupManager API to start migration
[FSD2D] Add migration-aware methods to AppBackupUtils
|
|
Add an override of BackupManager#requestBackup where type of the
operation (a regular backup or a migration) can be specified.
Bug: 160407842
Test: atest UserBackupManagerServiceTest
Change-Id: Ia54fa26b040c3ec3612672585561794ff831afef
|
|
Creating a new Throwable (and filling in the stack trace) can take
up to 150us. Since we do this on the critical path when sending
over SurfaceControl via binder multiple times, this is too much.
Instead, add an option to pass in callsite manually.
Bug: 159056748
Change-Id: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
|