Does the Android Manifest check for the available components to be used before an application starts running, or does the system check for the Android Manifest every time a new component is being instantiated? By components I mean activities, services, etc...
What is the process involved?
Also, can an application still go back and forth to check on the android manifest even after it is running to check on xml activity attributes such as the android:name, android:label, or even intent filters, for different purposes such as to see whether a component to be used has already been defined?
Well to say it in a simple way-
Manifest contains permission like- "SD card read/write permission". So, while installing an app if you don't have a SD card than your won't get installed.
Again manifest contains "minimum SDK version"- which checks what OS version you have in your mobile, if your mobile OS version is less than the minimum version defined in manifest than the app won't install in your mobile.
In the manifest you have a list of all the activities and services too. So, without adding these in the manifest- your activities/services wont work.
So, these sort of checking and permissions are in manifest - the information the system must have before it can run any of the app's code.
Hope i have been able to keep it short and simple :-D
The manifest is a part of the app - it gets packaged with the app in its installation APK.
The manifest tells the system what APIs the application will use. When the app is installed, the system tells the user what sets of potentially sensitive APIs the application will use (as listed int he manifest) and if the user allows the app to be installed the system then assumes that the use of those APIs is permitted.
The OS will not permit the app to use other sensitive APIs that the app did not declare in the manifest.
Android Manifest file contains important information like the Java package name of the application, permissions, descriptions about activities,services... The system must have these information before running the app code.By this reason, the system doesn´t check the Android Manifest in runtime.
More here:
Android Manifest - Android Developer
Related
I want to code an automotive app which should simply display a map while the user is driving. I am developing with Android Studio 4.0.1 and in Kotlin. In order to create an emulator for testing, I used Android Studio 4.2 Beta 1 to download an automotive system image because in 4.0.1 no automotive system image was available.
I am stuck to make this app "distraction optimized", so unfortunately the app still gets overlayed with a black screen and the text "You can't use this feature while driving".
When I follow the Guidelines ([https://source.android.com/devices/automotive/driver_distraction/guidelines][1]), it seems that I simply have to add the following metadata to the activity-element in the manifest.xml (I only have one activity):
<activity>
...
<meta-data android:name="distractionOptimized" android:value="true"/>
...
</activity>
Of course I also request the following needed permissions (amongst others) to the manifest-tag in the manifest.xml file:
...
<uses-permission android:name="android.car.permission.CAR_UX_RESTRICTIONS_CONFIGURATION" />
<uses-permission android:name="android.car.permission.CAR_DRIVING_STATE"/>
...
as well as to the permissions array which I pass to the requestPermissions(...)-function
val PERMISSIONS_ARRAY = arrayOf(
...
Car.PERMISSION_CAR_UX_RESTRICTIONS_CONFIGURATION,
Car.PERMISSION_CAR_DRIVING_STATE,
...
)
requestPermissions(PERMISSIONS_ARRAY, 0)
In onRequestPermissionsResult(...) I find out that these two permissions are denied. But the user was even not prompted / asked to give that permission at first app start. Also in the settings there is no possibility to give the app these permissions. In a later piece of code getActiveRestrictions() always returns 255, which means that all restrictions are active, right? Another indication that the app is not allowed to handle the Driver Distraction on it's own, and therefore the OS takes care of it by not showing the app at all...
What am I doing wrong? What do I possibly miss? Does anybody have an idea?
It is not sufficient to mark an activity as DO in the manifest, it must also be downloaded/installed from a trusted source (like Play Store) otherwise CarPackageManagerService won't allow the app to be displayed in any restricted driving-state.
Some insight (which is not fully provided by the website documentation) can be gained from reading the following comment in the source code for 'CarPackageManagerService', which performs the checks on apps and activities to see if they are Distraction Optimized (DO), among other things:
https://android.googlesource.com/platform/packages/services/Car/+/master/service/src/com/android/car/pm/CarPackageManagerService.java#740
Effectively, what this means is that your app needs to be either:
A system app,
Whitelisted in a config.xml file, which is a resource file for OEMs to create configurations for their car services, or
Tagged as DO in the app Manifest, and installed by an allowed source. The list of allowed sources is loaded from R.array.allowedAppInstallSources.
An exception to these rules is if your OS is a debug build.
I'm writing an Android app, that will run on custom hardware with a ROM that I have control of.
The device will run a single application (as a launcher) and once the device is deployed I (generally) do not have access to it anymore. The app also has support for updating itself.
As such, I need a way to properly handle permissions for the app i.e. permissions need to be granted automatically (including dangerous ones) if they are ever added to the manifest.
Now, the app is being signed by the same certificate as the Android OS running on the device, and the app is placed in the priv-app directory when the device is flashed.
I assumed that this would automatically grant permissions but this does not appear to be the case.
I have tried adding android:sharedUserId="android.uid.system" to the manifest, and that does indeed grant all permissions, but since there are already quite a few legacy devices "in the wild", adding this option makes it so that the app can no longer be updated (throwing a INSTALL_FAILED_SHARED_USER_INCOMPATIBLE error).
So, what is the best way to handle permissions in this case? Is there some other voodoo magic I am missing here? Should I just bite the bullet, add the sharedUserId option and manually update all devices (undesired, but possible option)?
we worked for exam with our friends. I tried to explain manifest file, talking about how to do things. But I see that I did know why to register activities to androidManifest.xml. Still do not know :). Does anyone have an idea?
The manifest file is used by the system to know what kind of components do the application have. Without registering your Activities/Services/Receivers/Content Providers the system would have to scan and parse the whole apk every time someone wants to use a specific component to find it. This would be really slow, that's why there is the AndroidManifest.xml, which is a small file, and it can be parsed fast to find the required component.
Manifest file describes the following features...
Version Number and Version Code:
This is useful, when you are uploading the application in Google play or go for upgrade the existing published apk.
2.minSdk and targetSdk:
mentioned your min and max version number your application supports.
3.application tag:
used to set the first activity or home activity when you launch an application from laucher.
4.activity tag:
the list of all activities in the application declared as child tag in application tag for the easier navigation to activity manager.
When we switch one activity to another activity, the activity manager checks whether this activity is declared in manifest file or not. If not found throws exception.
Uses: Developer can have look at all the activities at a glance (By Manifest file)
5.Filter tags: By intent filters in activity tag, User can open any kind of application activity.
Uses permission and Uses features:
All application resources are declared here.
example: Internet connectivity is needed for your application, Uses WIFI in your application.
I'm new in Android. I have an Idea to enrich user's knowledge whilst installing a desired application.
the idea is developing an application that can analyze .apk file of the application to check if it's over-privileged or not. and inform the user if this application which he's trying to install is over-privileged or not.
but since there's already a mechanism from Android which asks user's consent to grant whatever permission the application requests, I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it or it can not.
I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it
None of these are possible, sorry. You are welcome to create your own custom firmware that has this feature, but you cannot create this capability via an SDK application, for obvious security reasons.
I am not far from where you are ~ the entire mechanization you seek is based on an xml file in the "root" of the installation - it is called AndroidManifest.xml = all permission based issues should begin original first efforts on that file:
The AndroidManifest.xml File
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. Among other things, the manifest does the following: .....
the "app-store" web based distribution system is supposed to pick that up and not only make some decisions on what to present to the user but as well differentiate to some extent what to do in the matter but as I just got a Droid-X emulator available in my installation I can tell you for a fact that "versioning" is subject to oversimplification as we cannot rely on users being tech-geeks
I want to define a permission in my Android app, and let other third-party apps to use. This permission is used to restrict calling of my modules. That is, third-party apps must request the right permission to call my module, just like using system permissions defined by Android system, android.permission.INTERNET or so.
In my test, I defined the permission in my app, say "my.apps.permission.my_permission", and then install it on emulator. In some of my Activities, android:permission="my.apps.permission.my_permission" property is added. This property forces the apps calling my activities must have the right permission "my.apps.permission.my_permission". Then in a test app, request the permission in AndroidManifest.xml, <uses-permission android:name="my.apps.permission.my_permission" />
The problem is, in the test app, which will call my permission-required activities, when I call startActivity(), I got a SecurityException : Permission Denied. But, if I defined a permission with the same name in the test app, everything works fine.
And, the followings are my conclusions:
1) It seems that, the permission defined in my app, "my.apps.permission.my_permission", is not visible to other third-party apps. How to make it visible, so that other apps can use my permission just like the ones defined in Android system?
2) Even is visible, Android won't check user-defined permissions with name conflicting.(I test this by define a permission with name "android.permission.INTERNET" in test app and overrides the system-defined one, and require "android.permission.INTERNET" in my app, and still, everything works fine.) If so, every other apps can define a permission with the same name that my module requires, and cheat my app. Is that right?
Anyone can help?
Thanks a lot!
I got the answer.
My own app, which defined the permission for other apps to use, must be installed before other apps who want to use my permissions. Otherwise, those apps must be re-installed, to use my permissions. No other operations or codes are needed, just <uses-permission android:name="my.apps.permission.my_permission" />, the same as other system defined permissions.
And, several apps may define permissions with the same name, conflicting with each other. The first installed app occupies the conflicting permission name, others won't overwrite or change the original permission.