Always allow BAL for system.

This automatically opts in all activity starts by system processes
to grant the system process' BAL privileges.

The reason for this is that shared UID for system processes is common
and most automated tests actually ran against configurations that have
additional packages installed that downgrade the system process' target
SDK. This is also true for the droidfood population, that is running
userdebug/eng builds.
With the lower target SDK of the system UID the CompatChange call that
means for the droidfood population and even for many tests that run
against non-pure (i.e. -user) configurations the feature was likely
not fully activated (only for app processes).
While we have data from the droidfood population that indicates the
potential for breakages is limited we decided that it would be better to
allow system processes to start BAL and reduce those privileges with the
next qpr (especially since only system processes will be affected).

This reduces the impact of the BAL hardening, but allows us to keep the
logic in place and try to remove this workaround later.

Related bug: b/282922910 - IsChangeEnabledByUid() returning different values in user vs userdebug

Test: atest BackgroundActivityLaunchTest ActivityStarterTests
Bug: 283138430
Change-Id: If1891a4edba38c77986e6e391cdc65c841f2e993

0 files changed, 0 insertions, 0 deletions