Just making sure.
If I have an app that has a separate back-end library service app; I need to place my permission declarations in the manifest file of the main application even though the library portion of the application is actually performing the functions declared in the permission declarations.
Basically, nothing in your library's manifest is used when building the application. Even the package name is ignored. (This actually causes problems if you define custom attributes in XML and need to use an application namespace to reference the attributes in other XML. You have to copy the XML files into the application project and change the xmlns declaration to match the application's package name.)
You are correct. Just like if you were to use an Activity from a back-end library, the Activity must be declared in the main applications Manifest.
Related
I have a base ai.application.resident and I added a new module as dynamic feature com.application.wearable
When creating a bundle, I get this error:
app/base/build/intermediates/bundle_manifest/debug/AndroidManifest.xml:2282: AAPT: error: resource style/WearableTheme (aka ai.application.resident:style/WearableTheme) not found
There are also other resource errors in the bundle. It seems like the manifest is only looking for the resources in the base's package.
What is the proper solution for this? Do I have to move my themes in the base package?
Thank you
PS: This wearable app if my first android app. Please be understanding!
Thank you in advance.
Please provide more detail of your module arrangement, gradle files, and AndroidManifest.xml file(s).
If you are trying to reference resources or classes in a dynamic feature module from your top-level app, it is like you are trying to reach an object that is on the other side of a wall: the laws of physics don't allow it. Here in Android resource availability gravitates to the dynamic feature module within which the resource exists. Only through reflection could you reference them, but that approach is dangerous as the dynamic feature module won't always be there for your users in the wild.
I think you should look at Manifest Merging to hold your Wearable dynamic feature module's AndroidManifest content within the dynamic feature module (where the resources it wants to reference is available). If/when a user downloads your dynamic feature module, your app's package will be updated with the merged module.
Is it possible to specify some information, such as API keys, in a file, and then somehow inject this information into the AndroidManifest file (maybe during the build process)?
For my particular use case, the documentation for react-native-maps requires adding a Google Maps API key to the AndroidManifest file. However, I'd like to keep sensitive information out of the AndroidManifest file (instead, inside a file that will eventually be gitignored for example).
On a side note, from this question, it seems that all information inside the AndroidManifest is available to all packages on the same device. Is this still true?
If the information is only needed in the manifest, you can define manifest placeholders in your build.gradle file and reference them using ${} macro syntax in the manifest.
If the information might be needed elsewhere, consider using string resources created via resConfig in your build.gradle file.
The build.gradle file can pull the actual values from gradle.properties, a custom properties file, via some API call to a server, or whatever else you want, given sufficient Gradle/Groovy/Java coding. Typically, I have gradle.properties listed in .gitignore, and so I put this sort of thing in there, though I am not certain if that approach is common practice.
it seems that all information inside the AndroidManifest is available to all packages on the same device. Is this still true?
"All" is a strong term, but I would say that the vast majority of information in the manifest is visible through PackageManager. Sometimes, it's not directly accessible (e.g., I don't recall a way to get the <intent-filter> list for a component), but it's still there if you find the right way to get at it.
I am implementing a library, and I would like the functionality of this library included in applications that I develop with very little effort. For example, I would like each application I develop to implement a content provider that supplies a path to a file.
At present I identify applications that support the library using a meta-data tag. I would prefer it if I could add the content provider's tag at compile time, rather than explicitly adding the tag to the manifest of each new application I develop.
My question: Is there a way of inserting code into the manifest at run-time?
Is there a way of inserting code into the manifest at run-time?
No, sorry.
For example, I would like each application I develop to implement a content provider that supplies a path to a file.
If that is all the ContentProvider is for, this is akin to swatting a fly with a truck. Just call some method on some class exposed by the library from the application, passing in the path. Or, have the path name be held in some pre-defined resource name (e.g., R.string.this_is_the_path_yo), and look up that resource by name at runtime from the library. Or, have the file be in some pre-defined location (e.g., within assets/) and skip the whole resolve-the-path problem.
I have been happily refactoring code from different versions of the same app (paid/free) into Android library projects so that the actual apps can simply customize the library and reduce code duplication.
One thing I'm started to wonder is what getApplicationContext() inside the library code means? Is is the same ApplicationContext as one would get from the child apps? What happens when I access SharedPreferences from a library project's getApplicationContext() instead of the original app's getApplicationContext()? Will the SharedPreferences file be same or different?
What if I had used the activity to access SharedPreferences? Does it matter that the activity is now a library activity and not the original app? Is the SharedPreferences the same?
Thanks for clarifying.
When the APK is packaged up then all classes will be belong to the main application.
call getApplicationContext().getPackageName() and it will return the app's package name, and not the library's package.
I have the same setup for a free/paid application and no issues when I moved my classes into a library project.
However you have to check your xml files (manifest, widgets, etc.) to use the full package name of your library project.
A library project is almost like having all the code in one project. There are a couple of things to watch out for related to namespaces but generally it works very well.
e.g. Your library has its own namespace
Library package name = uk.co.lib
Main App package name = uk.co.app
Activities in the library that you want tro access from the main app have to be added to the app manifest. Activity named A in library project would be added to manifest in main app like this:
<activity android:name="uk.co.lib.A">
Accessing shared preferences etc would give the same result from either namespace and would return the preferences for the app.
There is only one application so there is only one ApplicationContext
Can anybody explain me in simple words what is the use of Manifest file and
R.java file in android.
Why do we need these files while making an application?
check this link,
http://developer.android.com/guide/topics/manifest/manifest-intro.html
Manifest
Every application must have an
AndroidManifest.xml file (with
precisely that name) in its root
directory. The manifest presents
essential information about the
application to the Android system,
information the system must have
before it can run any of the
application's code
R.Java
It will have identifier for all resource used in our project
thank you.
Manifest file:
It is a declaration file.
Here only Which activity should start first, that has been declared.
It declares which permissions the application must have.
It also declares the permissions that others are required to have in order to interact.
It declares the minimum level of the Android API.
It lists the libraries that the application must be linked.
All the component should declared here.
The components are activities, services, broadcast receivers, and content providers.
R.java file:
It is an auto-generated file by aapt (Android Asset Packaging Tool) that contains resource IDs for all the resources of res/ directory.
If you create any component in the activity_main.xml file, id for the corresponding component is automatically created in this file.
This id can be used in the activity source file to perform any action on the component.
Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code.
Check the following link
http://developer.android.com/guide/topics/manifest/manifest-intro.html
A project's R.java file is an index into all the resources defined in the file. You use this class in your source code as a sort of short-hand way to refer to resources you've included in your project. This is particularly powerful with the code-completion features of IDEs like Eclipse because it lets you quickly and interactively locate the specific reference you're looking for.
Check the following link
http://developer.android.com/resources/tutorials/hello-world.html
In short terms Manifest provide the basic information of the application to Android Operating system.
For example say you have a feature in your app that scans a QR code which requires your app to access camera that won't work until unless you get the consent of the user to access their's phone camera which is done by runtime permissions.These permissions needs to be defined in the Manifest file for Android OS to know that this app will be using something related to camera of user's phone.
The manifest file describes essential information about your app to the Android build tools, the Android operating system, and Google Play.
The permissions that the app needs in order to access protected parts of the system or other apps.
The hardware and software features the app requires.
The manifest declares anything that the operating system needs to know about your application.
You declare what permissions the OS will grant to your app when it executes.
You will also declare package information about your app. By doing that the OS will know what applications are installed.
Finally, you will declare custom implementations of the Foud Application Components (Activity, Service, BroadcstReceiver and ContentProvider classes) you have made.
You see, your application, any activities and services are not created by you. They are constructed by the OS through intents on behalf of your app. Likewise, all BroadcastReceivers need to be registered at the manifest, so the OS knows what application's receivers are registered to receive a broadcast, so it notifies them. Finally all ContentProviders must also be declared in the manifest so other applications can register to be provided content by your content provider.
In other words, in the manifest you put everything that the OS needs to know about your app in order to execute it and manage its components. Infact, anything you cannot access or declare directly by code, and you need the OS to take care of it...
I think it is a good idea for you to read through the Android Hello World.
Both AndroidManifest and R.java are explained.