In the new Android M build, the Battery Optimization feature will stop the app on certain condition to save battery, but for the VOIPapps that need to stay alive all the time, this feature cause troubles for the developer.
Currently there is one way to bypass the optimization, which is set the app to ignore optimizations,but too many steps need to be done.
My question is, is there a way to jump to ignore optimization page of specific App, and how can I know whether my app is excluded from optimization?
WARNING: It seems Google doesn't allow apps on the Play Store to do this. See the comments below.
Based on the AndroidManifest.xml extracted from Settings.apk in the MPA44I build, it would seem you might be able to do what you want by something like the intent below.
From XML:
<intent
android:action="android.settings.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"
android:targetPackage="com.android.settings"
android:data="package:PUT_YOUR_PACKAGE_NAME_HERE" />
From code:
try {
Intent intent = new Intent(android.provider.Settings.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
intent.setData(Uri.parse("package:PUT_YOUR_PACKAGE_NAME_HERE"));
startActivity(intent);
} catch (ActivityNotFoundException e) {
e.printStackTrace();
}
Note that I have not had time to verify this in practice myself but the approach is the same as I use in one of my apps to launch app-specific settings menus. Still, I hope it helps.
Google Allow this based on few conditions
Check Section "Support For Other Use Cases"
here
Also check White List Conditions
There's currently no way to effectively opt out of optimizations, as this does not affect doze mode - even if your app is on the whitelist.
See here:
https://stackoverflow.com/a/31721398/4301846
and here:
https://code.google.com/p/android-developer-preview/issues/detail?id=2225
Related
Background
I just noticed some functions of NotificationManager that handle a class that's called AutomaticZenRule :
https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule(android.app.AutomaticZenRule)
and others...
The problem
Looking at the docs of AutomaticZenRule, it still doesn't tell much about what it is, and what can it be used for:
Rule instance information for zen mode.
What I tried
Searching the Internet, I can see just in a Commonsware blog post, that they wonder what it is:
It is unclear what AutomaticZenRule is ...
There is practically nothing more that I've found about it. Not "zen mode" and not "AutomaticZenRule".
The questions
What is "zen mode" ?
What is "AutomaticZenRule" , and what can I do with it? How is it related to notifications?
Is there anything special on Android N, that this API was added on this version?
Is there a sample for using it?
Zen Mode is just another name for Do Not Disturb (DND) mode. Android can activate DND mode based on rules. These rules can be provided either by the system, or by a third-party app.
In the following screenshot you can see two system-provided rules, together with a "Driving" rule provided by the third-party app "Pixel Ambient Services":
AutomaticZenRule is there to integrate your own rules into the Android system. To integrate your own rules, you have to follow these rough steps:
Make sure that you have sufficient permissions to access the DND policy (android.permission.ACCESS_NOTIFICATION_POLICY). See NotificationManager.isNotificationPolicyAccessGranted() for details.
Add an activity for your rule:
<activity android:name="MyRuleConfigurationActivity">
<meta-data android:name="android.service.zen.automatic.ruleType" android:value="My Rule" />
<intent-filter>
<action android:name="android.app.action.AUTOMATIC_ZEN_RULE"/>
</intent-filter>
</activity>
Android will show your activity whenever the user wants to create or edit a rule of the specified rule type. In the latter case, Android will supply the ID of the existing rule in NotificationManager#EXTRA_AUTOMATIC_RULE_ID. To propagate changes in your activity back to android, you need to construct an AutomaticZenRuleinstance and call NotificationManager.addAutomaticZenRule / updateAutomaticZenRule.
After that, you can tell Android that the conditions for your rule are currently satisfied / not satisfied by calling NotificationManager.setAutomaticZenRuleState.
From digging in into the other documents available, i was able to understand ZenMode to some extent(although it can be my own version and not the correct one).
What my understanding is as follows -
Zen Mode is the Do not Disturb mode which now in latest updates can be enabled automatically which depends on factors such as late time of the day, etc. AutomaticZenrule can be used by applications who want their notifications to not be masked or suppressed when in do not disturb mode.
For this your application should make request to policy access by sending the user to the activity that matches the system intent action ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS.
If user has granted access to notification policy for your app, then you will be able to set a priority notification even in do not disturb mode. AutomaticZenrule thus plays a vital role to state the system that the application's notifications not be suppressed.
Although, i dont have a running sample code for it, i guess it should be on similar lines like the enabling device admin code or requesting a permission use case.
Thanks to you i got to read something new :)
Im trying to develop an app which has a few security options, and for one of those options I need to able to know if the device is locked with any kind password(numbers,pattern,etc) so I started reading the android documentation and found two KeyguardManager methods, isDeivceLocked() and isDeviceSecured() however I don't really see much of a difference in the description, so what really is the difference between the two? thanks in advance
The official API states the difference, though it might be a bit confusing. The key difference is whether you want to know the general configuration of the device, or its current state.
So isDeviceLocked() returns true if the device is currently locked behind some kind of password or identification mechanism, which is required in order to unlock and use the device. It returns false in case that the device is currently open and in use, or that it just doesn't require any password/identification in order to open it. (reference and more details may be found here)
On the other hand, isDeviceSecure() returns true if the device has been configured to use any kind of password or identification mechanism - even if it's not currently required in order to use the device.
In case you wonder what scenario might cause isDeviceSecure to return true, while isDeviceLocked returns false: it might happen whenever the device in in use (after the lock password has already been entered). Another scenario might be when the device has Smart Unlock (or trusted devices) configured, so that currently it wouldn't ask for a password or any other kind of identification in order to open/unlock itself.
I wish to know is it possible to write an android app that when it runs at the background, it can track user activities?(Such as what other app did the user used, what phone number did user dial, the GPS location for user, etc) Cause I am not sure can a single android app react to other application, does anyone know the answer? Thanks
In the general case, no, you can't. And users would probably prefer it so.
Once this has been said, there are certain partial solutions. Sometimes the system is so helpful that it will publish Intents reflecting user actions: for example when the user uninstalls an app -- with the caveat that you don't get that intent on the app itself being uninstalled.
It used to be the case that before Jelly Bean (4.1) apps could read the log that other applications publish and try to extract info from there, but it was a cumbersome, error prone, ungrateful task. For example, the browser shows nothing when it navigates to a certain page. You may read the logs for a while with adb logcat to get a feeling of what was possible and what isn't. This action requires the relevant permission, which cannot be held by regular apps now.
Thanks to #WebnetMobile for the heads up about logs and to #CommonsWare for the link, see the comments below.
Yes you can.
You can look here for instance about phone info:
Track a phone call duration
or
http://www.anddev.org/video-tut_-_querying_and_displaying_the_calllog-t169.html
There is a way to let Android and users know you are using and accessing their data for them to determine if they will allow it.
I am unsure you can simply access any app, but in theory if you know how to read the saved files that might be possible.
For instance Runtime.getRuntime().exec("ls -l /proc"); will get you the "proc" root folder with lots of data you might need there. This might have been changed, I am not sure, and I also don't know what you need.
Perhaps to get running process try:
public static boolean getApplications(final Context context) {
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
List<RunningTaskInfo> tasks = am.getRunningTasks(1);
}
For this to work you should include this in your AndroidManifest.xml
<uses-permission android:name="android.permission.GET_TASKS" />
See more about it: http://developer.android.com/reference/android/app/ActivityManager.html#getRunningAppProcesses%28%29
You certainly could but I think reporting that data back to you, unbeknownst to the user, via the internet, would be considered spyware and almost certainly illegal in most jurisdictions.
Fortunately spying users at that level should not be possible. Certain features can be achieved with abusing bugs in android which sooner than later will be fixed. I see absolutely no reason for you to know what number I am calling and where I've been lately. It's basically none of your business.
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.
I want to develop an application that disables the Background Data (new feature in Android 1.5) and Auto Sync and then enables GPRS/EDGE connection and vice versa.
I figured out how to enable/disable GPRS/EDGE by changing the APN settings. (weird solution. However; Android developers couldn't think a user may want to disable GPRS/EDGE) But, I couldn't find a way to enable/disable Auto Sync and Background data.
I investigated the Android code and as I understood, the Sync operation is an intent. So, I wanted to reach with putExtra to the intent and trigger the enabling/disabling. But; I couldn't find the correct keyword. Or maybe I was totally wrong.
What is the right way to solve this?
In my HTC dreams, there is a checkbox to disable the auto sync. I can look for the menu arborescence if you wish so you can find what the callback function is in the Android source code. But I am pretty sure auto sync cannot be completely disabled. Unchecking auto sync will prevent sync from being performed on a timed basis, but it will occur everytime you run an app with sync capabilities if any network data connection is available.
Good luck anyway.
EDIT :
There are two ways to get the info you desire.
First, I think you can use the code in android-sources/packages/apps/Settings/src/com/android/settings/Utils.java to create an activity that will enlist all the keys of the intent then find the one you want.
The other way is to write a nice mail to the guy who made the Toggle Setting app (http://smartphoneandroid.com/2008/12/28/toggle-setting-perfect-app-for-android-phone.html) since he obviously found a solution to your problem. His email address is written in the app sheet on the android market. I won't write it here, but if you do not have access to real android phone, I can mail it to you on your mail address.
Background data is a secure setting, so cannot be changed by user applications. But bear in mind, it's just a setting - it's not enforced. Apps are meant to read it and respect it but I bet some don't.
To Disable the AutoSynch
ContentResolver.setMasterSyncAutomatically(false);
To Enable the AutoSynch
ContentResolver.setMasterSyncAutomatically(true);
Permission you require is
<uses-permission android:name="android.permission.WRITE_SYNC_SETTINGS" />
setMasterSyncAutomatically() on ContentResolver should do it. Check: general-sync-settings-auto-sync-checkbox-programtically