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.
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.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With