I am using android studio 0.45 with gradle build to build my project. (gradle version 1.9). In my test folder I creating an extra activity that I don't want to be part of my release code. Where do I specify this activity in the Android Manifest. The gradle setup only allows for one AndroidManifest file as far as I can tell.
I am also using extra permissions in the test project to simulate phone calls that I don't need in my release code. How do I setup the manifest file so as to add permissions on a build specific mechanism...
It sounds like you should set up a product flavor for your test type, that includes the extra activity, and extra permissions in your AndroidManifest file. A flavor lets you have source files that are specific only to that flavor, and properties in the manifest that get merged together with the main manifest at build time.
Read the docs at http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors and give it a shot.
Related
I understand this question is vague, but can someone outline the rules and/or how we should be dealing with multiple modules?
I've been trying to separate my app out into a base feature module, application module and instant app module.
However I've been having a nightmare building it.
I've tried searching online but there isn't really much documentation in it?
Ive got two activities in my base module manifest, as I want these in both my installed and instant app. Do I then need to copy these activity manifest entries into my other manifests? I tried running my installed apk without adding in these activities (I thought it might pull it from the base module) but then android studio says can't find default activity to launch the application with. So I need to copy the activity entries into all manifests?
I've also got manifest entry conflicts from all the libraries I'm using. FacebookInitProvider , FacebookInitProvider, CrashlyticsInitProvider etc. I don't have these entries in any manifest, they are adding themselves in to every manifest causing merge conflicts when building.
With the build grades, I've put in the base just the libraries necessary to run the base / instant app (to keep it as small as possible). The installed gradle then has all the extra libraries for the full sized application. If I use
implementation project(":base")
Will it automatically pull in all the dependencies that base uses? Or do I need to redeclare these?
I ask because after getting the app to build, firebase and firestore was causing an exception on getting the instance with the message "Firestore module not found" which makes it look like it hasn't pulled in the dependencies properly?
I apologise for the lengthy post, but I'm honestly at the end of my tether here. Truly stuck!
Im not sure I understand all your project structure correctly so I will give you general information on an app with modules:
Lets say you have the application called "appone" and have a module called "moduleone"
In the module gradle file you declare the minimum you need for the module to work properly by itself and in the manifest just configuration specific for the module that will not be required to be defined in the appone manifest.
Now in the appone manifest, this is the main file, you will have to set here the activity declarations and app permissions (not in moduleone), android studio merges the two files automatically so when you compile it will make one manifest file with both manifests contents so this is what can make conflicts if you declare the same or conflicting data on both files.
In the appone build.gradle file this is where you declare the implementation project(':moduleone'), and the implementation of libraries required by appone.
If for example moduleone uses firebase library and in appone you also directly require access to the firebase library you could declare it in both build.gradle files, you just need to make sure both use the same version.
Also you will need to declare moduleone on the settings.gradle file using: include ':moduleone'
appone is declared as an com.android.application and moduleone is declared as com.android.library.
Also appone has in its manifest an activity declared with the LAUNCHER category.
I have an Android project which for some various reasons might need to split the functionality of the single AndroidManifest.xml file into smaller files.
I know it is possible to merge these files specifically if they exist inside a dependency AAR file, where there are specific rules which dictate the actual preference. But since I only have one application, I would like to ask if there is a way to inform the build system that multiple file manifests are required to be merge.
Any idea if there is a methodology about it?
You don't need to inform build system to merge manifest files. If a dependent library has a manifest file, it's manifest is automatically merged into the app during build time.
i have imported someone elses project and i see 3 manifests files .
one for main,one for test and another one in the root folder .
what is the advantage of having more than one manifest ?
how do the project built with more than one for example if i set activity as single task in one file and single top on another ?
if someone can explain how does it works and what would be the right way to handle this .
You usually would require more than one manifest file when you have more than one build type or product flavors.
Gradle merges all manifest files into a single manifest file. The merging priority is Product flavors and build types specific manifest files.Main manifest file for the application.Library manifest files.
Imagine the case where you have a free version and a paid version of your app. The root manifest file will have the segments shared by both the versions. The paid version would have the part specific for it, like checking license.
If I set a property in my gradle.properties file using the command line like so:
gradle build -Dproperty=myString
and in my Android project have a configuration.properties in my resources directory, how can I get configuration.properties to read the new property from the gradle.properties file?
I've tried the following setup:
gradle.properties
property=defaultString
anotherProperty=defaultBoolean
configuration.properties
myProperty=#property#
POTENTIAL SOLUTION 1
Using a configuration.properties file for each flavor.
The per-flavor resources sounded like a great idea, but I wanted to have a default list in main, and only override the properties needed. I have a lot of properties, and some flavors would only need to override one. So this does work, but is not ideal.
POTENTIAL SOLUTION 2
Using buildConfigField to pass what I need to the Java code.
The problem here is that I have two modules: app and api - where api is a dependency of app. Setting a buildConfigField in the app build.gradle lets me access them in the app code, but I would also need to access it from the api module.
To vary property values per flavor, you can use per-flavor resource files. For more information, check the Android Gradle plugin docs.
PS: If the property values are only used to activate different parts of the codebase, consider using per-flavor code instead.
I'm developing an application, with another project as my library.
What properties are merged in the manifest files?
Example - If the permissions are already specified in the Library's manifest file, do they need to be specified again in the applications manifest?
Also, if there is a service in the Library project, do I need to specify again manually in the Applications manifest too (additional to library's manifest).
Thanks
There is a section of this page: http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject that says you must (re)declare all of the bits of the library project that your application will be using in the manifest file.
Declaring library components in the manifest file
In the manifest file of the application project, you must add
declarations of all components that the application will use that are
imported from a library project. For example, you must declare activity, service, receiver, provider, and so on, as well as permission, uses-library, and similar elements.
Declarations should reference the library components by their
fully-qualified package names, where appropriate.
Personally, this seems redundant, but it may be because the app doesn't need to use all of the components of the library project, and the app shouldn't assume it will.