I have created a library module that is working when I add the permissions and activity tags to every project's manifest that uses it.
I'd like to encapsulate it as much as possible, is there any support for exporting a library's manifest tags so that I, and others can skip this step?
http://developer.android.com/tools/projects/projects-eclipse.html#ReferencingLibraryProject alludes to 'no'.
Have you tried setting the manifestmerger property to true. See this question.
Related
I experimented a bit with custom android manifests, and now I'm here with a broken manifest and I'd like to let unity regenerate the manifest. How can I achieve this?
Thank you in advance &
Best Regards
I'd imagine that if you unchecked the option to use a custom manifest, it would disregard the manifest you added. If you want to reset the manifest you were editing, you could just start a new project and copy and paste the manifest from that project. It's a pretty sparse file normally until the build populates it.
Reimporting the project fixed it.
I have a project with a product flavor that uses a different activity than the main code. I had to define that new activity in a second Manifest file, but I still want to use the original main Manifest as well. But with 2 Manifests with 2
application tags, I get 2 instances of the app installed on the device. Is there a way I can make this work, or will I just have to copy/paste the whole original Manifest and take out the link to it?
I would refactor to an Android library, where all common stuff is located inclusively the manifest. And an app that includes this library as dependency with its own manifest. When building the app the manifest merger should pick up the manifest from the library and merge it with the manifest of the app.
The library could also implement both flavors.
Background
In the past, when Eclipse&ADT were the official tools to develop for Android, you could simply use "manifestmerger.enabled=true" inside the "project.properties" of the app's project, and you got it merging all of the libraries' manifests automatically (and I've posted about it here).
This worked, sometimes. It had a lot of weird issues, and I always preferred to just avoid using it, and put what is needed into the main manifest file manually.
The problem
Somewhere on 2014, Google announced that the new Android-Studio (0.1 I think), together with Gradle, will allow you to choose exactly how to perform merging of libraries' components.
However, the new instructions (link here) are very complex and I really (really) tried to understand how to use them, and also didn't find samples of how to use them.
It's not that I didn't understand anything, but I'm not sure if I understood well.
What I've found
On the bright side, I've found out that merging is done completely automatically, so if you have a BroadcastReceiver on the library's manifest (and as a class, of course), it will be added to the app's project that uses it.
The question
I can't simply ask everything to be explained. I think it will be enough to ask those questions:
How can I choose which app components (permissions, activities,...) to be ignored from being auto-merged?
How can I point override app components (of the library) attributes (on the app's project) ? for example the theme of the activities?
Is there a way to completely disable the auto-merger for the manifest files?
What happens with manifests of dependencies that are inside repositories? Are they merged too?
Are there any tutorials/samples/videos regarding this new (well new for me) feature?
Are there any things I should be aware of when using the auto-merger?
I hope those questions are representative enough, informative enough, yet not too hard to answer for people who know.
1. Disabling elements
You can always explicitly disable permissions and features in your app's manifest and override any library values. And i found that you can disable elements from library.
Example
Consider the following code from the above link:
<activity-alias android:name="foo.bar.alias">
<meta-data
android:name="zoo"
tools:node="remove" />
</activity-alias>
By having this code inside your manifest you ensure that the merger finds any <activity-alias> elements with android:name="foo.bar.alias" attribute and removes a <meta-data> element if it has the android:name="zoo" attribute. It removes just the "zoo" meta data. Not the activity alias. If you specify this in your main manifest it will be effective on anything that has been merged so far (elements from libraries).
Example #2
Since you requested an example with activities, this is what I've come up with:
<activity android:name="com.example.ui.MyActivity" tools:node="remove" />
This line will make the merger remove any activities with android:name="com.example.ui.MyActivity" attribute that have been merged so far. So if you specify this in your main manifest it will effectively remove any com.example.ui.MyActivity entries that might have been merged from libraries.
2. Overriding attributes from library
The order in which the values are merged are described here. Basically, it goes like this: libraries, then main manifest, then flavors and build types manifests if you use those.
What are build types?
The default are "debug" and "release". You can define your own and override settings like signing or proguard. For your purposes you could say it's the equivalent of run configurations.
It works like this: you put your default and shared values inside the main manifest. Then in flavor manifests you override the values you need. Google "gradle flavors" for more info.
The following example is taken from a previous version of manifest merger documentation.
Override an attribute coming from a library
Using tools:replace="x, y, z" will override x,y,z attributes from the
imported library’s activity XML declarations.
Higher Priority declaration
<activity
android:name="com.foo.bar.ActivityOne"
android:screenOrientation="portrait"
android:theme="#theme1"
tools:replace="theme"/>
with a lower priority declaration :
<activity
android:name="com.foo.bar.ActivityOne"
android:theme="#olddogtheme"
android:windowSoftInputMode="stateUnchanged"
android:exported="true">
will result in :
<activity
android:name="com.foo.bar.ActivityOne"
android:screenOrientation="portrait"
android:theme="#theme1"
android:windowSoftInputMode="stateUnchanged"
android:exported="true"/>
3. Disabling manifest merger altogether
See Disable Manifest Merger in Android Gradle Build.
android.applicationVariants.all { variant ->
variant.processResources.manifestFile = file('src/main/AndroidManifest.xml')
variant.processManifest.enabled=false
}
In what file do you put this?
At the end of your module's (not root project) build.gradle.
4. Are manifests from dependencies merged?
Yes they are (they're libraries).
Is there a way to block merging certain library manifests?
Not that I know of, sorry.
5. Any tutorials?
Depends on what are you trying to achive. So far it always worked for me out-of-the-box.
e.g. http://www.myandroidsolutions.com/2014/04/10/android-gradle-manifest-merge/
The manifest merger documentation (link below).
I don't know about any videos.
6. Anything I should be aware of?
You can check the generated manifest if you get suspicious about extra permissions etc. It's located in project/module/build/intermediates/manifests/full/[flavor]/build-type/AndroidManifest.xml.
Source: https://developer.android.com/studio/build/manifest-merge
Some of the links in this thread are obsolete. Here's the main one that is updated related to auto merger of manifests, by gradle, for Android AARs.
https://developer.android.com/studio/build/manifest-merge
While writing Android manifest some configuration I must put inside "application" section (eg. list of activities) and some outside it (eg. uses-sdk). Why? Is there any general rule what goes inside "application" section and what outside? Or was it pure random arbitrary decision by Android creators?
Not really a programming question. If you follow commit history of AOSP you might get an answer. Or track down Andy Rubin and ask him :)
With the current layout, you could theoretically have multiple applications inside the same APK. Stuff that is common to all applications will got at the highest level (uses-sdk, etc.), everything else inside the corresponding <application>.
Definitely it is not a random decision.
The Format is something like you have define the configurations pertaining to any application such as its activities and services inside tag because ofcourse they are related to your application.
And General libraries you use and Permissions outside of the tag which complement your application.
Take a note of the structure of the manifest file here
To get concept in detail try here.
I want to have a normal class file in my android package that is not a component but will be used by an activity. Is this allowed? How do I add this in the manifest if required?
Right now it is not part of my manifest and I am getting an 'INSTALL_PARSE_FAILED_MANIFEST_MALFORMED' error in my Android project and don't know if it's because of this generic class file.
Thanks
Is this allowed?
Yes.
How do I add this in the manifest if required?
You don't put it in the manifest.
It's not needed to add to the manifest. You can have as many "normal classes" as you wish (by normal i suppose that are classes that do not extend activity).
Take a lot at LogCat during install to check what the problem is.