Android - Inactivity/activity Regardless Of Top App
Solution 1:
This is just an idea, and may not be fully transferable.
Here's what an AccessibilityService can do:
An accessibility service runs in the background and receives callbacks by the system when AccessibilityEvents are fired. Such events denote some state transition in the user interface, for example, the focus has changed, a button has been clicked, etc.
You will be informed of the event inside onAccessibilityEvent(AccessibilityEvent)
:
@OverridepublicvoidonAccessibilityEvent(AccessibilityEvent event) {
// Some event
timeSinceLastInteraction = System.currentTimeMillis();
}
You could periodically log the updates:
Log.i("LOG_TIME_ELAPSED", "Last user interaction was " +
((System.currentTimeMillis() - timeSinceLastInteraction) / 1000) +
" seconds ago.");
There are two ways in which you can configure your AccessibilityService:
In code, inside onServiceConnected(). (API 4 onwards)
In xml, using the
meta-data
tag in your service. (API 14 onwards)
In your application's case, you could probably set AccessibilityServiceInfo.eventTypes
to:
accessibilitySeviceInfo.eventTypes = AccessibilityEvent.TYPES_ALL_MASK;
But, TYPES_ALL_MASK will include notifications such as: AccessibilityEvent.TYPE_ANNOUNCEMENT, AccessibilityEvent.TYPE_NOTIFICATION_STATE_CHANGED etc. which I am guessing you do not care to intercept. So, you'll need to choose a subset of AccessibilityEvent.TYPE_X.
Another thing you should be careful about is the notification timeout:
The timeout after the most recent event of a given type before an AccessibilityService is notified.
The event notification timeout is useful to avoid propagating events to the client too frequently since this is accomplished via an expensive interprocess call. One can think of the timeout as a criteria to determine when event generation has settled down.
So, be generous with the timeout value.
You'll find this page very helpful in case you decide to go with the AccessibilityService option: Developing an Accessibility Service.
From your comments to Chloe's answer, it seems that the device is under your control: meaning, to some extent, you don't have to rely on the user for enabling the service:
The lifecycle of an accessibility service is managed exclusively by the system and follows the established service life cycle. Additionally, starting or stopping an accessibility service is triggered exclusively by an explicit user action through enabling or disabling it in the device settings.
You can enable the AccessibilityService at time of deployment, and perhaps restrict access to Settings menu using an app like AppLock.
Another option is to check whether your AccessibilityService is enabled from time to time:
AccessibilityManageram= (AccessibilityManager)
getSystemService(ACCESSIBILITY_SERVICE);
List<AccessibilityServiceInfo> listOfServices =
am.getEnabledAccessibilityServiceList(
AccessibilityServiceInfo.FEEDBACK_ALL_MASK);
for (AccessibilityServiceInfo asi : listOfServices) {
// Check if your AccessibilityService is running
}
In case the AccessibilityService has been disabled by a inquisitive/notorious user, you can lock the device by displaying a fullscreen view with text: Device has been locked. Contact a Sales Rep to unlock this device
.
Solution 2:
I believe you have to return false to indicate that your transparent service window did not consume the touch event. That way the event loop will pass it down the stack to the lower windows.
https://developer.android.com/reference/android/view/View.OnTouchListener.html
Another possibility, is to add a service which listens for motion/accelerometer events.
https://developer.android.com/guide/topics/sensors/sensors_motion.html
Another possibility is to listen for ACTION_USER_PRESENT
https://developer.android.com/reference/android/content/Intent.html#ACTION_USER_PRESENT
or ACTION_SCREEN_ON
https://developer.android.com/reference/android/content/Intent.html#ACTION_SCREEN_ON
Post a Comment for "Android - Inactivity/activity Regardless Of Top App"