How to reference a string from another package in

Question

The Android documentation tells me that I can access a string from another package by using the "package name", whatever that means:

@[<package_name>:]<resource_type>/<resource_name>

So in my manifest I want to access a string that I've placed in a separate library project, in the com.globalmentor.android package---that's where my R class is, after all:

    <activity
        android:label="@com.globalmentor.android:string/app_applicationlistactivity_label"
        android:name="com.globalmentor.android.app.ApplicationListActivity" >
    </activity>

That doesn't even compile. But this does:

    <activity
        android:label="@string/app_applicationlistactivity_label"
        android:name="com.globalmentor.android.app.ApplicationListActivity" >
    </activity>

Why? What does the Android documentation mean which it talks about the "package_name"? Why doesn't the first example work, and why does the second example work? I don't want all my resource names merged into the same R file---I want them partitioned into packages, like I wrote them.

Answer 1

Whether you like it or not, library project resources are merged into the app project resources, resources with the same name from the app project overriding those from library projects. Look at the R.java file in the app project to confirm .

You can access publicly exported framework resources by using @android:string/foo ('android' package), but I don't think you can export resources from a library project like this (yet).

Answer 2

In short: package name prefix is for shared libraries, not for your apk.

The documentation reads:

To reference a system resource, you would need to include the package name

This corresponds for external shared libraries (and their resources), your application is linked against (e.g. maps). They have their own R class, not merged with that of your application.

These are all standard android packages and shared libraries you mentioned in section of android manifest.

As Nikolay pointed out, all app resources are merged, that is why the majority library projects use prefixes like abs__ for their resource names.

See Library projects doc for additional info.

Answer 3

Name your resource in your package as com.globalmentor.android.app_applicationlistactivity_lab and not just app_applicationlistactivity_lab.

<?xml version="1.0" encoding="utf-8"?> <resources> .... <string name="com.globalmentor.android.app_applicationlistactivity_lab">...</string>
.... </resources>

Then you can access it from XML as

"@string/com.globalmentor.android.app_applicationlistactivity_lab"

and programmatically by

getResources().getString(R.string.com_globalmentor_android_app_applicationlistactivity_lab);

without conflicts.

Answer 4

Why?

Because you added that library project to your project, so Android merges the resources, so the last project that is built "wins" the name. For this reason it's a good idea to prefix resources. In this case, the "package_name" can't be used as you have those resources in your own project. I imagine this is your case because it compiles without the package name.

If you don't have that library project added to your project, then a possible solution is to use SharedUserId.

Source: http://developer.android.com/tools/projects/index.html

Development considerations

As you develop your library project and dependent applications, keep the points listed below in mind:

• Resource conflicts Since the tools merge the resources of a library project with those of a dependent application project, a given resource ID might be defined in both projects. In this case, the tools select the resource from the application, or the library with highest priority, and discard the other resource. As you develop your applications, be aware that common resource IDs are likely to be defined in more than one project and will be merged, with the resource from the application or highest-priority library taking precedence.
• Use prefixes to avoid resource conflicts To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the project (or is unique across all projects).