Ravenwood test authors should only need to call setServicesRequired()
for the services they directly interact with, but often those
services will have indirect dependencies on other OS internals, and
those dependencies will evolve over time.

To handle this, we add the concept of dependencies to SystemService,
where a service declares the other services required to run.  (They
can choose to omit services from their dependencies where they
gracefully handle a missing service at runtime.)

Bug: 325506297
Test: atest RavenwoodServicesTest
Change-Id: I42187b3494fef499d619ad882891e832b0fd6bca

One of our eventual goals with Ravenwood is to support usage of
system services from test code.  A recent change added support for
"real" services on Ravenwood, and this change expands that to add
support for "fake" services.

Some services are so tangled with dependencies it would take a
long time until we'd be able to run their "real" code.  Also, some
services with deep hardware dependencies that it can be difficult
to add new abstraction layers to support Ravenwood.  Finally, we
want to support service owners that only have resources to meet
the "Pareto principle", where enabling 20% of their functionality
on Ravenwood is enough to unblock 80% of test use-cases.

Thus, we're supporting teams bringing either "real" or "fake"
implementations of their services.  Since all test interactions
still go through published FooManager and FooManagerInternal-style
interfaces, teams can start with a "fake" and slowly transition
to using more of their "real" code over time, without having to
update test clients.

And as a final reminder, because Ravenwood requires test suites
like CTS, we're already verifying that "fake" services behave
similarly to the "real" services on physical devices.

Bug: 325506297
Test: atest CtsContentTestCasesRavenwood
Change-Id: I8ed5bd030e03143c15cb9fa945bbdcb0b412611e

[automerger skipped] Suppress HiddenAbstractMethod on Notification.Style.areNotificationsVisiblyDifferent am: 7db8b595 -s ours

am skip reason: Merged-In I3b72ef4f0afff35771ee6f37130d1084071e2de1 with SHA-1 57f1c4e1 is already in history

Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/26379910



Change-Id: I7da18d61495df2e90a17777bea669d0b5ccd6f2b
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>

Merge "Suppress HiddenAbstractMethod on Notification.Style.areNotificationsVisiblyDifferent" into main

The `Notification.Style` class is an abstract class with a publicly
visible constructor and so the assumption is it is expected to be
extended by Apps. As such it cannot have any hidden abstract methods as
that would prevent an App from extending the class. Unfortunately,
`areNotificationsVisiblyDifferent(Style)` is both hidden and abstract.

The issue was not previously detected due to a bug in Metalava but that
has been fixed and so now this is an issue. This change is temporarily
suppressing the error in the code to unblock Metalava changes being
merged into AOSP but it should be fixed properly ASAP.

A proper fix would either require marking the public constructor as
`@removed` or unhiding the method or giving it a concrete
implementation.

Bug: 324468829
Test: m checkapi android-non-updatable-doc-stubs
(cherry picked from https://android-review.googlesource.com/q/commit:ddc69d098f03fce1bed20144f92b8743eddb1767)
Merged-In: I3b72ef4f0afff35771ee6f37130d1084071e2de1
Change-Id: I3b72ef4f0afff35771ee6f37130d1084071e2de1

The `Notification.Style` class is an abstract class with a publicly
visible constructor and so the assumption is it is expected to be
extended by Apps. As such it cannot have any hidden abstract methods as
that would prevent an App from extending the class. Unfortunately,
`areNotificationsVisiblyDifferent(Style)` is both hidden and abstract.

The issue was not previously detected due to a bug in Metalava but that
has been fixed and so now this is an issue. This change is temporarily
suppressing the error in the code to unblock Metalava changes being
merged into AOSP but it should be fixed properly ASAP.

A proper fix would either require marking the public constructor as
`@removed` or unhiding the method or giving it a concrete
implementation.

Bug: 324468829
Test: m checkapi android-non-updatable-doc-stubs
(cherry picked from https://android-review.googlesource.com/q/commit:ddc69d098f03fce1bed20144f92b8743eddb1767)
Merged-In: I3b72ef4f0afff35771ee6f37130d1084071e2de1
Change-Id: I3b72ef4f0afff35771ee6f37130d1084071e2de1

* changes:
  OverscrollSpec could be used from TransitionState.Idle state
  DSL to define the overscroll behavior of a scene (1/2)

Merge "Tweak updateAZR so that supplying null ZenDeviceEffects behaves the same as null ZenPolicy" into main

Merge "Merge "INPUT_OWNERS: update, give "self-ownership"" into main am: 9ce68660 am: 4cac4b20" into main

To ensure consistency, we continue to use the same definitions for
scenes with OverscrollSpec, even when the scene is in Idle state.

Test: atest SceneGestureHandlerTest
Test: atest ElementTest
Bug: 291053278
Flag: NA
Change-Id: Ie6babb06b2fd2bcf202e85c3baf78f261594a64d

This reverts commit 3d8cc938.

Reason for revert: b/326506223
This CL has been flagged to be causing significant increase in
unreachable memory bytes. Reverting to validate this finding, will
followup with a proper fix if needed.

Test: presubmit
Test: atest MotionEventTest
Change-Id: Id2cefb4cbd768ed2debb7cbbf9ba912826e64a85

Test: Manual Test
Fix: 327090015
Flag: NA
Change-Id: I7743567a8653cfe98feca34a712d2b78079b1402