How to make shut down in Android programmatically, I searched for the question and I found many answer the strongest answer said your phone must be ROOT, now my phone is root and my code working fine
but when I execute this code below I get an alert like this image below.
Code:
try {
Process proc = Runtime.getRuntime()
.exec(new String[]{ "su", "-c", "reboot" });
proc.waitFor();
} catch (Exception ex) {
ex.printStackTrace();
}
My result:
Now how to eliminate this alert I want to shut down directly when I press my shut down program button, without getting this alert.
Even if your phone is rooted, when apps that require root are accessing these system areas it will prompt for permission from the user atleast once(1st time of using the app). Either you can allow each time which will allow root permissions for your app for specified time limit(usually 15 mins) or you can select the "Remember my choice" and allow permanent access to your app this way.
In case you allowed once with the "Remember my choice" then you will have to manually change this permission from your super user app.
NOTE: Once if your device is rooted, you will get an app named "SuperSU" or "Superuser" in your device which will display all the apps that requires ROOT permission and the default access level of these apps.
Hope this helps:)
Related
I am developing a flutter alarm application and I ran into a problem. Probably it is easy to solve, but as I do not know how I thought you might know. I attached a file showing the other permissions feed of the alarm application alarmy which I found in the playstore. In the file, you can see that the "Show on Lock screen" and the "Display pop-up windows while running in the background" permission are both accepted from the start. On the other hand in case of the alarm application "Ultra Alarm" I am developing the two permission are denied from the start and I do not know how to change that. Maybe you can help me. It is a mi device.
I'm not sure if it's disabled by the system or if you haven't asked for the permissions, in the second case I recommend you to use permission handler, on the other hand, if the system is blocking the app to grant the permission it's becasuse you haven't made the setup on your Info.plist
I recommend you to check this post
I have an app that requires root access. I'm using the following code to request the permission:
Process p = Runtime.getRuntime().exec("su");
What this does is: when the user has granted the root access to the app, it displays the root sign (#) in the statusbar ( which is normal ). The symbol remains in the statusbar even after the app goes to the background or even after that activity is finished. I want the symbol to appear when the permission is granted, and releasing the granted root access after performing the operation, so it removes the symbol from the statusbar.
HideItPro does it so I know it's possible, but I couldn't find a way pf doing it. Can anyone help me how to do this ?
PS: I'm using RootTools sdk for root operations.
Android's permission system is different than traditional Linux. On normal, commercial devices there is no access to "root" and there is no su command. You have to have a rooted ROM for that functionality.
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"/>
This question already has answers here:
Is it possible to detect Android app uninstall?
(8 answers)
Perform a task on uninstall in android [duplicate]
(4 answers)
Closed 7 years ago.
I though it was not possible but I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called.
I would like to replicate this behavior in my App.
I tried with an Activity listening to "android.intent.action.DELETE" Intent, as suggested here:
How to know my app is uninstalled from the device...?
But as I'm about to uninstall my app, the chooser pops up asking to pick my application or the package uninstaller. How can I avoid this?
Is there a different way to intercept your application UNINSTALL event? (before answering that it is not possible, please try to uninstall NQ Mobile Security and see what happens. On my Android 2.3.4 it shows a nice screen saying that is not safe to go without a security app).
I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called
They must be exploiting some security flaw in Android. I will research it and see if I can get it fixed. Apps are not supposed to get control at uninstall time.
Thanks for pointing this out!
Is there a different way to intercept your application UNINSTALL event?
I sure hope not.
Opera Max is an app that does something similar - after being uninstalled opens a webpage.
How do they do this?
By using libevent, from native code, they watch /data/data/com.opera.max directory to be removed and then post good old action.VIEW broadcast when it happens.
Install their app, run it, and on rooted device from adb shell remove /data/data/com.opera.max directory
UPDATE: I created a sample app that shows how it works. BTW it doesn't work with recent (KitKat+ I think) Android versions: https://github.com/pelotasplus/ActionAfterUninstall
I'm pretty sure that they are monitoring the LogCat to intercept when the Activity Manager calls the PackageUninstaller. I think they kill the task and start their own Activity.
It's pretty clever but it's definitely exploiting a security hole in Android.
They are likely asking for a very critical permission that the user is granting them unknowingly. Look at the "Permissions" tab for this app (as of 6/15/2012): https://play.google.com/store/apps/details?id=com.nqmobile.antivirus20&hl=en.
The list of permissions this app gets is downright chilling. Among other things:
SYSTEM TOOLS RETRIEVE RUNNING APPS Allows the app to retrieve
information about currently and recently running tasks. Malicious apps
may discover private information about other apps.
CHANGE/INTERCEPT NETWORK SETTINGS AND TRAFFIC Allows the app to change network settings
and to intercept and inspect all network traffic, for example to
change the proxy and port of any APN. Malicious apps may monitor,
redirect, or modify network packets without your knowledge.
PREVENT TABLET FROM SLEEPING PREVENT PHONE FROM SLEEPING Allows the app to
prevent the tablet from going to sleep. Allows the app to prevent the
phone from going to sleep.
CHANGE YOUR UI SETTINGS Allows the app to
change the current configuration, such as the locale or overall font
size.
MODIFY GLOBAL SYSTEM SETTINGS Allows the app to modify the
system's settings data. Malicious apps may corrupt your system's
configuration.
DISPLAY SYSTEM-LEVEL ALERTS Allows the app to show
system alert windows. Malicious apps may take over the entire screen.
MOUNT AND UNMOUNT FILESYSTEMS Allows the app to mount and unmount
filesystems for removable storage.
CHANGE NETWORK CONNECTIVITY Allows
the app to change the state of network connectivity.
CHANGE WI-FI STATE Allows the app to connect to and disconnect from Wi-Fi access
points, and to make changes to configured Wi-Fi networks.
-- Update --
I also found that the Android Package Manager pretty much just deletes a package if it is asked to do so. The only check it performs prior to doing so is whether the package being deleted is currently registered as having an active device admin:
try {
if (dpm != null && dpm.packageHasActiveAdmins(packageName)) {
Slog.w(TAG, "Not removing package " + packageName + ": has active device admin");
return PackageManager.DELETE_FAILED_DEVICE_POLICY_MANAGER;
}
} catch (RemoteException e) {
}
See line 6900 in PackageManagerService in the AOSP source here.
For this, the application must be explicitly registered as a device admin by the user. See notes on device administration here: http://developer.android.com/training/enterprise/device-management-policy.html.
As per https://stackoverflow.com/a/26829978/1317564, here is some example code that does it: https://github.com/zzljob/android-uninstall-feedback/blob/master/library/jni/feedback-uninstall.c. This won't actually stop the uninstall from taking place, but does provide a way to catch it and take some action. I'm honestly surprised that this works in Android and the team may have plugged the gap in recent releases.
When you want to change the mobile system date or time in your application, how do you go about doing it?
You cannot on a normal off the shelf handset, because it's not possible to gain the SET_TIME permission. This permission has the protectionLevel of signatureOrSystem, so there's no way for a market app to change global system time (but perhaps with black vodoo magic I do not know yet).
You cannot use other approaches because this is prevented on a Linux level, (see the long answer below) - this is why all trials using terminals and SysExecs gonna fail.
If you CAN gain the permission either because you rooted your phone or built and signed your own platform image, read on.
Short Answer
It's possible and has been done. You need android.permission.SET_TIME. Afterward use the AlarmManager via Context.getSystemService(Context.ALARM_SERVICE) and its method setTime().
Snippet for setting the time to 2010/1/1 12:00:00 from an Activity or Service:
Calendar c = Calendar.getInstance();
c.set(2010, 1, 1, 12, 00, 00);
AlarmManager am = (AlarmManager) this.getSystemService(Context.ALARM_SERVICE);
am.setTime(c.getTimeInMillis());
If you which to change the timezone, the approach should be very similar (see android.permission.SET_TIME_ZONE and setTimeZone)
Long Answer
As it has been pointed out in several threads, only the system user can change the system time. This is only half of the story. SystemClock.setCurrentTimeMillis() directly writes to /dev/alarm which is a device file owned by system lacking world writeable rights. So in other words only processes running as system may use the SystemClock approach. For this way android permissions do not matter, there's no entity involved which checks proper permissions.
This is the way the internal preinstalled Settings App works. It just runs under the system user account.
For all the other kids in town there's the alarm manager. It's a system service running in the system_server process under the - guess what - system user account. It exposes the mentioned setTime method but enforces the SET_TIME permission and in in turn just calls SystemClock.setCurrentTimeMillis internally (which succeeds because of the user the alarm manager is running as).
Cheers
According to this thread, user apps cannot set the time, regardless of the permissions we give it. Instead, the best approach is to make the user set the time manually. We will use:
startActivity(new Intent(android.provider.Settings.ACTION_DATE_SETTINGS));
Unfortunately, there is no way to link them directly to the time setting (which would save them one more click). By making use of ellapsedRealtime, we can ensure that the user sets the time correctly.
A solution for rooted devices could be execute the commands
su
date -s YYYYMMDD.HHMMSS
You can do this by code with the following method:
private void changeSystemTime(String year,String month,String day,String hour,String minute,String second){
try {
Process process = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(process.getOutputStream());
String command = "date -s "+year+month+day+"."+hour+minute+second+"\n";
Log.e("command",command);
os.writeBytes(command);
os.flush();
os.writeBytes("exit\n");
os.flush();
process.waitFor();
} catch (InterruptedException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
Just call the previous method like this:
changeSystemTime("2015","04","06","13","09","30");
I didn't see this one on the list anywhere but it works for me. My device is rooted and I have superuser installed, but if superuser works on non-rooted devices, this might work. I used an AsyncTask and called the following:
protected String doInBackground(String... params){
Runtime.getRuntime().exec("su && date -s " + params[0]);}
In our application case, the dirty workaround was:
When the user is connected to Internet, we get the Internet Time (NTP server) and compare the difference (-) of the internal device time (registederOffsetFromInternetTime). We save it on the config record file of the user.
We use the time of the devide + registederOffsetFromInternetTime to consider the correct updated time for OUR application.
All GETHOUR processes check the difference between the actual time with the time of the last comparission (with the Internet time). If the time over 10 minutes, do a new comparission to update registederOffsetFromInternetTime and mantain accuracy.
If the user uses the App without Internet, we can only use the registederOffsetFromInternetTime stored as reference, and use it. Just if the user changes the hour in local device when offline and use the app, the app will consider incorrect times. But when the user comes back to internet access we warn he about the clock changed , asking to resynchronize all or desconsider updates did offline with the incorrect hour.
thanks penquin. In quickshortcutmaker I catch name of date/time seting activity exactly. so to start system time setting:
Intent intent=new Intent();
intent.setComponent(new ComponentName("com.android.settings",
"com.android.settings.DateTimeSettingsSetupWizard"));
startActivity(intent);
`