tree c6e03189e14ca37a925c8deaafafd1483575a722
parent e7f8555d956c8bf5f338a182d8023b2740edc389
author Joshua Trask <joshtrask@google.com> 1678737447 +0000
committer Joshua Trask <joshtrask@google.com> 1678806078 +0000

Stop sharing framework strings from unbundled Java

This kind of sharing was a relic of unbundling, and is known to cause
inscrutable failures (e.g. b/270760957) when the unbundled tests were
run on a device with an out-of-date framework version. We've already
hard-forked (duplicated into the IntentResolver package) most string
resources, and this CL addresses the remainder, w/ exceptions:

 1. Layout XML and other resource files may not have the same
    compatibility issues, so I've left them unchanged or now; we may
    need to make a similar change to those files in the future.

 2. I left one string, `com.android.internal.R.string.copy`, because
    I don't think we'd ever want to diverge from the system value and
    it's currently exported in the frameworks `public-final.xml`
    resource (so there's no risk of binary-incompatibility issues).

In some cases, the resource-sharing wasn't apparent due to file-level
imports of `com.android.internal.R`; I removed those imports (so that
all the unbundled code loads resources from the `intentresolver`
package by default) and converted the non-string resource references
to explicitly reference the framework symbols by fully-qualified name.

This only addresses string resources and may be inadequate to prevent
all regressions in the class of b/270760957, and view ID resources are
particularly concerning because it wouldn't be straightforward to fix
them by an analogous "hard-fork" process. In fact, an earlier
workaround (removed in ag/20065287) had separate cases specifically to
address resource sharing for strings vs. view IDs, so we may expect to
need some fix there. If we encounter similar regressions based on the
view IDs (and don't have any better ideas), we may be able to
reinstate the workaround from ag/20065287 (just for the view IDs;
strings should never need the old workaround now).

Bug: 270760957
Test: `atest IntentResolverUnitTests`, before and after adding a new
placeholder string resource at the top of frameworks' `strings.xml`.
Prior to this CL, that modification would've caused the tests to start
failing unless the framework was rebuilt (e.g. by `mp droid`).

Change-Id: Ifaf069124ba677a79517894d7aba847c5d869b74