CTS PrivateAttributeTest in M: How to resolve it by using private attribute correctly?

144 Views Asked by At

Google have added this new CTS case in M, which is cts/tests/tests/content/src/android/content/res/cts/PrivateAttributeTest.java

It enforces that NO vendor custom attribute (type=attr, id=0x0101*) shall be added to framework/base/core/res/res/values/public.xml, according to the comments of this test case:

/**
 * Tests that private attributes are correctly placed in a separate type to
 * prevent future releases from stomping over private attributes with new public ones.
 */

Seems that vendor should use the private attribute mechanism instead, which is built into aapt already. Basically it is an alias of attr, with its own id range.

It works, except one caveat:

The doclint check of javadoc is broke by private attribute, since aapt (framework/base/tools/aapt/Resource.cpp::writeLayoutClasses) add an invalid link to the comments of private attribute, like this:

assume we add a private attribute named "foo" in public.xml:

<public type="attrprivate" name="foo" id="0x01110000"/>

which is a styleable for View:

<resources>
    <declare-styleable name="View">
        <attr name="foo" format="reference|float">
    </declare-styleable>
</resources>

the R.java generated by aapt will be:

/*
  blabla
  <p>This corresponds to the global attribute
  resource symbol {@link android.R.attr#foo}.
  @attr name android:foo
*/
public static final int View_foo = 87;

but {@link android.R.attr#foo} is invalid since there is no android.R.attr.foo symbol, hence broke the doclint check of javadoc.

Am I using private attribute correctly? or is it an issue of the framework for now?

Thanks, Heng

0

There are 0 best solutions below