I'm developping two apps (on Android 4.2.2), app A that contains a "private" area and app B that can open the private area with an Intent.
I have used a custom Permission with protectionLevel="signature" to be sure the broadcast will be receive only if A and B are built with the same keystore, and it works well.
After this, I have made some tests, and finally find a way to "bypass" the Permission by using:
su -c am broadcast ... from an app that did not define the custom permission
So it means that if someone install the application A on a rooted device, he could send a broadcast message to my app and access the "private" area...
From my point of view, I'm not sure if it's a security breach or the expected behaviour.
I have found no documentation about this...
Do I really need to add a password in extras or something like that to be sure this access is protected?
Thanks
Related
I'm looking to expand my app to handle Guest Mode, introduced in Android L. I found that if I create a service with android:singleUser in AndroidManifest, with permission INTERACT_ACROSS_USERS, and I'm a system app by installing it in /system/priv-app, then my service is running even as I switch user. But my app needs to interact with the user, by being able to launch an activity, show a toast or notification. All of those things seems to not be possible. Is there a particular flag I need to set when I call startActivity so that it will launch a new activity from my service?
I found a way to do it. Basically have a singleton Service, which is a service with the android:singleUser="true" and with INTERACT_ACROSS_USERS and have the APK installed in /system/priv-app. Then have it broadcastAsUser to all users. You'll need to use reflection to access methods in UserManager. Then have a receiver instance which will receive the broadcast in the guest user's space, and then have the receiver startActivity.
There are several internal apis (comments as #hide) like Context.startActivityAsUser, NotificationManager.notifyAsUser to support it, but it needs build from source also with platform signature.
I have a SMS Blocking Android App. It worked fine until Google introduced SMS feature in Hangouts and so did Samsung in its ChatOn messenger. Both of them have the highest priority for SMS receiver ie 2147483647. I verified this from their manifest.
So is there anyway to decrease their SMS receiver priority using what so ever method including root?
I plan to implement a "click to fix" option after a user opens the app.
The only way I could think of doing this was to edit the manifest file of these applications.But again I am not sure how android processes the Broadcast receiver. Does it use its own internal memory to know which app will process the sms received broadcast, or does it read the manifest file of all the installed applications every time?
If there is a separate memory how can I access it(using root, if required) and if manifest file is read every time, is it possible to edit that file even with root, as I read there are signature related issues.
P.S In root programming i have just experimented with calling standard sudo commands inside an app. Also my main focus is on pre Kit Kat devices.
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.
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 would like to require that a user type a password before being allowed to uninstall/remove my application. How can I implement this functionality?
You could do this by:
The first time your app is installed, install a separate application/package ("watcher").
The only classes "watcher" contains is a BroadcastReceiver that listens for ACTION_PACKAGE_REMOVED
Add a BroadcastReceiver to your application that also listens for ACTION_PACKAGE_REMOVED
When a intent is broadcast to one of your receivers, check if the other component is still installed. If is isn't (the user just uninstalled it), prompt for the password - if it's wrong, reinstall the other component. If it's right, uninstall yourself.
You can exec logcat and get the start activity intent information.
You will find that before the uninstall activity is displayed, there is
a text msg such as:
Starting activity: Intent { act=android.intent.action.DELETE dat=package:com.comodo.pimsecure cmp=com.android.packageinstaller/.UninstallerActivity }
then you can pop a activity ask for password now.
It is possible. you can do it with DeviceAdminReceiver api. (i don't no how)
This is a hard problem. I can think of at least one non-evil use-case for it.
e.g. Stolen Phone Recovery app - you wish to deter ne'er-do-wells from uninstalling the app.
In this case, I can think of two sensible assumptions which would stop me implementing what you're looking for:
the thief is unaware of your app, so will not try to uninstall it.
the thief is aware of your app, and switch it off until he can get it to an iron box* to re-install the OS.
* For the uninitiated: an iron box will prevent the device sending or receiving electromagnetic signals.
Of course, this answer amounts to You Ain't Going To Need It, though I suspect you have already thought this through.
Protect installing/uninstalling apps by password makes Android more secure from malware/viruses. Your Android become as secure as iPhone.
How it works:
Automatic apps installing is prompted to user. You can search the app name. If not secure, Block it.
Root access is prompted to user. Too many ads is an indicator that access is dangerous.