Determine whether or not to deal with "undocumented" android manifest attributes

[atsushieno]

There are handful of Android manifest attributes that are NOT documented but found on Android resources, found by build-tools/manifest-attribute-codegen. For example:

<e name='manifest'>
    <a name='revisionCode' api-level='22' />
    <a name='isolatedSplits' api-level='26' />
    <a name='isFeatureSplit' api-level='26' />
    <a name='targetSandboxVersion' api-level='26' />
<e name='application'>
    <a name='multiArch' api-level='21' />
    <a name='defaultToDeviceProtectedStorage' format='boolean' api-level='24' />
    <a name='appCategory' api-level='26' />
    <a name='classLoader' api-level='27' />

Adding them in our manifest ~Attribute classes means that we are exposing undocumented features that Google might have some reason not to expose them.

Not binding them in the ~Attribute classes means that manifest-attribute-codegen outputs are not very useful. App developers can always write those attributes manually in AndroidManifest.xml though.

[jonpryor]

I'm inclined to say that if an attribute isn't documented, then we shouldn't bind it.

This in turn implies that we need some form of "ignore" file for manifest-attribute-codegen, to reduce noise.

[atsushieno]

I usually agree. But probably I should point out that some of those attributes seem to be used for Instant Apps, therefore it is possible that they are described "somewhere"...

[atsushieno]

Another problem with "ignore" file I noticed: I found most of the new manifest attributes in P preview API are undocumented either. If I add them to "ignore" list, what will happen to them in the future?

• scenario 1: We keep ignoring them: those attributes might become "public" and they are kept ignored in our region.
• scenario 2: Every time new API arrived or preview became public, we iterate the "ignore" list - that does not really ease development, which means the most important purpose is not accomplished. ("The purpose is to determine that an attribute is ignored by intention" ? Then just have a look at the documentation, it is super obvious. Usually those undocumented attributes won't be even noticed and won't trigger any extraneous attention.)

Therefore I identified that the ignore list is not really useful. Double-checks will happen at any API updates.

Forgot to mention: managing "ignore" list is a work cost. We should not increase extraneous work cost for nothing.

[jpobst]

Tracked as part of #8272.