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.
Related
I am creating one SDK for android which include the Activity, Services and Broadcast receivers.
Problem is when i generate the AAR file from my project and import it to other sample project my All the Activity, Services and Receivers names are visible from Manifest of my AAR file.
I don't want to expose any of my class name to users of My AAR file, Please provide proper way to hide my confidential code and classes.
Remember one thing "Everything is hackable" and java classes are decompilabel.
You can use the Proguard to Obfuscate your code
Have a look
https://developer.android.com/studio/build/shrink-code
With Proguard, it will also shrink your code and reduces the size of you AAR file
and change the names of the classes, then it is hard to recognize the functionality of your lib file.
Learn more about Obfuscation: https://en.wikipedia.org/wiki/Obfuscation_(software)
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 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.
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.
I am currently working on a Android Project where we are expected to merge our App with 2 more apps from vendors who wouldn't be sharing their code.So just wanted to know Is there any way we could just include there Source code as JAR Files in our project and then include their resources and point to them(I did do it using getResources().getIdentifier("splash", "layout", getPackageName()) But Its still not working ?? I think I have tried all possible methods so hoping you guys could help me with this.
To quote CommonsWare from this question:
Bear in mind that your packaged classes cannot reference resources (at
least not via R. syntax), and that JARs cannot package resources,
manifest entries, etc. If all you are trying to JAR up is pure Java
code (perhaps using Android APIs), then you should be fine.
Basically, you can only use JARs that contain pure java as libraries in your app, not entire other projects.
The Activities can be compiled into a jar and added to the main Android project and we need to add their project's resources into your Project. The only we could make it work is using the getResources().getIdentifier("splash", "layout", getPackageName()). Even the Widgets like TextView, Button and all those should be referred to using the getResources() method. Like, for example, If you want to perform a action on particular button then we need to identify them by getResources().getIdentifier("Button" /*id in the XML File*/, "id"/*type*/, getPackageName()).
One more thing: you need to specify all the Activities in your Main Android Project's AndroidManifest.xml file with their package name. I hope this solves something.
In order to support faster build times, the r16 tools are creating their own jar files inside of Android Library Projects. You can use this feature to solve this issue. If a vendor would like to release their Android Library Project but without source code, they can make a copy of that Android Library Project that contains everything except for the source code tree. Next, include the jar file from the original Android Library Porject (the one that the r16 tools built.) This will allow you to have a component you can distribute that does not require source code. The consumer of this new Android Library Project will need to manually add any necessary meta data to their own project's AndroidManifest.xml file as needed (Activities, Providers, Permissions, etc).