We have many phones using Android Management with kioskCustomLauncherEnabled on. When opening applications occasionally they will minimize as if the home button was pressed. We've observed this on Pixel 1, Pixel 3a and Pixel 4a phones. We've disabled all gestures thinking that might be related but it still occurs.
Is this a bug of the phone's kiosk mode? Is there a workaround?
Hi there and thanks for your question,
I think it's a bit difficult to answer without looking at your dedicated device policy. I haven't heard personally of such a bug but maybe it could be a behaviour you set on your policy? Generally, you would use kioskCustomLauncherEnabled if a device requires users to access one or more apps from the home screen triggering a go back to home type of behaviour while keyguardDisabled would trigger the device to stay unlocked. You will also want to disable a maximum amount of settings available to the user.
Theo L
Android Enterprise
This appears to have been a Pixel 3A problem. One of the recent system updates a few months ago seems to have made the problem go away. Doesn't appear to still be an issue
Related
I'm using opengl es 3.0 API with the android studio ndk to create apps.
But I've encountered a very huge problem. I've created a demo app, all it does it change the background color of the screen from white to black and vice versa, every frame. And so when I go to minimize this app, I still see it rendering the background, mostly at the edges of the screen, and not in full color but still very strongly apparent. And it doesn't go away when I close the app, when I restart the device, or when I run "kill apps" on it. Only a factory data reset fixes the issue, so it's not easy for me to debug this.
This is the relevant code that I'm using for when the app is minimized and receives the APP_CMD_TERMINATE event:
eglMakeCurrent(engine->display,EGL_NO_SURFACE,EGL_NO_SURFACE,EGL_NO_CONTEXT);
eglDestroySurface(engine->display,engine->surface);
engine->display = EGL_NO_DISPLAY;
engine->surface = EGL_NO_SURFACE;
I've error checked that eglDestroySurface() is successful.
And I've put debugging messages in to make sure that the main draw loop is NOT executing when the app is minimized. But the problem persists and I don't know what to do about it. Thanks for any help.
UPDATE: well, no one has responded, and I still don't know what to do. Could it be related to threads?
UPDATE: Still can't determine what it is, but for some reason it's messing with the System UI. Willing to upload my entire source code somewhere if someone would be willing to go through this with me, as I'd really like to be able to continue working on my game engine.
Is it the "Strict Mode" developer option on the device settings, perhaps?
That one flashes the screen if an app is blocking.
It would explain why a factory reset changes behaviour.
The answer is not a solution here. The above comment by the user columbo was correct.
I've demoed switching from black to white at high framerates on 3 different android devices, and also my Linux Desktop, all via the openGL api, and it has exhibited this issue on all the devices. So what he said must be correct: this is a problem with LCD monitor technology itself. Interestingly, doing completely random colors does not cause this problem.
I'm currently working on a website that will be in an exhibition soon. Users will have a keyboard and mouse in front of them, so I need to lock down the machine to be restricted to just one website. Guided Access mode on iOS is a perfect example. I wish Apple had an OS X version for this reason.
I'm currently trying parental controls but it seems to be quite buggy/not responding to my preferences. I'd really love to just have Chrome or Safari locked to fullscreen somehow so users can't exit the browser/redirect to another website.
Thank you in advance!
I'm thinking you could put Chrome in kiosk mode(can't change website) then change the shortcut keys for exiting out of fullscreen mode if you can on a Mac, and maybe having another desktop and monitor for emergencies. I would have made this a comment but I can't :P This isn't really an answer, just a suggestion. It would really be easier on another OS to do the stuff above.
Recently used 'Web Kiosk' software for exactly this purpose: https://www.macproline.com/webkiosk
It has a lot of options for locking down the machine, both in terms of web sites visited, and disabling key commands, preferences, switching apps, quitting apps, etc.
When searching for a solution for this, I was surprised how few options there were. That said, I would give this a look.
I am developing a windows phone app that uses users current location, I am making the app in 7 OS. My question is, Can I track the location in background, that is when the screen is locked?
I know this is a possibility in wp8 as it provides us with GeoLocator class, but can I achieve this in wp7? I am basically making a runtracker app hence I would like my app to track the location even when its in background, is it really feasible?
Your help is always appreciated!!
It is possible to keep the app running under lock screen, as it does, for example, Endomondo app.
Using Idle Detection, you can keep the app on, although screen is locked, and you can keep on tracking the location. Actually, it is not running in background, but in the foreground. Just the screen is locked. So, be careful not to drain user's battery.
You have to set the PhoneApplicationService.ApplicationIdleDetectionMode property to Disabled, for example in InitializePhoneApplication() method in App.xaml.cs:
PhoneApplicationService.Current.ApplicationIdleDetectionMode = IdleDetectionMode.Disabled;
Note that there are special certification requirements for this type of apps. Refer to section 6.3 (Apps running under a locked screen) of the following page:
Additional requirements for specific app types for Windows Phone
I got the same problem in one on my apps..
I don't think it' s feasible for wp7..
Bt if you want to do it with wp8 you can refer following link.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681691%28v=vs.105%29.aspx
And to know about background supported and unsupported API's http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202942%28v=vs.105%29.aspx/css
GeoCoordinateWatcher Class exists in WP7, but here is the documentation from MSDN -
This API, used for obtaining the geographic coordinates of the device,
is supported for use in background agents, but it uses a cached
location value instead of real-time data. The cached location value is
updated by the device every 15 minutes.
More Info : http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202962%28v=vs.105%29.aspx/css
I'm doing a phone app with some animations and they look really clunky on the emulator. I don't have a phone yet so this is the only way I can test my app.
Sometimes the animations start late (up to a second after user input) and the they are almost always very jagged. Far from the smooth fades and transitions that I've seen on the interwebs. I'm not using anything hairy - just basic rotations and opacity fades on one or two elements.
Does anyone else see this in the emulator? If not, i guess I have a bug somewhere. If so, is there a work around? Should I bump the priority of the xde.exe in process explorer? Other?
Thanks!
This may be a consequence of gpu detection no working on your system.
You can verify this by checking if you can see the frame rate counters.
Jeff Wilcox – Frame rate counters in Windows Phone
Note the emulator system requirements here also.
Setup and System Requirements for Windows Phone Emulator
Is it possible to track the accelerometer value while under the lock screen?
I managed to write a simple application which counts from 1 up to 100 using a timer which fires an event on which I increment a counter.
But when I use register a handler for the ReadingChanged event of the accelerometer it will not be fired anymore once the screen has been locked. Even if I unlock the screen again I will have to readd my handler.
the msdn documentation tells on the one page:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff941090(v=vs.105).aspx
"Valid reasons to disable idle detection in Windows Phone OS 7.1 applications include ones where core functionality continues while the phone is locked (for instance, an exercise tracking app)"
but the sensor api also tells:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202968(v=vs.105).aspx
"The Sensor APIs cannot be used while the application is running under the lock screen. For more information, see Idle Detection for Windows Phone. The Sensor APIs also cannot be used in background agents. For more information, see Background Agents Overview for Windows Phone"
I hope they will change the api soon, because of that it is not possible to write any good sleep tracking / sport tracking applications ... :(
I was helping a guy with this a couple of days ago. He had an app that tracks GPS and accelerometer data under lock screen.
Turned out the app accelerometer data stopped tracking when under manual or auto lock screen.
There may be an issue here to be looked into.
Under lock screen it is a good idea to minimise power usage... disable all uncessary code, like ui updates. My understanding of one the motivations for idle detection and running under lockscreen being opened up during CTP was in response to a lot of feedback from developers of map/tracking apps that basically need this for their app to be of any use.
I'm not sure of the usage case where you'd want to use the accelerometer under the lock screen.
Apps typically run under the lock screen when you need them to do something when you're not interacting with the device. e.g. playing music or downloading a large file.
If you wanted accelerometer data I'd assume that the device is being held and, therefore, presumably, looked at. Given this, why would you therefore want to run under the lock screen?
That being said, if you had a good reason to do so, you should still be aware that:
when your application runs under a locked screen, it ... must minimize
power usage
(from the Marketplace Certification Requirements.)
In my understanding, reading values from sensors is not minimizing power usage.