Resource APKs for OEM/Operator Customization

[Paul Nichols]

Hi,

I wanted to check and see if there was anything in the works to
support resource APKs. We have been prototyping an extension to the
resource framework that would allow a set of "customized" resources to
be loaded from a resource APK. The idea being that we would like to be
able to take an application such as the Browser and change the default
set of pre-loaded links without having to re-compile the Browser. This
would allow the Browser to be “customized” in a post-compile step.

One of the issues that we are trying to address has to do with the way
resource IDs are dynamically assigned each time an application is
compiled. The aapt tool provides a way to effectively “freeze” a
subset of the resource IDs by making them public. By declaring the
application resources that we want to customize to be public, aapt
will assign the same ID to these resources each time the application
is compiled. It then becomes possible to generate a resource APK that
uses these same “frozen” resource IDs. The resource APK would only
contain a few resources, basically a subset of the resources that we
want to make customizable. A few modifications to the framework are
needed …

When an application loads a resource from the application.apk:
- ) First check to see if a corresponding resource.apk has been
installed.
- ) if resource.apk is present and it contains one of the frozen/
customized resources then
* ) Load the customized resource from resource.apk
- ) else
*) Load the resource from the application.apk as normal.

I wanted to get some feedback before we get too far down the road to
make sure that we are heading in the right direction. We would like to
contribute this patch and wanted to make sure that the changes are
being made in an acceptable fashion.

Thanks.

[Dianne Hackborn]

Hi,

There currently aren't plans exactly along that path.  I definitely am averse to doing something that requires apps declare resources as public...  first because maintaining public resources is a pain (with annoying things like what happens when you remove resources), and second because this wouldn't work for the framework (since making something public has very serious meaning that should not be subverted by another use).

The resource system already mostly supports loading multiple .apks and merging them into one resource set...  you just add the additional .apks to the asset manager.  This does require building the resource .apk against the actual binary you shipped (I'm not sure if aapt currently support building such a thing or not), but you should be carefully controlling what versions of things you are putting together anyway, right?

The other aspect to this is theming, which really has much different problems to address.  Theming here is: allowing the install of an .apk that modifies the resources of multiple base .apks but comes from a different source than the base .apks and ideally works across at least non-major version changes of them.  There is some rudimentary work and ideas in the resource system for theming, but a lot left to do.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Paul Nichols]

Hi Dianne,

Thank you for the feedback, I have a few more comments and questions
below.

> ... maintaining public resources is a pain (with annoying things
> like what happens when you remove resources), ...

I agree that maintaining public resources would become a big pain. We
have been trying to think of some ways to ease that pain. One idea is
to keep a master list of the "customizable" resources and then add a
tool to the build chain which performs a check when the application is
compiled. This build-time check would flag any incompatible changes as
either an error or a warning depending on the type of build (eng,
user) and the type of change.

When a resource has been marked as "customizable" in a released
version of an application then that resource name needs to be
reserved. The set of customizable resources could be assigned a
version number. If a future version of the application removes a
customizable resource then backward compatibility would be broken. A
check of the version number would allow the application to ignore any
incompatible customizations. I am thinking that it should be possible
to upgrade an application without necessarily upgrading the
customization.

> The resource system already mostly supports loading multiple .apks and
> merging them into one resource set ...

Good point. I think this feature is very close to meeting our needs.
Our initial prototyping efforts focused on loading multiple .apks and
having the framework merge these into one resource set. We ran into a
few roadblocks with the way that some of the asset cookies are handled
and the order of precedence when multiple .apks are loaded.

Would it be OK to modify the framework to give preference to the
customization .apk which is added to the asset manager's list, instead
of giving preference to the application .apk?

> ... you should be carefully controlling what versions of things you are
> putting together anyway, right?

Yes, we would be controlling which versions of things get put
together, but we still want to achieve forward/backward compatibility.
For example, browser bookmarks. Some operators might want to pre-load
their own set of bookmarks. If the Browser application has a resource
named "bookmarks" then the .apk with the customized bookmarks would
contain a "bookmarks" resource. However, if the Browser application
decided to change the name of the resource from "bookmarks" to
"my_bookmarks" then the forward/backward compatibility would be
broken. We want to avoid this by "freezing" the set of resources that
can be customized. In this way, it would be possible to upgrade the
Browser application without having to redo the bookmark customization.

Does the asset manager treat public and private resources any
differently? I understand that the aapt tool "freezes" the resource ID
for anything that is declared to be public. Other than the resource ID
always having the same value, does the phone software treat a public
resource any different than a private one?

Best regards,
Paul

[Paul Nichols]

As we go about loading resources from multiple .apks, we noticed that
each resource set is assigned a unique cookie. The application .apk
which is loaded first is assigned cookie 2 and the customization .apk
which is loaded second gets cookie 3. We would like for the resources
from the customization .apk to take precedence over those from the
application .apk. For example, a string resource named my_test with
resource ID 0x7f040003 has a value of “hello” in cookie 2, and a value
of “world” in cookie 3. The desired behavior would be for the resource
system to return a value of “world” for my_test. However, this is not
the case today.

In ResTable::getResource and ResTable::getBagLocked the behavior is
different. The package in the least recently loaded .apk (lowest
cookie) takes precedence for the same configuration. In the case of
bags, the values are merged with the lowest cookie taking precedence.
Also, if an entry lookup has failed for a package existing in any
cookie, the entire resource lookup is considered a failure without
searching the other packages in the PackageGroup. We would like an
entire PackageGroup to be searched before a resource lookup is failed.
Also, we would like for the most recently loaded resource package to
take precedence.

Is it OK for multiple .apk loading to have the desired behavior as
stated above? Would it break anything to modify the resource system to
behave this way? Can you share any additional documentation that
describes the details of the resource system?