Best way to override values in frameworks/base/core/res/res/values/config.xml ?

[Naseer]

Hi,
I want to override values in frameworks/base/core/res/res/values/
config.xml based on the target product.
What is the best method to override only selected values from them ?
I do not want to directly change the xml files do avoid conflicts with
other targets and to avoid maintenance issues.


Thanks,
-Naseer

[Robert Greenwalt]

The build system provides an overlay feature that can be used for this.  It gives aapt one or more overlay paths that get used to modify the base resource file (config.xml in your case).  The config.xml that would exist in the overlay dir would only need to contain the values that you want to change.

R

--
unsubscribe: android-porti...@googlegroups.com
website: http://groups.google.com/group/android-porting

[Naseer]

Found the answer after some googling -
http://groups.google.com/group/android-framework/browse_thread/thread/e9974bd5a42af10a/61dc12b2bd0eadde

This info is pretty useful it should be in http://source.android.com/porting/index.html


Thanks,
-Naseer

> > unsubscribe: android-porti...@googlegroups.com<android-porting%2Bunsubscribe@­googlegroups.com>
> > website:http://groups.google.com/group/android-porting- Hide quoted text -
>
> - Show quoted text -

[Naseer]

Thank you -- Can you please point me to any documentation on how to do
the overlay ?
I am assuming it will use make variables defined in device/$VENDOR./
$TARGET_PRODUCT
Will this also involve modifying the makefile in frameworks/base/core/
res ?

On Aug 18, 8:48 pm, Robert Greenwalt <rgreenw...@google.com> wrote:

[Robert Greenwalt]

you will need to set the PRODUCT_PACKAGE_OVERLAYS build time var in your product defining makefile.  This should be set to the relative path of your overlay dir.  The overlay dir contains a sparse mirror of the source tree with just the resource files you wish to overlay.

For example, from the root of your dev tree:

framework/base/core/res/res/values/config.xml - the real file in with all the other src files

vendor/foo/product/MyProduct.mk (includes PRODUCT_PACKAGE_OVERLAYS := vendor/foo/myoverlay)

vendor/foo/myoverlay/framework/base/core/res/res/values/config.xml - the overlay copy, may only have this one file in myoverlay

You should not modify the base/core/res makefile.

R

--

[Naseer]

Thank you. I had figured that out as you can see from my earlier post,
but somehow google groups got the replies out of order.

> > <android-porting%2Bunsubscribe@­googlegroups.com>
> > > > website:http://groups.google.com/group/android-porting-Hide quoted

> > text -
>
> > > - Show quoted text -
>
> > --

> > unsubscribe: android-porti...@googlegroups.com<android-porting%2Bunsubscribe@ googlegroups.com>
> > website:http://groups.google.com/group/android-porting

[Al Sutton]

Does anyone know if there is a equivalent for code?

I'm working with some people on a Froyo port to the Archos 5 IT, which, although it ships with Android, doesn't have the home, menu, and back buttons so we've had to implement them in the status bar. In order to do this we've needed some code changes to frameworks/base, so it would be great if someone could point me at a method of doing a vendor overlay for the java sources (and yes, I've tried including the code in the overlay file, and unfortunately it doesn't work).

Thanks,

Al.

--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the company number  6741909. 

The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.

[Jim Ancona]

On Aug 19, 8:55 am, Al Sutton <a...@funkyandroid.com> wrote:
> Does anyone know if there is a equivalent for code?

AFAIK, the only way to do this is to fork the relevant repository and
then continue to merge changes from upstream. We have a similar
problem with the Android on Freerunner project (mapping Android
buttons to hardware that doesn't really support them), so if there's a
better way, I'd love to hear about it too.

Jim

> > > > website:http://groups.google.com/group/android-porting-Hide quoted text -

[Dianne Hackborn]

I would think it would be much easier to maintain a patch on top of the platform code rather than trying to replace source files.  What do you do when the platform's source changes to fix bugs or add features?  A patch you can rebase...  a separate source that is a copy of an earlier version of the platform's source seems worse.

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.

[Al Sutton]

[copied to group due to using reply not reply all first time]

We've ended up with a forked repository at the moment. The main problem with post checkout patching (or file copying) is that repo will then refuse to update the files due to detecting local changes.

The ideal system would allow us to continue to use repo to keep the checked out tree up to date and apply the required changes during a build so we can keep all our changes in the vendor/xxx tree. Is that possible with the current build system?

Al.

--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the company number  6741909. 

The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.

[Magnus Bäck]

On Saturday, August 21, 2010 at 09:51 CEST,
Al Sutton <a...@funkyandroid.com> wrote:

> We've ended up with a forked repository at the moment. The main
> problem with post checkout patching (or file copying) is that repo
> will then refuse to update the files due to detecting local changes.

Easily fixed with git stash.

> The ideal system would allow us to continue to use repo to keep the
> checked out tree up to date and apply the required changes during a
> build so we can keep all our changes in the vendor/xxx tree. Is that
> possible with the current build system?

Don't fight the system. You are de facto branching the git in question,
so use the facilities for branching that Repo and Git provide. If it's
just your personal changes you can simply commit them on a topic branch
and Repo will automatically rebase it for you each time you sync. If
it's a shared branch you probably want to set up a manifest branch where
you change the `revision' attribut to point to the shared branch. You
could also use a local manifest to accomplish the same thing. It's hard
to be more specific without details about your environment.

--
Magnus B�ck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson

[Al Sutton]

[copied to list]

I'm a fan of the KISS principal, so if I can reduce the number of repositories involved then I tend to head that way.

One of the patches we have to make is a single line change to a two files (we could do it in one, but it's for frameworks/policies/base so we do it in both the mid and phone profiles). Unfortunately, we have to fork and maintain a whole repository for the project just because of the one line change, and that, to me, seems like a lot of overhead (you can see the patch at http://www.gitorious.org/openaos-testing/frameworks_policies_base/commit/51dcc06ce534fee03dd356e788535ba17c7f39e5)

If that's the way it needs to be done, then that's the way it needs to be done, but it would make things simpler from an admin and maintenance point of view if everyone on the OpenAOS project could use the "standard" repo and have the one line patch applied.

Al.

--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the company number  6741909. 

The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.

Magnus Bäck                      Opinions are my own and do not necessarily

SW Configuration Manager         represent the ones of my employer, etc.
Sony Ericsson

[Dianne Hackborn]

Well you really wouldn't want to have "overlay" code for that kind of thing anyway, because your overlay would end up having a copy of whatever the code was at the point you made it, and wouldn't track later changes that happen to it.  That's really no different than forking, but just in a less rigorous and safe way.

Unfortunately I am not a git expert to help out with this...  I am pretty sure the build system doesn't have a way to automatically apply a patch, though.

[Naseer Ahmed]

For your particular case, I think you're better off adding a new parameter to frameworks/base/core/res/res/values/config.xml, then reading that in the policy.
You could then submit this as a patch to the android mainline and if it gets accepted, you can then use a normal resource overlay for config.xml

[Al Sutton]

It's certainly an idea which crossed my mind for this one line patch. Unfortunately we have a few other patches which are slightly larger and definitely wouldn't make it in to the mainline (one resizes the status bar to put home, back, and menu buttons in it).

Al.

--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the company number  6741909. 

The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.