March 9, 2014 at 13:40Is there an API for Kiosk apps on Android?
With this publication, I would like to provoke a discussion of the problem that occurs in the Android system: the impossibility, without tricks and hacks, using methods approved by official guidelines, to create applications for execution in a protected environment (kiosk applications).
The kiosk software must protect the Internet kiosk (in this case, the Android terminal) from unauthorized activity. The kiosk should be protected from the possibility of calling system dialogs, access to device settings, access to the file system, etc.
The application I'm working on should be installed on terminals that are located in public places, such as shopping centers, cafes. Accordingly, any user by default should be considered an attacker who wants to go into the system settings, change them, perform a system reset, or install a malicious application. Any such actions should be stopped by the kiosk system.
Another class of similar applications - electronic menus in restaurants. I have seen such menus implemented both on Android devices and on iPad. Moreover, the same software was used both there and there, differing only in the design for a particular restaurant. So, the iOS device was better protected in my opinion, because in the Android version, I was able to easily enter the settings, I had the opportunity to change them. In iOS, all system functions for the user were disabled and all that was offered to me was to enter some kind of pin code, which, apparently, will unlock the kiosk.
Find developer.android.com documentationdid not make a complete picture on the issue of the kiosk. Similar questions are periodically asked on stackoverflow, and people even offer private solutions to some kiosk tasks. Here, for example, some of them:
1. It is possible to run Activity or the entire application in full screen mode by hiding the statusbar. Google seems to call it immersive mode. Also, you can temporarily hide the system buttons (panel at the bottom of the screen). Well suited for video players, games, presentation programs. Unfortunately, the user can “pull out” the statusbar back by swiping at the top of the screen (swipe down), and also return the panel of system buttons.
2. It is possible to get an instance of the “statusbar” system service and use reflection to call the hidden disable method. Unfortunately, having done this we will get a SecurityException, as Only the system applications are allowed to hide the statusbar. To become a system, you must sign your application with the key received from the device developer. The opportunity is not always there.
Also, invoking a hidden undocumented method is not a good idea. Apparently, the developers of the system for a reason did not provide an open interface for this method.
3. We can override the onBackPressed method in the Activity class by locking the system back button. We can hang the intent filter on the HOME action by intercepting the Home button. But we cannot intercept the action of the “Recent” system button.
4. It is possible to struggle with pressing the “Recent” system button or calling the statusbar by intercepting the “loss of focus” event. If our Activity loses focus, we immediately return it. Unfortunately, it may take about a second between losing and returning focus (maybe less, maybe more - depends on the speed of the system) and the user can manage to go to the settings menu or remove our application, or do something else.
5. We can generally disable system buttons by editing the /system/build.prop file:
But, firstly, this requires root access, and secondly, I would like to be able to do this programmatically (yes, you can programmatically edit this file, remount read only filesystem first, then reboot the device, but it's still a hack).
It turns out that Android lacks a holistic concept for creating kiosk applications. I would like to have a separate API section that solves the questions posed. I would like to have a set of recommendations from Google on creating such applications.
Yes, I understand - the creation of such applications imposes an additional responsibility on the developer. This paves the way for the creators of locker viruses. But how did developers on other platforms solve this problem?
The kiosk software must protect the Internet kiosk (in this case, the Android terminal) from unauthorized activity. The kiosk should be protected from the possibility of calling system dialogs, access to device settings, access to the file system, etc.
The application I'm working on should be installed on terminals that are located in public places, such as shopping centers, cafes. Accordingly, any user by default should be considered an attacker who wants to go into the system settings, change them, perform a system reset, or install a malicious application. Any such actions should be stopped by the kiosk system.
Another class of similar applications - electronic menus in restaurants. I have seen such menus implemented both on Android devices and on iPad. Moreover, the same software was used both there and there, differing only in the design for a particular restaurant. So, the iOS device was better protected in my opinion, because in the Android version, I was able to easily enter the settings, I had the opportunity to change them. In iOS, all system functions for the user were disabled and all that was offered to me was to enter some kind of pin code, which, apparently, will unlock the kiosk.
Find developer.android.com documentationdid not make a complete picture on the issue of the kiosk. Similar questions are periodically asked on stackoverflow, and people even offer private solutions to some kiosk tasks. Here, for example, some of them:
1. It is possible to run Activity or the entire application in full screen mode by hiding the statusbar. Google seems to call it immersive mode. Also, you can temporarily hide the system buttons (panel at the bottom of the screen). Well suited for video players, games, presentation programs. Unfortunately, the user can “pull out” the statusbar back by swiping at the top of the screen (swipe down), and also return the panel of system buttons.
2. It is possible to get an instance of the “statusbar” system service and use reflection to call the hidden disable method. Unfortunately, having done this we will get a SecurityException, as Only the system applications are allowed to hide the statusbar. To become a system, you must sign your application with the key received from the device developer. The opportunity is not always there.
Also, invoking a hidden undocumented method is not a good idea. Apparently, the developers of the system for a reason did not provide an open interface for this method.
3. We can override the onBackPressed method in the Activity class by locking the system back button. We can hang the intent filter on the HOME action by intercepting the Home button. But we cannot intercept the action of the “Recent” system button.
4. It is possible to struggle with pressing the “Recent” system button or calling the statusbar by intercepting the “loss of focus” event. If our Activity loses focus, we immediately return it. Unfortunately, it may take about a second between losing and returning focus (maybe less, maybe more - depends on the speed of the system) and the user can manage to go to the settings menu or remove our application, or do something else.
5. We can generally disable system buttons by editing the /system/build.prop file:
qemu.hw.mainkeys=0But, firstly, this requires root access, and secondly, I would like to be able to do this programmatically (yes, you can programmatically edit this file, remount read only filesystem first, then reboot the device, but it's still a hack).
It turns out that Android lacks a holistic concept for creating kiosk applications. I would like to have a separate API section that solves the questions posed. I would like to have a set of recommendations from Google on creating such applications.
Yes, I understand - the creation of such applications imposes an additional responsibility on the developer. This paves the way for the creators of locker viruses. But how did developers on other platforms solve this problem?