11

I'm writing an SDK and would like developers to be able to create an activity-alias whose targetActivity is set to an activity inside my SDK. I'm doing this because I'd like them to be able to customize the intent filter on a specific activity in the SDK. If in the sdk's manifest there is ActivityX, I'd like them to be able to write an activity-alias like this in their app's manifest:

<activity-alias
    android:name="abc"
    android:targetActivity="ActivityX">
    <intent-filter>
    ... user's custom intent filter
    </intent-filter>
</activity-alias>

The problem I'm coming across is that the targetActivity has the restriction that it:

"... must match the name attribute of an activity element that precedes the alias in the manifest."

This is a problem because no matter where I place the activity in the sdk's manifest or where I place the alias in an example app's manifest, the alias always comes before the activity in the final merged manifest causing an INSTALL_PARSE_FAILED_MANIFEST_MALFORMED error.

One idea is to put an alias without an intent filter just after ActivityX is declared in the sdk manifest and hope that the two aliases will be merged together and stay in the sdk alias's position. But I can't figure out how to do that. One reason that might not be working is that two aliases may not be able to conflict.

Do you have thoughts on solving this via a merge solution or some other technique?

lf215
  • 1,185
  • 7
  • 41
  • 83
  • 1
    Android libraries are very limited in corner cases like this. I can see why you want to do that. I've no idea but I would suggest you post in in b.android.com as a feature request to the tool team – Daniele Segato Mar 04 '16 at 18:37

1 Answers1

4

An identical issue was brought up in the AOSP. A workaround to the problem is described there as follows:

Manually include the manifest entry for the Activity from [the sdk] in the manifest of the application project, placing it before the activity-alias entry.

Despite the fact that this workaround has the problem of

... duplicate code across manifests.

it seems that the project maintainers deemed this solution as adequate. There is no indication that a fix to the underlying problem will be released any time soon.

lf215
  • 1,185
  • 7
  • 41
  • 83