This CL adds a network callback -- registered via ConnectivityManager --
for every mobile subscription that we know about. This amounts to one
listeners per subId (more on that below). The network callback is
registered only to receive information about _that_ subId's network
pertaining to the NET_CAPABILITY_PRIORITIZE_LATENCY. We'll use this flag
downstream to determine whether or not to show a network slice
attribution.

On ConnectivityManager's callback list:
  The docs on ConnectivityManagerService claims that we should be careful
about too many callbacks registered with the system. If we need to get
rid of the 1:1 mapping from subscription to registrant, then we would
have to do some work to register a _single_ callback that maintained a
map of <netId, networkCapabilities>. It would also presumably have to be
eagerly listening, and make sure to update the map whenever a network
disappears
  Note that this doesn't actually give us a huge performance benefit
from what I can tell. This is because our single registrant would still
get a callback-per-network in which the capabilities changed. Therefore,
we still get the penalty of N incoming IPCs when there are N networks
that meet the criteria. So we only should worry about that in the case
where we run close to the limit of 100 subscribers per process.

Test: tests in statusbar/pipeline
Bug: 270385675
Change-Id: If42b52ad6e14bdc258c90761e3e6dd629bbe9d3d

This enables SystemUI to register a network callback filtered on the
network capabilities associated with network slices.

Also add the NETWORK_FACTORY permission which is required to eventually
start monitoring these events.

Test: compile
Bug: 270385675
Change-Id: I739a8d5dbe48624e4785f5ebf4cc0a85e0f64da2

Test: compile
Bug: 270385675
Bug: 301610137
Change-Id: I6ec2cbbec5db99c94a09766795a64450d7062286

[automerger skipped] Merge "Create pending intent for specific user" into udc-dev am: 293c1c6b am: a98bb877 -s ours

am skip reason: Merged-In If03e146a069b9162d41eee26b7070ea52827fddf with SHA-1 a75c8e7b is already in history

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



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

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



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

This change does the following:
 * Fixes refresh of anon region pinning - The pinAnonRegion
   method was being called multiple times redundantly (e.g., for
   different users, or during startup). This resulted in duplicate
   pinnings of the same region size, potentially 3-4x the requested
   memory after a single boot. This is not safe even for experiments.
   Update behavior to listen to config changes and refresh accordingly,
   including releasing memory if the experiment flag is reset.
 * Changes the mapping from MAP_PRIVATE to MAP_SHARED - This avoids
   issues w/ downstream telemetry where rss.anon values (as read from
   /proc/*/status) trigger behavior like heap dumps/profiles. The memory
   region is still anonymous, and even appears as private dirty in
   showmap/dumpsys meminfo (due to the invalidating setMemory() call on
   the shared anon buffer), but in perfetto memory accounting, it
   falls under `mem.rss.shmem`.
 * Renames pin_anon_size to pin_shared_anon_size - As it's not safe to
   use the previous flag due to (1), and the semantics are changed
   slightly in (2), introduce a different name.

Bug: 294079161
Test: device_config put runtime_native_boot \
          pin_shared_anon_size 2000000000
Test: device_config put runtime_native_boot \
          pin_shared_anon_size 0
Test: device_config delete runtime_native_boot \
          pin_shared_anon_size
Test: showmap `pidof system_server`
Test: cat /proc/`pidof system_server`/status | grep 'Rss'
Change-Id: I7c7c0dc76b9ff04c9cd05de25bfaed65372a56a0

* I'm removing the word View from the class so that this can be used in other contexts.
* I'm adding an requirement that you call `forView` if you want to omit the FeatureFlags.

Bug: 290365128
Test: atest SystemUITests
Change-Id: I96a273a660f05fc398ee7eb68e19b76aa8db0bc5

Context:
This bug mainly occurs in multi page auth scenarios such as:
Page/Screen 1:
username field
Page/Screen 2:
password + confirm password field

For the above:
On completion of page 1, the session is committed and a new session is kicked off. However, the new session (for page 2) will now contain the username field from the prev session (merged) along with the two new fields (pw + confirm pw).

As a result, a fill req + fill response (triggered by generate strong pw) will now contain (username, pw, confirm pw) in the returned dataset. However, this will fail as (username) is in the returned dataset but it is not part of the current screen.

Fix: The fix here is to ignore any fields (in the fillresponse) that don't belong to the current session. The previously submitted gms fix will be reverted (separately) as well to not conflict with this change

Test + confirmed that w/ flag (fill_fields_from_current_session_only=True) enabled the issue is no longer observed.

Flag: fill_fields_from_current_session_only
Bug: 270722825
Bug: 289585475
Test: atest CtsAutoFillServiceTestCases
Change-Id: I05b5d841ea99d7738b306ba4acfb577827da71a8

Bug: 300019131
Test: verify using perfetto trace
Change-Id: Ife206bd8b1592cdee013242115bf885e6c699af0

* changes:
  Removes SmartActions from Rankings before marshal
  Moves test utils from NLSTest to RankingTest

Test: presubmit
Bug: 304525499
Change-Id: Ie269983803809e0e18691339914738a50c087f67

Define get() for isCommunalEnabled so it calls through to FeatureFlags
based on best practices in go/sysui-flags#best-practices

Bug: b/301269121
Test: on device
Change-Id: I7a7fd82cb270488268dce24e54ec5079bdaa6aad