Let's say the user open "Settings" application, is there a way to "intercept" this intent, from my app's service, in order to detect that "Settings" app is going to be openned?
For instance, in SOTI MobiControl app you can manage (from a web dashboard) the permissions of the user with the app installed (and enrolled to your server). If you don't allow one user to open Settings app, when he tries to open it, a toast appears saying "Unauthorized". How do they that?
Doing so is against Google Play Developer Program Policy, as it states in its System Interference section:
An app downloaded from Google Play (or its components or derivative
elements) must not make changes to the user’s device outside of the
app without the user’s knowledge and consent.
This includes behavior such as replacing or reordering the default
presentation of apps, widgets, or the settings on the device. If an
app makes such changes with the user’s knowledge and consent, it must
be clear to the user which app has made the change and the user must
be able to reverse the change easily, or by uninstalling the app
altogether.
Apps and their ads must not modify or add browser settings or
bookmarks, add homescreen shortcuts, or icons on the user’s device as
a service to third parties or for advertising purposes.
Apps and their ads must not display advertisements through system
level notifications on the user’s device, unless the notifications
derive from an integral feature provided by the installed app (e.g.,
an airline app that notifies users of special deals, or a game that
notifies users of in-game promotions).
Apps must not encourage, incentivize, or mislead users into removing
or disabling third-party apps except as part of a security service
provided by the app.
https://play.google.com/intl/ALL_us/about/developer-content-policy.html
Is there a way to "intercept" this intent, from my app's service, in
order to detect that "Settings" app is going to be opened?
As other mentioned before it's not possible to intercept a launch intent.
For instance, in SOTI MobiControl app you can manage (from a web
dashboard) the permissions of the user with the app installed (and
enrolled to your server). If you don't allow one user to open Settings
app, when he tries to open it, a toast appears saying "Unauthorized".
How do they that?
It's however possible to determine if an app is opened and "intercept" that call. By intercept I mean draw over the starting app's screen and present a login screen or a not authorized screen.
I haven't worked out a full sample that would work an any Android version but from my research with AppLocks, I'd say it works more or less like this:
On pre-Lollipop Android you'd use this to retrieve the running processes:
ActivityManager manager = (ActivityManager)getSystemService(ACTIVITY_SERVICE);
for (ActivityManager.RunningAppProcessInfo info : manager.getRunningAppProcesses()) {
Log.e("TAG", "Running process: " + info.processName);
if ("com.mycompany.mycoolapp".equals(info.processName)) {
// do stuff...
}
}
requires:
<uses-permission android:name="android.permission.GET_TASKS"/>
or alternatively:
for (ActivityManager.RunningTaskInfo recentTaskInfo : manager.getRunningTasks(100)) {
Log.e("TAG", "Recent tasks: " + recentTaskInfo.baseActivity.getPackageName());
}
On Lollipop and higher you'd use UsageStats to determine if an app is running:
UsageStatsManager usageStatsManager = (UsageStatsManager)getSystemService(USAGE_STATS_SERVICE);
Calendar cal = Calendar.getInstance();
cal.add(Calendar.YEAR, -1);
long start = cal.getTimeInMillis();
long end = System.currentTimeMillis();
List<UsageStats> queryUsageStats = usageStatsManager.queryUsageStats(UsageStatsManager.INTERVAL_DAILY, start, end);
for (UsageStats stats : queryUsageStats) {
Log.e("TAG", "Usage stats for: " + stats.getPackageName());
}
requires:
<uses-permission android:name="android.permission.PACKAGE_USAGE_STATS"/>
I would probably run both using the AlarmManager to perform that recurring task.
I'm fairly certain these are the two ways to get the list of running apps. If the permission for usage stats is denied to AppLock it's not working any more an Android 6.0 devices. On pre-M devices it however still works which is an indicator that the app has an alternative way to get the list of running apps (the first option described above).
Once it's determined an app has been started (it's running and hasn't been running the last time we checked), we can "take over" the screen. And that's how I'd do it: http://www.piwai.info/chatheads-basics/
Of course that's just the basic idea and I'm sure there are a couple of pitfalls when implementing a reliable solution but this should give you something to start with.
Let's say the user open "Settings" application, is there a way to "intercept" this intent, from my app's service, in order to detect that "Settings" app is going to be openned?
No, unless you are the one that is calling startActivity() to launch the application in the first place.
Related
Hi:
I'm curiously about how to show this dialog. When I press allow, the battery optimize is disabled for this app. Is it an new android api
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
String packageName = context.getPackageName();
PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
if (!pm.isIgnoringBatteryOptimizations(packageName)) {
Intent intent = new Intent();
intent.setAction(android.provider.Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
intent.setFlags(FLAG_ACTIVITY_NEW_TASK);
intent.setData(Uri.parse("package:" + packageName));
context.startActivity(intent);
}
}
Also, you need to add the following permission in manifest
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
This is part of the new App Standby feature introduced with API 23 (Marshmallow) alongside Doze Battery Optimization aimed to optimize power and resource usage while the app is in background (App Standby) or when the device has long been in sleep (Doze).
Following is the explanation from the Android Developer's site page:
Specifically, in the App Standby mode, the system determines that an app is idle when the user is not actively using it. The system makes this determination when the user does not touch the app for a certain period of time and none of the following conditions applies:
The user explicitly launches the app.
The app has a process currently in the foreground (either as an activity or foreground service, or in use by another activity or foreground service).
The app generates a notification that users see on the lock screen or in the notification tray.
The app is an active device admin app (for example, a device policy controller). Although they generally run in the background, device admin apps never enter App Standby because they must remain available to receive policy from a server at any time.
When the user plugs the device into a power supply, the system releases apps from the standby state, allowing them to freely access the network and to execute any pending jobs and syncs. If the device is idle for long periods of time, the system allows idle apps network access around once a day.
So, this means that starting from API 23 (Marshmallow), the device may actively put your app on standby, preventing network access (say for task like sync) and limiting (or disabling) background executions. Now, for most of the apps this behavior is fine or you could easily optimize for such behavior, but for some apps out there this may cause some unexpected behavior, especially for apps that have been poorly optimized or use non-standard sync strategies or some other means of background sync/execution.
So to circumvent that, the user can explicitly mark the app as non-optimized and the system will fallback and not put the app to standby, although this leads to a poorer user experience and you should not be doing this for regular apps that could be optimized.
I am working on android multi-user. So I have to convert my existing project in to multi user supporting project.
My app will be running in owner. If I switch to user, any related UI actions should be shown on owner or user,
I am using Context.startActivityAsUser(intent, UserHandle.Current);
so the activity will be launched on corresponding user or owner.
the same way to launching broadcast events.
In my app, I am using notification as part of service as below
startForeground (int id, Notification notification);
as the service is running is owner, the notification is showing on owner only even though I switched to user.
When end user switched to other profile, the notification should be shown on current profile.
as per my knowledge, there is no startForeground(...) as user (i mean as startForegroundAsUser()) so I have converted notification stuff to
NotificationManager.notifyAsUser(null, appID, notification, UserHandle.CURRENT);
....
When I switch from owner to user, my app is getting crashed and logs also not clear for find the issue. Logcat just says as
I/ActivityManager(421): Process com.example.test (pid 5833) has died
W/ActivityManager(421): Scheduling restart of crashed service com.example.test/com.example.test.testservice in 1000ms
.....
.....
.....
but the service is not started as top profile is CURRENT.
Let me know the other approach to achieve this.
The short answer is you cannot do this. Each app package is installed on the device with a separate data area and process for each human user. They are purposely kept isolated in memory and filesystem space via Linux UID/GID and permissions. In Android 5.0 this is further enforced using SE Linux for Android. So when you are switching (human) users, your apps are being started as separate instances for that person.
After achieving device ownership, I am trying to implement a method to instruct the device to lock any given app into kiosk mode (or screen pinning mode). Since I have device ownership, the user is not asked for the permission to do so.
From the developer website, brief description tells me that it is possible to do what I am trying:
http://developer.android.com/about/versions/android-5.0.html#ScreenPinning
Programmatically: To activate screen pinning programmatically, call
startLockTask() from your app. If the requesting app is not a device
owner, the user is prompted for confirmation. A device owner app can
call the setLockTaskPackages() method to enable apps to be pinnable
without the user confirmation step.
This indicates that as a device owner app, I can pin other apps without user confirmation... but I have no idea how to.
I have been able to put my own app into pinned mode.
Any help would be appreciated.
The setLockTaskPackages() is used the specify which applications (through their package names) will be able to programmatically be pinned without user confirmation.
The setLockTaskPackages() is called from your device owner app (most probably in your DeviceAdminReceiver's onEnabled() method).
So, in you owner device app, you'll have something like :
mDPM.setLockTaskPackages("com.foo.myapp");
and then, in your "com.foo.myapp" application, you will be autorized to call :
startLockTask();
Your application will immediately enter the Pinning mode, without any user confirmation.
If you don't first register your application with setLockTaskPackages, the application will be pinned but the user will have to confirm first.
Also notice that when an app is registered with setLockTaskPackages(), it has some different behaviours than the manual pin:
the user cannot unpin manually the application by long-pressing Back + Recent Apps. You'll have to programmatically unpin your app with stopLockTask();
The "Home" and "Recent Apps" buttons are invisible (not displayed)
When the app is unpinned (via stopLockTask()), the user will directly go back to Home : no Screen lock is displayed, even if a Keyguard is set (Pattern, code, or whatever Keyguard screen).
I've not enough reputation for a comment, just would point out that for devices with physical buttons (like the Samsung Galaxy Tab A mentioned by #chairman) one way for manage the forced unpinning of your application is to implement in your DeviceAdminReceiver class the following:
#Override public void onLockTaskModeExiting(Context context, Intent
intent)
So if your user want to for the unpin you can always re-pinning your app ;)
Here's a code snippet that should get you going:
DevicePolicyManager myDevicePolicyManager = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
mDeviceAdminSample = new ComponentName(this, DeviceAdminSample.class);
if (myDevicePolicyManager.isDeviceOwnerApp(this.getPackageName())) {
// Device owner
String[] packages = {this.getPackageName()};
myDevicePolicyManager.setLockTaskPackages(mDeviceAdminSample, packages);
} else {
// Not a device owner - prompt user or show error
}
if (myDevicePolicyManager.isLockTaskPermitted(this.getPackageName())) {
// Lock allowed
startLockTask();
} else {
// Lock not allowed - show error or something useful here
}
I am writing an Andoid app so that when battery life gets below a certain level, a dialog with options of how to save the battery appears. One of those options is to close all background apps/services (processes) using ActivityManager.killBackgroundProcesses(). The code is shown here:
public void TaskKiller( View view){
List<ApplicationInfo> packages;
PackageManager pm;
pm = getPackageManager();
packages = pm.getInstalledApplications(0);
ActivityManager mActivityManager = (ActivityManager)this.getSystemService(Context.ACTIVITY_SERVICE);
for (ApplicationInfo packageInfo : packages) {
mActivityManager.killBackgroundProcesses(packageInfo.packageName);
}
}
However, when I click the button that calls TaskKiller() and closes the background processes, some of the apps (Email, Google Maps) instantly begin he process of restarting. How can I alter my code so these apps stay closed until they are reopened? Also, is this approach sensible in regard to saving power or am I attacking this the wrong way?
I don't think that's the right way of handeling the problem.
These apps have broadcast receivers, which mean they'll restart the service whenever something happens (i.e. AC plugged in/WiFi turned on), and I don't think there's a way to stop that without root, and actually disabling the broadcast receiver.
You could make something that kills it every 5 minutes, but that wouldn't be very battery-friendly.
I don't think it's a good idea to force close the Maps app everytime, it's a bug in Android i think..
One of the answers is as following:
"
Actually, Maps always runs when you have "Backround Data" checkmarked in your General Sync Settings under Account Settings in your phone's Gmail app. Syncing backround data is necessary, unfortunately, in order for your phone service provider to provide calling and texting (although internet access will still work without this item checkmarked). Unchecking this box will remove Maps from Running applications (& any other app that needs it), improving battery time and speeding up your phone. But, if you want to make calls, text or use apps that require Backround sync, you have to have this ckeckmarked. If all you want to do is browse the net...uncheckmark it. There are currently no other legitimate solutions to the issue. Hope this is helpful...
"
See this issue (https://code.google.com/p/android/issues/detail?id=10251)
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.