In my project IntentExamples, I have this filter, corresponding to a service.

                <action android:name="biz.rpcodes.apps.intentexamples.START_SERVICE" />

In another project, UseExampleService, I have something like:

Intent i = new Intent("biz.rpcodes.apps.intentexamples.START_SERVICE");

...guided by this answer: https://stackoverflow.com/a/16439551/5181778

My question is: How can I best manage these Intent filter Strings across multiple projects? The best solution I have now is to make a class that I am copy and pasting from Service project into the other projects, i.e.:

class ExampleServiceIntents {
public static final String ExampleServiceIntents.START_SERVICE = 

While I could import the Service classes themselves, new Intent(this, ExampleService.class) , I would like to keep the Service classes in their own project.

  • Why do you want to keep the service in a separate project? That just introduces the possibility that the app with the Service is not installed. And you can always create a library which contains these constants and then use that library in each project. Nov 18, 2015 at 12:48
  • I currently have libraries, and I find it cumbersome in Android Studio to import them. Usually Android Studio will break something and I am left copy pasting files one by one. (Separate question/issue though) Plus, these Apps are in-house, I can control the requirements, this is not for Google Play Store etc. Plus do not need all three apps running same code, in some ways it is better to put requests in queue on one process for our design. (Alot to explain)
    – Rick Page
    Nov 18, 2015 at 19:16
  • How is it cumbersome to import them? You are going to break a lot more by copying classes by themselves then just copying full working modules. And why aren't you using a maven server like SonarQube or Artifactory to host your in house libraries? Then importing the library would just be like importing any other maven project - adding one line in the build.gradle. Nov 18, 2015 at 19:23
  • "break alot more" Yes, totally. But the only way I could figure to use the modules was by importing them, in which case Android Studio copies all the files. "... maven server " Thank you for the suggestion, I am going to look into this.
    – Rick Page
    Nov 18, 2015 at 20:37

1 Answer 1


Android Shared Libraries or operating-system dependent symbolic links.

Option 1: Shared Android Library

A formal Android library imported into each project.

Pros: Type safety. Cross-platform and works with source control. Full syntax checking and editor support.

Cons: It is still a bit annoying to import projects as libraries via the current editors (Android Studio or Eclipse with ADT) since they don't offer very good interfaces to do this. If you have to do this task often but not so often you remember all the steps each time, then this might not be worth the effort. But if its a one or two time thing to start with, then you don't have to do it again, it's not too bad.

Option 2 Symbolic Links

Symbolically link a common source file in each project. Then both projects will see the file and changes to it, so they can stay in sync.

Pros: Much simpler to implement.

Cons: Symbolic links don't work so well with source control tools. Not cross-platform (for development) since symbolic links are very different from one operating system to another. Not real clear to a new developer coming onto the project that changes in one automatically get shared with the other.

Therefore, because the symbolic links option have more cons then pros, I would generally recommend the shared library solution for most projects. But, if your particular project doesn't need the features from the cons column of the symbolic link, then that's probably easier. It depends.

PS: There is a terrible third option of having a third full Android application that offers an Android data Provider that offers up the string values. But at that point you need to communicate with that app with special strings that need shared too, so you're only adding a step of abstraction but haven't solved the problem.

  • Interesting idea about the Provider. But, a step backward, I agree. Thank you for recognizing that the current editors "don't offer very good interfaces to do" shared android library, and for the pros and cons.
    – Rick Page
    Nov 18, 2015 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.