I have designed 2 applications,
1) Which is a service and is running in the background.
2) Which runs in the foreground, which just has an EditText. now, i want to insert some values into EditText using the service. In logs i found, the error not allowed to start intent without permissions .INJECT_EVENTS
I have put the permissions in the manifest file of both the apps, it's still giving me a problem.
That is because ordinary Android SDK applications cannot hold the INJECT_EVENTS permission. That can only be held by applications signed by the same signing key as was used to sign the firmware.
Moreover, this is a really strange way to have two applications communicate. Android has a wide range of IPC options -- please use one. Or, do not make them be two separate applications.
Related
I am trying to write a simple android app that switches off my phone screen. When I am runnning this app I get Security Exception: Permission denial app requires android.permission.DEVICE_POWER. I know that this is a protected permission but my phone is rooted. What do I specify that I can use this permission? I have already tried declaring DEVICE_ADMIN permssion along with the DEVICE_POWER permission but it still doesn't work.
Rooting potentially lets you circumvent or modify the android security model, but it doesn't necessarily mean you get special privileges for an android API which enforces it. You cannot ordinarily run an application itself as root, while code in a helper executable which you could start as root will have substantial difficulty interacting with the Android APIs.
What you are trying to do may really not be a very good idea. But if you really want to do it, you would need to either install your own build of Android so that you have a (self generated) key matching that which you used to sign the platform, which you can then use to sign your application, or else try to install your application on the system partition.
If all you want to do is turn the screen off, then why don't you use the PowerManager? According to the documentation, the goToSleep() function will force the device to go to sleep.
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.
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.
I have been trying to figure this out on the web with no information whatsoever as to what this actually does. The Google Manifest information says:
Allows an application to set the maximum number of (not needed) application processes that can be running.
I am thinking this is not a third party app permission but I need to be sure, its for our embedded device.
My guess is that this limits the number of processes that one application can have open when calling android:process=".RemoteActivity" in the manifest.
Anyone? Thank you.
It's a development/debug intended permisson. And just do what it says. Remember that when you run an app, android creates a process for all it's activities. This is, if you start opening the different activities of your application, you use the same process. However, Android let's you choose if an activity uses the main process or another new one. That's why this permission exists.
Sources:
http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html
http://developer.android.com/reference/android/Manifest.permission.html#SET_PROCESS_LIMIT
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