i want to do a task manager soft,i want to check all apps which used android.intent.action.BOOT_COMPLETED and i want to also disable Auto Startup when the mobile start run. i have no clue,if i need the root permission to finish it any advice may receive
To check which applications receive BOOT_COMPLETED intent action you can use android PackageManager and ResolveInfo class something like,
Intent intent = new Intent(android.intent.action.BOOT_COMPLETED);
List<ResolveInfo> listApp = packageManager.queryIntentActivities(intent, 0);
for (ResolveInfo res : listApp) {
Log.e("Camera Application Package Name and Activity Name",res.activityInfo.packageName + " " + res.activityInfo.name));
}
But I think its not possible to change other application's permission which they are used. So you can't prevent it to start at BOOT_COMPLETED time.If you want to this then for this you have to ROOT permission.
There is one of application on android market that allow you to do it, for example LBE Privacy Guard
UPDATE:
In android framework structure, in /data/system/packages.xml which contains all installed application's information include used permission, (I never try this also don't know whether its worked or not) If you can modify this file then may be you can achieve what you want..
Thanks..
Note you can not change the /data/system/packages.xml file above to remove the android.intent.action.BOOT_COMPLETED permission.
This is because the android framework, at start-up, parses every apk (i.e. app) manifest file and when it sees the android.intent.action.BOOT_COMPLETED permission, it calls the app at that time.
Therefore, modifying the file will have no effect. I've tried this - believe me. The only way I know of to remove the android.intent.action.BOOT_COMPLETED permission (aside from modifying the andorid framework, recompiling it, and loading it onto your phone) is to manually edit the apk files you want to remove the permission from.
Obviously not for the faint of heart!
If you can find out what the component is (e.g., by looking at the app's manifest), you can disable the component from an adb commandline or a root shell with: pm disable package.name/component.class.name
The Autostarts app does this. It has GPL (I think) source code that you can re-use for your app if your app is GPL, too.
Related
I know from https://developer.android.com/guide/topics/connectivity/telecom/selfManaged, that you can set the default dialer by having the necessary items in your manifest and permissions listed. One of those being the Dial intent.
What i'm trying to do is build a library that does all of these content provider calls and provide a nice reactive way of doing things to my application. While building the library I would like to add some integration tests around these device calls.
There's the GrantPermissionsRule that helps with setting permissions already defined in your manifest but how does one deal with becoming the default dialer or SMS application? I'd accept even an adb command that you could run using a Runtime execute command.
I also tried testing on an emulator and I noticed that you can give your app WRITE_SECURE_SETTINGS but not MANAGE_USERS which is the other necessary permission you need if you were to use reflection to access the https://android.googlesource.com/platform/frameworks/base/+/master/telecomm/java/android/telecom/DefaultDialerManager.java
Any help is much appreciated!
you can try adb command:
adb shell settings put secure dialer_default_application com.google.android.dialer
replacing com.google.android.dialer with your package.
For a survey I want to monitor user-compelled changes in the Android M application permission settings.
I decided to create a FileObserver watching /data/system/users/0/runtime-permissions.xml. This file holds all information but only has read/write access for the system -rw-------. chmod won't work because access privileges are restored on every change. So my monitoring app needs system permissions.
I followed this method to deploy my app directly to priv-app directory. Works like a charm, app is considered a system app, but still does not have permission to read the above-mentioned file. File.canRead() fails just as File.exists().
Is there maybe something I have to add in the AndroidManifest.xml to make it work, or is making use of the priv-app folder a complete wrong guess? Do I have to sign the application? For final deployment I wanted to add the application to a custom rom using some kind of kitchen.
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
I have a requirement in my app that after a specified number of unsuccessful login attempts:
A folder on the sdcard essential for the app be deleted and
The app be uninstalled from the device.
This is basically a self destruct sort of action.
Can you provide inputs on whether the aspect of uninstalling the app, while the app is running is feasible? I assume deletion of the folder must be easy. Do you foresee any issues with doing that too.
Thanks
A
There's no public API to allow you to seamlessly remove a package (including your own.) You can request a package be removed by firing an Intent with the action set to ACTION_UNINSTALL_PACKAGE, but the user will be notified of the action as it will take them to the default installer (ie Google Play Store) to perform the action.
Larry Schiefer is right, there is (fortunately) no public API to do this without user interaction. But if you have extended rights, for example if the device is rooted and your app has root access, you could use the command line:
Runtime.getRuntime().exec(new String[] {"su", "pm uninstall com.example.yourapplication"})
In the case you have special privileges because you are a system app, you can use hidden API's, which are very dangerous because they are undocumented and can change from one Android update to the next. However, if you are in control which version of the OS installed, you might get away with it.
In this case, you could call PackageManager.deletePackage through reflection.
pm = context.getPackageManager();
Class<?>[] types = new Class[] {String.class, IPackageDeleteObserver.class, int.class};
method = pm.getClass().getMethod("deletePackage", types);
method.invoke(pm, new Object[] {"com.example.com", null, 0})
This function should also delete all your package data, so it's a complete wipe. You need to ask for the DELETE_PACKAGES permission in your AndroidManifest.xml (which is only granted if you are a system app/system user):
<uses-permission android:name="android.permission.DELETE_PACKAGES"/>
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