Develop Reference

Security threat by a BroadcastReceiver with GooglePlay's permissions

Does the following situation create a security threat?
Image a situation.
You have a device without GooglePlay services installed.
You create a broadcast receiver with android:permission="com.google.android.c2dm.permission.SEND" permission (this permission is held by GooglePlay services) and install this app on the device.
The app does not check if GooglePlay services are available on the device.
Is it possible for a malicious software to exploit this developer mistake?

It's not very likely that this would cause a problem. There's minimal issue with this because:
This permission is defined by Google for GCM (which has been replaced by FCM.) It is used to ensure that only senders who hold this permission can send that Intent to the registered receivers. It's a small amount of security in the grand scheme of things, though.
Even if a different app / service defined this same permission to fake it on a device where GMS is not present, the normal payload of the Intent is likely going to have some type of extra data in it so Google's receiver (what is specified in your manifest) can verify its content before doing anything with it.
Starting with Android 4.4.3, checks were added to the system so that system bundled apps/services (e.g. GMS) permission definitions take precedence over 3rd party apps. This prevents 3rd party apps from re-defining permissions in an attempt to back-door a system app permission. Not exactly the same situation you describe, but still important.

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.

Whats are the ten most deadly permissions?

I would like to know what would be the top ten most deadly permissions that can be requested by an android. I know it might be a matter of opinion, but supposing that I had the 10 permission listed in by an application, I would definitely know my application did not generate a whole lot of confidence among users. What would be the permissions I would most likely like to avoid asking the user for.
I am aware of permissions like BRICK and SHUTDOWN but since they don't apply to third party devs I would like to know only of permission which can be requested by a third party developer.
PS: need not necessarily be 10. Any number of permissions you believe might lead to the user being weary of application would be nice.

CALL_PRIVILEGED - call numbers without going through the dialer
SET_ALWAYS_FINISH - controls whether or not applications become finished when put in background. Could lead to some nasty trackers or something.
READ_CONTACTS - could lead to some data stealing for ppl to add to their spammer lists.

Here are some I found that could potentially be very dangerous (not including the ones above :)
GET_ACCOUNTS - Allows access to the list of accounts in the Accounts Service
MOUNT_FORMAT_FILESYSTEMS - Allows formatting file systems for removable storage.
PROCESS_OUTGOING_CALLS - Allows an application to monitor, modify, or abort outgoing calls.
READ_SMS - Allows an application to read SMS messages.
SEND_SMS - Allows an application to send SMS messages.
READ_EXTERNAL_STORAGE - Allows an application to read from external storage
WRITE_EXTERNAL_STORAGE - Allows an application to write to external storage
And of course the best way to transmit some of this data
INTERNET - Allows applications to open network sockets.

I think it depends on what the app is meant to be doing.
Some days ago, for example, I was looking for a task killer app, and I ended not installing any because all the "Task Killers" I saw on the market requested full internet access.
Why would they need internet access in order to kill a task?
If they wanted internet access in order to display ads then they should say so, but otherwise I take the paranoid approach and I assume it is spyware.
Other than that, I am very protective of my SIM card and contacts.

Any app which uses ACCESS_INTERNET and READ_CONTACTS could be stealing your contacts. However, there are thousands of apps in the market that have these permissions and probably aren't...

Access the list of accounts in the Accounts Service
Act as an AccountAuthenticator for the AccountManager
Access information about networks
Request authtokens from the AccountManager
I routinely check permissions before download. If the application has no business doing these, then I would not even download it . Even if it does, I would think twice whether I really, really need the app to reside on my device. And BTW - the above are part of 34 permissions coded in Skype!
If we do not know who and where the developer is, we would tend not to download software on our PC's. Yet, so many don't use this logic for their Android devices.

BRICK - Disable a device

HowTo simulate Trackball/Cursor movement on android device?

I have purchased an Samsung Galaxy I9000 Phone, knowing that it does not have either a trackball nor a touchpad/cursorkeys. I thought: simply write an application that reads gestures and sends/generates the appropriate cursor events. Checking the SDK documantation and found that this is possible after granting my application the permission 'INJECT_EVENTS': "Allows an application to inject user events (keys, touch, trackball) into the event stream and deliver them to ANY window. Without this permission, you can only deliver events to windows in your own process.".
This clearly states that this permission is available at application level, not only at system/firmware level.
After several hours of experimentation I did not find any way to get my program to inject cursor events to any other program than my own. How can this be achieved without having the permission 'INJECT_EVENTS'?

As #adamp points out in the comments, there isn't a way to do this without the INJECT_EVENTS permission as that would be a huge security bug. Furthermore, this question and this bug seem to indicate that INJECT_EVENTS is a system-level permission and not available to non-system apps.