This subject has been beat to death, but I'd like to give it one more shot. Every query I do from this site or basically google give several hint/tips on handling when the button is pressed, but from what I understand the Samsung Knox has the ability to disable the button, and I'm wondering if that's a custom implementation baked into knox or just something i'm completely missing.
My application will be set as the device owner application for other reasons, but I do not see any low level items regarding the recent apps button.
I am currently targeting Android 21 (5.0). We currently use commercial (non root, multiple manufacturer and OS level) phones that we provide with one of our apps being mapped to the home button and monitors accessibility, and the primary application we attempt to keep in the foreground.
A few things...
I'm not interested in making my application a kiosk application so that is not an option for mean at this time.
I can monitor for the Intent.ACTION_CLOSE_SYSTEM_DIALOGS and bring my application to the front (or handle differently), but this still allows for the button to be pressed and the screen to load for a bit.
I've attempted all of the options for getWindow().getDecorView() and setting the flags of SYSTEM_UI_FLAG_HIDE_NAVIGATION, SYSTEM_UI_FLAG_IMMERSIVE_STICKY, SYSTEM_UI_FLAG_IMMERSIVE (different combinations of the flags) during the OnResume, OnWindowFocusChanged, and as a callback listener on the 'setOnSystemUiVisibilityChangeListener'. This works OK for a while but after several pull down attempts on my Pixel 2 the navigation is stuck open.
I'm not very well versed in the capabilities of an application that is the device owner, but I cannot find this lower level configuration option available.
Any help is appreciated
Related
I'm a junior software developer and I need to develop an app for wear OS with the following key feature; to detect a long press of physical button on a smartwatch while the app is running in background. Is this even possible? If yes, I would truly appreciate for any links to samples and documentation.
thank you
As far as I know this is not possible. The multifunctional buttons can be mapped to custom actions, but only when an application is running in the foreground. Otherwise they are controlled by the system (to e.g. act as a shortcut to Google Pay).
Even if it was possible, your app would only work on some devices since not all models have a multifunctional button. The only button that is guaranteed to exist on all devices is the power button, and this one you can definitely not get any events from in your app.
You've probably seen this already but I'm attaching it in case it's helpful to someone:
Design guidelines plus recommended use cases and behavior can be found here
Implementation reference for the multifunctional buttons is here
I have an customer project where I have to make single task android device. Customer isn't able to escape the application which my company have developed. Also customer isn't able to start any other application and our application is started when the device is booted. Overall all the customer is able to do with the device is run our application.
Is there any other way to make this work than rooting the device, disabling all system buttons and making our application the launcher. I have something like 400 devices for this purpose so rooting all those would cost lot of time.
I also read Google's tutorial about COSU devices but found it very confucing https://developer.android.com/work/cosu.html#testing-plan
Androids own screen pinning is not good enough because customer can escape the app. Some may suggest to use some kiosk application like SureLock but my company's goal is to find clear solution for this without using any third party apps. Also running our app via some kiosk application is not our goal.
I found some posts on the Stack Overflow with similar question, but not the answer I'm looking for.
If someone has some tips for this question I would be very grateful.
Single purpose devices built on top of Android can get difficult to implement. There are a few different options, but each have trade-offs.
As you mentioned, rooting devices will functionally get you what you want - however it will be time consuming with hundreds of devices to root, difficult to maintain, and you will (potentially) introduce security issues to your devices and app.
Another option is using Google's Lock Task Mode for COSU devices[1]. The link there has a nice graphic showing the features of lock task mode:
1 app pinned to the home screen
only apps white-listed by the DPC (device policy controller) can be locked
Home and Recent buttons hidden
exit by calling stopLockTask()
There are some downsides to using Google's solution for this. First Google recommends creating (and therefor maintaining) an entirely separate DPC app to run as a device owner and set policies[2]. You'll also be dependent on Google Play to manage application updates and be required to have Play accounts associated with each device which "are used to identify a single device that is not tied to a single user for simplified, per-device app distribution rules in COSU-style scenarios"[3]. To automatically get your DPC app on devices your "DPC must be publicly availble on Google Play, and the end user can install the DPC from the device setup wizard by entering the DPC-specific identifier."[3] You'll also need to upload the user application to Google Play[4], which may be an issue for some who don't want their apps on Play. Going this route gives you features you need, but can be complicated and also ties you and your customer pretty tightly with Google/Play services and their workflow.
You can also look at enterprise mobile deployment platforms like Mason[5]. In your case, you can create a custom Android OS in a few minutes with your app locked in kiosk mode (+ other features like disable camera/sms, remove apps and hide settings, etc.) and then deploy it to all of your devices remotely. Mason also supports OS and app updates controlled by you if your requirements change.
DISCLAIMER: I work for Mason
[1] https://developer.android.com/work/cosu.html
[2] https://developer.android.com/work/cosu.html#create-dpc
[3] https://developers.google.com/android/work/requirements/cosu
[4] https://developers.google.com/android/work/play/emm-api/samples#push_install_an_app_on_a_device
[5] https://bymason.com/
I went to the same problem before. I spent at least 3 days doing research. I tried to find many solutions but I found zero.
How I solve is
1. Up To JellyBean
- Use System Alert Dialog (And make it transparent and small size like 2 * 2 And display in some corner(User can't see it)). User can't press home button If there is system Alert dialog
2. After JellyBean, This method doesn't work. The user can press the home button even though there is System Alert Dialog.
so what I did is, start the service on stop and start the same activity again and again(within sec). So user can't see any difference.Don't forget to make activity as single task so that even though you start same activity from service, again and again, new activity will not create (So Ugly way )
- You can simple make screen full screen. make sure in kiosk mode try to check if the screen is in full-screen mode. if not make it full-screen mode(its not hard to do)
- other way is to make launcher app but when ever you pressed home button it always asked to choose launcher app. if user mistakenly choose default/ other launcher app, this solution doesnt work
Good luck
Make your application as a launcher application by defining in manifest file.
After that go to setting of your mobile device and change default launcher application to your application.
A little background first. I'm developing an application for corporate devices running on the Android platform. It won't be distributed on the Play store and thus, is unavailable to the general public. The devices are owned by the company and its only purpose is to run this application. So accessing the home screen/notifications/application history/ app drawer are unnecessary and in fact we want to focus the user experience directly on this application.
The current problem I'm facing is preventing access to the notification tray. Simply making the application full screen is not a solution. We do actually need to see the status bar. It's the easiest way to provide network,gps and battery status information to the user.
So far my research has only turned up one solution, which is to go full screen (again, not a solution for this problem,I need the status bar to be visible). I know there's a number of lock screen apps that are able to do this so there must be a way. I just haven't found it yet.
I am not sure, but probably that you can't just lock notification bar from the application level. Android app is isolated from the Operating System and another apps, so it is not able to lock OS features.
Solution that came into my head is to make app fullscreen and create Your own status bar with battery level, current time and network status. It is not hard.
Another solution would be to prepare Your own Android distribution :)
Moreover probably You would like to override all buttons (home, back, search) so user is not able to leave your app.
Very likely is not going to be possible on a Stock device, you'd have to root and potentially install your own version of the OS to allow for this behavior. The system was purposefully made to disallow applications from having this type of behavior. The creators of the OS had the general public in mind as users, and they wanted to prevent applications from being able to "lock" the user out of portions of the device.
Much easier solution like #Jacek states is go full screen and make your own View to display whatever info that you do want from the Notifications bar, AFAIK there are public APIs to access all of that information.
My app has code to go full-screen where sensible to do so -- it's sensible on most Android 1 and 2 devices, but under Android 3 for example going full-screen loses the app menu button, and at the moment I don't implement my own menu button so users can't (or at least can't easily) get to the app's menu.
At the moment I test for Android version < 3, and go full-screen if that's the case, but I have users with Android 2 tablets (Viewsonic view pad 10s for example) where this isn't sensible (the Viewsonic user tells me she has to hold down the back button to get app's menu to appear).
Is there a better way of testing whether going full-screen will lose the menu button? Or going full screen only if it's sensible to do so?
Thanks for any help you can give. Let me know if you need more info or if the above isn't clear.
Mark
Is there a better way of testing whether going full-screen will lose the menu button?
No. The Viewsonic device in question does not qualify for the Android Market, AFAIK, and all bets are off in terms of compatibility for devices that fail to meet the requirements for the Market.
Are there any requirements/guidelines for an Android device? like numbers of buttons or minimum buttons required.
Also are there any android devices which do not have the menu and back buttons?
( I am aware that no menu/back buttons will kill most of the apps in terms of usability , I just wanted to know more on the topic :-) )
Are there any requirements/guidelines
for an Android device? like numbers of
buttons or minimum buttons required.
Yes. These are documented in the Compatibility Definition Document.
Also are there any android devices
which do not have the menu and back
buttons?
That depends on how you define "buttons" and "android devices". Quoting from the CDD (see above link):
The Home, Menu and Back functions are
essential to the Android navigation
paradigm. Device implementations MUST
make these functions available to the
user at all times, regardless of
application state. These functions
SHOULD be implemented via dedicated
buttons. They MAY be implemented using
software, gestures, touch panel, etc.,
but if so they MUST be always
accessible and not obscure or
interfere with the available
application display area.
There are devices that do not have dedicated off-screen buttons (whether physical or touch-sensitive off-screen spots). The ARCHOS 5 Android tablet is one -- it has the HOME and BACK buttons in an expanded title bar. However, it is unclear if Google considered them to have met the CDD, since the ARCHOS does not have the Android Market. Devices lacking the Market may not meet the CDD.
So, it is entirely possible to create devices that do not meet the CDD, but at that point Android is mostly just another embedded OS, IMHO.
I would recommend this links:
Twitter for Android: A closer look at Android’s evolving UI patterns
Android UI design patterns
User Interface Guidelines