The Context
There's a certain app that competes with my app for a hardware resource that should be mutex-locked, but isn't. The hardware resource has no API in the public Android SDK, and the competing app expects to be the only app to ever need it. The hardware resource's governing firmware also expects it to only ever be acquired by one app at a time.
The Problem
Collisions over the hardware resource are not handled well in the firmware, and my test device will often need a reboot if the user launches the competing app while my app is running (I'm able to check for the competing app's service with ActivityManager.getRunningServices() and stop my app from trying to acquire the hardware resources if the user starts my app while the competing app is running).
I don't have access to the competing app's source code, or the system image source code, so my app has to be responsible for handling the competing app's bad behavior and/or the firmware's poor handling of competition for this hardware resource.
The Question
Is there a way for a normal (i.e. non-system) app running on Android Marshmallow to receive a callback when an app Activity or Service with a known component name is launched?
Is there a way for a normal (i.e. non-system) app running on Android Marshmallow to receive a callback when an app Activity or Service with a known component name is launched?
No. In fact, Android 5.0+ takes pains to hide the real-time knowledge of other running apps from you, for privacy and security reasons.
Related
I can understand the security reasons behind not allowing a background service to dispatch touch events to the app (any app. that does not belong the context of the service) that is running in the foreground. But there are some apps available in the playstore that can be used to access a remote device. How are those apps generating touch events?
An example of such app. is Optia
https://play.google.com/store/apps/details?id=jp.co.optim.optiasmsng&hl=en
There's one hint in the system requirements:
It must be equipped with original Samsung firmware
I would guess that it has been built withing the Android build tree (to enable it to use methods marked with #hide too) and given a user ID that has system permissions (which regular apps doesn't have).
I'm looking for technical input on Android User Profiles (both full & restricted). More specifically I would like to understand:
Whether it is possible to create an app which runs across all profiles, i.e. is not stopped, paused, restarted when switching user profile. My focus is NOT limited to activities, but I'm also interested in knowing whether a system-app/service could be created that does this and if so how.
What life-cycle is maintained for services of the non-active users. I get the impression that (at least some) services of APKs of a user get started the moment it gets activated in the lock screen (even without unlocking) and then are allowed to keep on running. But what will happen in low-memory conditions? Will a service of a non-active user also receive broadcast intents? Can such a service interact with the user and if so how?
In general: can someone point me to any technical information on the Android profiles features? There's a lot of articles on how it "looks" to the user, but I could find very little (apart from info on the pm and am command-line tools' options) on how it really works technically.
Thanks in advance!
Whether it is possible to create an app which runs across all profiles, i.e. is not stopped, paused, restarted when switching user profile. My focus is NOT limited to activities, but I'm also interested in knowing whether a system-app/service could be created that does this and if so how.
Default Android behaviors
By default, an Android application runs in a specific Android user workspace, it does not run for all Android users.
It means that when the user starts an application, it is started for the current Android user only.
When the application is launched from another Android user, Android will recreate a new instance of your application. As Android users can run in the background it means that you can have several instances of the same aplication running in parallel.
All the Android components of you application (ie. Services, Activities, BroadcastReceivers and ContentProviders) will be re-instantiated.
Most of the time it's the wanted behavior, but it can be a problem for some applications that do system-level handlings that have to be done once for the whole system, without
taking into account Android users (ex: a JobService doing some handling on Bluetooth events).
Define a singleton component/application
For each component of your app which is not an Activity, you have the possibility to specify that you want it to run as a singleton (ie. only one instance will be created for all Android users.).
To do so, the property android:singleUser=”true” must be added to the attributes of the component in the AndroidManifest.xml of the application.
<!-- Declare a singleUser service in the AndroidManifest.xml -->
<service
android:name=".MySingleUserService"
android:singleUser="true" />
Any singleUser component will always run under the system Android user (ie. the user 0) which can't be stopped by Android, even if you're application is currently running for another Android user.
To be able to use the property android:singleUser=”true”:
your app has to be a system application (either in system/app/ or system/priv-app/).
you app has to be signed by the platform certificate (by specifying LOCAL_CERTIFICATE := platform in its Android.mk).
your app must declare the use of the following permission in its AndroidManifest.xml.
<!-- Permission needed to use android:singleUser. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS"/>
Additional remarks
If your app only contains singleUser components, the entire app will become singleUser (ie. only one instance of your app will run for the entire system).
android:singleUser=”true” forces android:exported=”false” for your component (except if your app is privleged).
If a component of your application wants to communicate with a singleUser component of the same app via Intents, the default Android APIs can't be used because Intents do not cross Android users.
In that case, you have to use the multi-user Intent exchanges dedicated APIs which are suffixed by AsUser (ex: sendBroadcastAsUser(), startServiceAsUser(), etc.) and which allow to specify the destination Android user (UserHandle.SYSTEM in that case). Note that one of the following permissions must be used:
<!-- Permission needed to send intents to components of the SAME app running in another Android user. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS"/>
<!-- Permission needed to send intents to components of ANOTHER app running in another Android user. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS_FULL"/>
What life-cycle is maintained for services of the non-active users. I get the impression that (at least some) services of APKs of a user get started the moment it gets activated in the lock screen (even without unlocking) and then are allowed to keep on running. But what will happen in low-memory conditions? Will a service of a non-active user also receive broadcast intents? Can such a service interact with the user and if so how?
As I've mentionned above, an Android user can continue to run in the background even if they are not the active one (at least until Android 10). If resources are low, Android can stop any Android user which is not the system user (ie. stop all their running applications). So a Service can continue to run on an Android user which is currently running in the background until the user is stopped.
As I've also mentioned above, Intents do not cross Android users. So if you have a BroadcastReceiver registered in the user 10 and that an Intent is sent from the user 11, it won't be received by your BroadcastReceiver. The only exception is if you use the AsUser Intent exchanges APIs to send it.
Also note that an Intent with the action BOOT_COMPLETED is sent whenever a new Android user is started. It is only sent to the components of the starting Android user.
Sources
Unfortunately, there is few Android online documentation about multi-user systems. Here are the only articles about it (if youd don't find answers there, I suggest you to directly look into the AOSP source code):
Building Multiuser-Aware Apps
Supporting Multiple Users
Manage multiple users
I want to disable/unregister intents registered by other apps so that they would not get broadcast messages sent by the system?
Something like this:
Gemini app
(3rd screenshot)
Is there any similar app with the open source code?
Also, it is possible to remove permissions registered by another app?
I want to disable/unregister intents registered by other apps so that they would not get broadcast messages sent by the system?
Fortunately, that is not possible, except on rooted devices.
Something like this: Gemini app (3rd screenshot)
As the app notes, this requires root.
Also, it is possible to remove permissions registered by another app?
As JonTraex notes in his linked-to answer, this is not possible even with root.
I answered a similar question here:
https://stackoverflow.com/a/9106832/529691
If you had bothered to look at their permissions you could see how they are doing it.
SYSTEM TOOLS
KILL BACKGROUND PROCESSES Allows an application to kill background
processes of other applications, even if memory isn't low.
KILL BACKGROUND PROCESSES Allows an application to kill background
processes of other applications, even if memory isn't low.
FORCE STOP OTHER APPLICATIONS Allows an application to forcibly stop
other applications.
MEASURE APPLICATION STORAGE SPACE Allows an application to retrieve
its code, data, and cache sizes
I am looking into mobile app development, and I had some questions about the android platform.
Does the android platform use a central settings and preferences page (much like the gears icon on an iOS device)?
I've been reading about services. Are these what I would use if I wanted to develop an application that doesn't have a UI (think something like the drop box client)?
In my reading about services I read that the android OS will kill your service when it thinks that it needs to reclaim resources. Is there a way to ensure a service wouldn't be killed?
How much control would I as a developer have over the physical hardware? Say if I wanted to make an app to block distractions, and to do this I would need to control the networking interfaces beyond purposely misconfiguring these interfaces to block their connection? Can I programmatically turn off these interfaces?
Each individual application has its own settings page, but this is generally created by using the built-in Android settings class (you can just subclass PreferenceActivity)
Every application must have an activity (A screen with a UI), but yes, you can do the majority of your work in a service, which is analogous to a background process on a desktop computer
There is no way to ensure that Android won't kill your service without rooting the phone. However,
"If the service is bound to an activity that has user focus, then it's
less likely to be killed, and if the service is declared to run in the
foreground (discussed later), then it will almost never be killed" link
Yes, you have access to any hardware (GPS, WiFi, Bluetooth, 3G radios, camera, etc) through the Android API. You will have to request an install time permission from the user in order to deal with them, however. Also, other programs can turn them back on.
I'm trying to find out how applications like Perfect App Protector or Smart Applock Free work.
What mechanism is used?
These applications use a service to monitor whether a new application is trying to launch or not.
It can be done in several ways. If running application matched with the configured application then it is sent back to the background by the service and may ask for lock code, password as you configured earlier. If it matches then you will get the application on the foreground. Otherwise it kills the process from being executed.