Develop Reference

At what point does the system check for the Android Manifest?

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

Force stop packages in android

hi everybody
i need some help please does anyone know how can i put this in my manifest tag in androidmanifest.xml file:
android:sharedUserId="android.uid.system"
==>because when i do the deployment failed .
and how can i use this permission :
<uses-permission android:name="android.permission.FORCE_STOP_PACKAGES" />
==>because xamarin studio tell me it's a unknown permission
to use this:
ActivityManager am = (ActivityManager)GetSystemService (Context.ActivityService);
am.forceStopPackage(PACKAGE_NAME);
_Any help will be appreciated _

Setting the sharedUserId to android.id.system actually means declaring your app to belong to the system. You cannot do that unless your app is actually signed with the system certificate. In order to get that certificate, you would have to negotiate with the manufacturer of the device. The only possibility you would actually be able to get the system key is running a firmware on your device that you built and signed yourself.
ActivityManager.forceStopPackage() is reserved for system applications and there is no chance to use it in a user-space application.
You can find various explanations on the Internet and on SO, e.g. here: Android Permission Denial: forceStopPackage()

If your goal is to quite your app, I would direct you to this question:
Is quitting an application frowned upon?
Which sums up how and why you might close your own application.
Actually terminating the application is near impossible, but sending it to the back ground or finishing all activities gets the similar effect of being gone from the screen. This is by design and is explained in the article
To close other applications is either a ROOT only or system specific. So your application could request root permission on android if available. Otherwise, I believe it is possible to negotiate a app with some root access through google play but I assume it is very complicated.

How to manage installed apps (with root permission if necessary )?

Android users can go to the "manage application" (AKA "applications manager") screen, choose an app and make a choice of what to do there using the "App-info" screen.
I wish to make an app that allows the user to make those choices in even an easier way (maybe even batch operations).
How do I access each of the features there? Which permissions would I need and for features that are not available via the API, how could I get them via root access?
The features I'm talking about are:
Force stop.
Uninstall last updates.
Disable.
Uninstall - for this I actually know how to do it, but it needs confirmation of course:
final Uri packageURI=Uri.parse("package:"+packageName);
final Intent uninstallIntent=new Intent(Intent.ACTION_DELETE,packageURI);
Toggle "show notificaions".
Clear data
Clear cache
Clear defaults. I would also like to know how to set as default and get all registered intents and their currently default apps (which will handle them).
View app storage usage in both external & internal storage (and cache)
If you don't know what I mean, here's a screenshot of the app-info page:
I've also found some interesting Android permissions that existed ever since API 1, but I can't find any examples of how to use them. Such permissions are CLEAR_APP_CACHE , DELETE_PACKAGES , and CLEAR_APP_USER_DATA.
What I have found is a Samsung code example (available here) that has a permission of CLEAR_APP_CACHE, but I can't find where they use it, if at all.

how are android security permissions checked at run-time?

This question has been asked before at How does Android enforce permissions?. While the discussions there are good, the question is still not fully answered.
In the development environment, exceptions are thrown when the app tries to do something that requires permissions not declared in AndroidManifest.xml. So how does the run-time system implement the run-time checking?
I guess it's most likely done in the core framework, which may or may not need support from native code. But I don't know what source code files in AOSP are relevant to this.

Android uses a lot of the standard Linux(-kernel?) mechanisms especially when it comes to hardware restrictions.
Every app gets assigned a new unique (Linux-)user id and whenever the app process is created the system creates it with that user id. The id will never change unless you remove the app. That means for accessing the lower system levels your app will appear as a certain user and every (Linux-)permission system that works with users will also apply to your app.
If you request WRITE_EXTERNAL_STORAGE in the manifest your app will also become member of the (Linux-)group (called sdcard_rw) that has permissions to write to that storage. Permissions on the filesystem are enforced to only allow writing to the system user (=owner) and the sdcard_rw group, anyone else (=other) may only read. See also Is Google blocking apps writing to SD cards
By doing that Android has to do pretty much nothing except for setting the correct UID/GIDs of the processes it spawns once the app starts and the rest is handled at lower levels. Apps that are not member of a certain group simply don't get access to certain hardware.
List of permission <> group mappings: platform.xml
There are also some (Android software) restrictions that are based on either the signature of your app and / or simply by looking up the permissions your app requested: e.g. ContextImpl#checkPermission() - but those permissions have to be checked at every entrypoint to code that allows restricted actions.
From time to time people discover ways to e.g. turn on GPS programmatically because a check like that is missing somewhere.

With regard to your second paragraph, "exceptions" are runtime faults. Permissions are not enforced at build time, only at run time.
Accessing hardware, low level operating system resources, and system files generally requires the app userid to be a member of an appropriate group which it may be assigned by the package manager as a result of having a corresponding android permission. (Familiar examples of that would be network sockets, and the sdcard write which zapl mentioned, but also system-only things like talking directly to the GSM modem or reading the raw touchscreen coordinates).
For the majority of android operations that are done by way of calling library functions which are stubs for interprocess communication to services running in a different process, the platform code running in the more privileged process on the receiving end of the ipc request checks with the package manager to find out if the calling application has the necessary android permission.
Many special permissions are only available to apps signed with the system signature - even if another app claims those in its manifest, they will not be applied by the package manager.

Scan the Application during the installation process in android

i just want an application that would scan the installing application and decide whether to deny the installation process or not basing upon the package name ?

Fortunately, this is not possible, for obvious security reasons. Malware authors would really like it if they could block other applications from being installed.

Do you want an application which self-checks for integrity?
Or an application which check ANY other new application?
On the former, I would suggest to put some piece of code on the main activity which checks this. But if you are trying to have some sort of 'anti-hacking' feature it would be quite pointless, as it would simply be needed to remove those lines.
On the latter, that would be more complicated and, also, how would you know the 'correct' package name?

Third party security applications such as Lookout, McAfee, Avast, etc. run with the same limited permissions and capabilities as any other Android application. That said, it's not possible for any Android application to "man-in-the-middle" an application installation process for security checks or any other purpose. As mentioned by others, this would have negative security implications, as it would allow any application to modify or deny the installation of other apps.
As a third party app, the best you can do is to monitor installed packages using a broadcast receiver that listens for android.intent.action.PACKAGE_ADDED intents, or use FileObserver to trigger a security review once the app is written to the file system. At this point if you detected an application you wanted to uninstall, you would still have to ask the user for their approval to uninstall the application.
FWIW, device manufacturers have the capability to make low-level modification to provide this capability, but I assume this is out of scope for your case.