I've developed a socket app (realtime) for Android. Everything was working fine until the Android 6 update with brings the "doze" mode. Is there a plugin that prevent from dozing? This renders my app useless since when the app goes in doze mode, the app cannot use the network connection anymore. I'm running a background mode plugin but this isn't enough, doze takes over.
Thank you.
edit: following Emanuel's comments, I have found this post about it but no valid answer.
How do I add my app to the whitelist so it doesn't stop by "doze" ? I cannot find any info anywhere... except this doc, but doesn't say how to add to the whitelist. Since my app doesn't rely on GCM, I should be good, if only I can find how to add my app!
use this cordova plugin to White listing an Android application programmatically from battery optimize settings
To install
cordova plugin add https://github.com/thomas550i/cordova-plugin-doze-Optimize
Javascript code of usage
cordova.plugins.DozeOptimize.IsIgnoringBatteryOptimizations(function (responce){
console.log("IsIgnoringBatteryOptimizations: "+responce);
if(responce=="false")
{
cordova.plugins.DozeOptimize.RequestOptimizations(function (responce){
console.log(responce);
}, function (error){
console.error("BatteryOptimizations Request Error"+error);
});
}
else
{
console.log("Application already Ignoring Battery Optimizations");
}
}, function (error){
console.error("IsIgnoringBatteryOptimizations Error"+error);
});
There is no plugin that prevent from dozing
But Users can manually configure the whitelist in Settings > Battery > Battery Optimization. Alternatively, the system provides ways for apps to ask users to whitelist them.
An app can fire the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent to take the user directly to the Battery Optimization, where they can add the app.
check this : https://developer.android.com/training/monitoring-device-state/doze-standby.html
Related
We have an app utilizing NFC and recently migrated from enableForegroundDispatch to enableReaderMode. Since then, we have been receiving bug reports where the user intermittently has trouble scanning tags.
I was troubleshooting remotely with a customer today who was unable to scan any tags (the app was working through yesterday). Sometimes they would receive an "NFC read error. Try again" message.
When we had them install the older version of our app which uses enableForegroundDispatch, NFC scans worked as intended. Scanning using the NFC Tools app was also working during this time, as was scanning with no app open. We tried rebooting the device and also toggling NFC on / off with no luck. It was just our app.
After much debugging, what appears to have resolved it was to fully delete our app from the device and then reinstall it. The device is a Google Pixel 2 running Android 11.
I have read countless threads about enableReaderMode and am also aware of this bug affecting kiosk apps in Android 11 (but our app isn't a kiosk). I also read about how there is a bug where Android might think our app is not in the foreground.
Is there any credence to the theory that deleting our app (vs. updating the same installed package with different builds) is what resolved this, and if so then what exactly is happening that is causing this?
Edit: I just found the threads about "NFC service dead" and am guessing this is what happened.
I have read the public code for NFC service, I cannot remember it having anything that would be affected differently by update vs uninstall/install other than possibly the Manifest(PackageManager?) permission to use NFC.
I have not looked in to details about how an app update updates the Manifest permissions, but guess an update might not update the permissions if it thinks they are not changed whereas remove/install would probably delete the whole entry and re-add it thus if there was corruption in the permission list a remove/install would likely fix it.
Also if the NFC Service is dead then other App's would not scan as well. I do seem to remember there is something in there to restart the NFC service if it had died.
I want to write a android native module which work as a background service and get current location and post to server and then integrate that module with react native.
if you just want it for the location then i suggest react-native-workers
it has access to native modules (network, geolocation, storage ...) you can aslo integrate it with react-native-queue
There are a couple of example projects / demo apps you might want to check out which implement both "Foreground Services" and "Background Services" in Android to help you get location updates while the app is closed or the screen is off. The background service example will only allow you to get updates as frequent as 1 minute, while the foreground service example will allow you to get updates as fast as 1 second (or maybe faster, I haven't tested that yet) while also displaying an "Ongoing Notification" to the user.
Background Service Example: https://github.com/comoser/rn-background-location
Foreground Service Example: https://github.com/andersryanc/ReactNative-LocationSample
There are a number of Android specific code adjustments you will need to make in either case. It's not ready yet, but in the near future I plan to update my repo's readme with a detailed set of instructions for implementing the necessary changes in your project.
I am writing a simple Phonegap application for Android. This program will send notification to notification bar and make the phone vibrate periodically.
I use navigator.notification.vibrate(time_period) to achieve the target. According to this article, both beep and vibration are not supported by android emulator. Hence, I was expecting that there could be entry indicating failure of it in the Catlog, but there is no such entry. The question is how to make sure that a vibration event has happened or failed (without deploying to a device).
AppHarbor looks like one of the ways to debug Phonegap application remotely. I wonder if there is other local ways to test Phonegap application as an HTML5 website in a Chrome browser (navigator.notification call is a standard call)? If yes, then it is probably possible to somehow parse the browser's console automatically to find out if the vibration event has happened.
Can you hide the vibrate() call behind an abstraction which you can replace depending on which platform you are using?
For example
var vibrateFunc = function(time_period) {
if (navigator.userAgent.toLowerCase().indexOf('chrome') > -1) {
console.log('vibrating for ' + time_period)
} else {
navigator.notification.vibrate(time_period)
}
}
and then have your app code call vibrateFunc() whenever it wants to vibrate.
I would like to know how to disable the logging that happens as a result of the Android O/S API and not my payment app itself.
http://code.google.com/p/seek-for-android/
I have no control over it as its dependent on the O/S itself and it writes to logcat file.
Any advise highly appreciated.
I would like to know how to disable the logging that happens as a result of the Android O/S API and not my payment app itself.
That would require modifications to the firmware itself. Other applications, including those that are part of the firmware, are welcome to log whatever they want to LogCat. Your "payment app" has no rights to affect what information other applications log. Hence, the only way to "disable the logging" would be to disable LogCat entirely, and no SDK application can do that.
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.