Oh note that this does mean that anyone using that resource is using a
private API, so must be bundled with the exact same build of the system it
was compiled against.

On Mon, Feb 16, 2009 at 2:08 PM, Dianne Hackborn <[email protected]>wrote:

> Okay good, glad it will work. :)
>
>
> On Mon, Feb 16, 2009 at 2:01 PM, Nick <[email protected]> wrote:
>
>>
>> Thank you! That mechanism will help greatly. I'm sorry I didn't just
>> ask that question first. I know what I was wanting to do was not
>> recommended but I didn't know of any other option.
>>
>> On Feb 16, 4:35 pm, Dianne Hackborn <[email protected]> wrote:
>> > No it isn't, and simply and plain do NOT do that.  You can reference
>> private
>> > resources from other packages with "@*android:type/name".
>> >
>> > And you can' t just make up new resource IDs that you want.  The numbers
>> > have very specific meanings -- for example the number "0x02080000" you
>> want
>> > to use is a number in the range that will be used for loaded shared
>> > libraries.
>> >
>> >
>> >
>> > On Mon, Feb 16, 2009 at 1:31 PM, Nick <[email protected]> wrote:
>> >
>> > > Since the support of shared resources is not supported, my only option
>> > > left is to include it in public.xml.  To prevent future compatibility
>> > > problems with stock Android resources, I wanted to start my resources
>> > > in a different range to prevent stepping on any future resources that
>> > > are added after mine. For example, I wanted to place my drawables
>> > > starting at range "0x02080000". However, it appears that the build
>> > > process requires all the public.xml stay in the same range for each
>> > > resource type (i.e. drawables start with "0x0103").
>> >
>> > > I'm willing to add this support in and submit it back to the project,
>> > > but I was wondering if anyone could point me in the direction of where
>> > > this checking is done?
>> >
>> > > Thanks,
>> >
>> > > Nick
>> >
>> > > On Feb 10, 8:26 pm, Dianne Hackborn <[email protected]> wrote:
>> > > > I don't know, sorry.
>> >
>> > > > On Tue, Feb 10, 2009 at 3:59 PM, Nick <[email protected]> wrote:
>> >
>> > > > > That's fine...I wanted to make sure there wasn't another way from
>> what
>> > > > > I was doing.
>> >
>> > > > > Is this issue in the Android bug/issue tracking system?
>> >
>> > > > > On Feb 10, 4:19 pm, Dianne Hackborn <[email protected]> wrote:
>> > > > > > Sorry true shared libraries are not supported right now, largely
>> due
>> > > to
>> > > > > the
>> > > > > > lack of support for linking to resources outside of the
>> framework.  I
>> > > > > don't
>> > > > > > have an ETA on when this feature will be in the platform, though
>> it's
>> > > > > > clearly something we want.
>> >
>> > > > > > On Tue, Feb 10, 2009 at 12:00 PM, Nick <[email protected]>
>> wrote:
>> >
>> > > > > > > If I understand the current framework correctly, it is
>> possible to
>> > > > > > > share resources to be used in new Java libraries (not those
>> > > included
>> > > > > > > in the open source project) by placing them in with the other
>> > > Android
>> > > > > > > framework resources.
>> >
>> > > > > > > However, I've only found one way to share these resources
>> across
>> > > > > > > packages.  I can modify the public.xml file in
>> > > frameworks/base/core/
>> > > > > > > res/res/values/ and expose the resources that the applications
>> > > need.
>> > > > > > > This is not ideal since my resources are now part of
>> android.R.*,
>> > > > > > > which potentially has backward compatibility problems if the
>> open
>> > > > > > > source project exposes new resources that overlap my
>> previously
>> > > > > > > defined resources.
>> >
>> > > > > > > Is there another way to make these resources available to
>> packages
>> > > > > > > without making them part of android.R?
>> >
>> > > > > > > NOTE - All the packages that will need these resources will be
>> part
>> > > of
>> > > > > > > the system image so I don't need to expose them to external
>> > > packages.
>> >
>> > > > > > > Thanks,
>> >
>> > > > > > > Nick
>> >
>> > > > > > --
>> > > > > > Dianne Hackborn
>> > > > > > Android framework engineer
>> > > > > > [email protected]
>> >
>> > > > > > Note: please don't send private questions to me, as I don't have
>> time
>> > > to
>> > > > > > provide private support.  All such questions should be posted on
>> > > public
>> > > > > > forums, where I and others can see and answer them.
>> >
>> > > > --
>> > > > Dianne Hackborn
>> > > > Android framework engineer
>> > > > [email protected]
>> >
>> > > > Note: please don't send private questions to me, as I don't have
>> time to
>> > > > provide private support.  All such questions should be posted on
>> public
>> > > > forums, where I and others can see and answer them.
>> >
>> > --
>> > Dianne Hackborn
>> > Android framework engineer
>> > [email protected]
>> >
>> > Note: please don't send private questions to me, as I don't have time to
>> > provide private support.  All such questions should be posted on public
>> > forums, where I and others can see and answer them.
>> >>
>>
>
>
> --
> Dianne Hackborn
> Android framework engineer
> [email protected]
>
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support.  All such questions should be posted on public
> forums, where I and others can see and answer them.
>
>


-- 
Dianne Hackborn
Android framework engineer
[email protected]

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

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

Reply via email to