I have a working app with notification media controls. I am properly using Notification.MediaStyle(). Everything works well on Google Pixel 4a. However Samsung devices are showing their own system/default controls on lock screen. Buttons are wrong, metadata is missing and they are not usable.
So the question is how do I make them work or how do I disable them? I was not able to find any related documentation.
Related
I have the same website for mobile and desktop devices. One weird behavior I discovered is on mobile devices - Android and Chrome browser.
I didnt have the opportunity to discover exact trigger of the behavior but I think it has something to do with screen turning off.
I have this code before unload. On desktop it works fine.
$(document).on('beforeunload',function(){
$('.loading').show();
})
On phone it works also good but when I minimize Chrome or screen turns off and I wake up the phone. It triggers beforeunload event. Because of that I need to reload the page. I tried also small workaround that clicking on the .loading class will hide it, but with this behavior it doesnt work.
Any ideas ?
I am currently using the "deprecated" code in the example below to disable vibrations globally on the phones using my app, but so far I have discovered that it is no longer working in Android 5, but it had worked fine in Android 4 and below. There are many complains about Google taking the silent mode out but there must be a way how to disable vibration, I guess. But I couldn't find any other example in the documentation nor via google.
Any ideas pls help...
The example:
Enabling and disabling vibration in android programmatically
The only way to fully disable vibrations at the moment in Lollipop is Silent Mode (which is completely different than what our old silent mode is). I hope this gets fixed, but there is no other way currently to disable it all.
I want my music widget to be shown on the screen in a similar way that RemoteControlClient works. I don't want the users to be needed to have the widget added to the lock screen beforehand. The samsung music app on thier 4.2 devices have this behaviour.
AFAIK, this isn't possible in the public SDK. Samsung's apps may be able to do it on their device because they are developed by Samsung for their own devices and have greater access as preinstalled system apps.
No API that I am aware of does this as of now.
I am trying to work with trigger.io and Kendoui Mobile.
the point is, when launching the mobile app on emulator all works like expected - but when it runs on android mobile the Layout / View doesnt show up until you touch the screen or turn the mobile to landscape or viceversa.
with a tabstrip of kendoui one time showed up you can swtich between views with no problems.
but if you redirect to another view with different layout you have to touch again the screen to show the content (it just shows just the background of body until touch).
the telerik guys at the moment dont know from where it comes from as they tested it with phonegap and no problems.
Maybe the trigger.io guys can find out why it happens?
Best regards
marc
It looks like this is an issue with hardware acceleration on Android 4.0, probably an unfortunate interaction between whatever hardware accelerated transitions Kendo UI use and that particular version of Android.
Phonegap seem to have hardware acceleration disabled by default, which is why they would not be affected.
As a fix we are going to add an option to disable hardware acceleration on that particular Android version, which we'll have live by the end of the week.
I have this browser launching application which didn't have any problem till now: when it is being tested on Samsung Galaxy 10.1 (Model Number: GT-P7510) with Android 3.1 Honeycomb.
The issue is this: whenever I tap on a text box, the whole screen will flash across a black screen for a moment and revert back to normal. It starts flickering/blinking the black screen when I leave a focus on any text box as well.
Currently, I've no idea what is causing this issue as I've tested this application on several devices e.g. Samsung Galaxy S, Samsung Galaxy Tab 7-inch with previous version of OS from 2.1 to 2.3.
Anyone who has any clue as to what is going on whether be it a compatibility issue with the app or a change in function in honeycomb 3.1 or the device itself, please share your information and enlighten me on this matter please. Any kind of help is greatly appreciated!
Thanks
I'm sorry that this is not a solution, but I think I can shed some light on the problem.
We have recently been testing a functional jQuery Mobile HTML5 app wrapped with PhoneGap Android 2.x phones to the Galaxy tab 10.1. We have seen something very similar, with the exception that we have defined a splash screen for our app. What we see is that when an input field is given focus, the screen flashes up the splash screen momentarily. Very annoying! To verify if this is the same problem, define a splash screen for your PhoneGap app and see if the screen flahes your image instead of a black background. Knowing something about what's going on with PhoneGap and the Android WebView, this is my best estimation of what is happening: PhoneGap loads the main App activity with a black background and displays the splash screen (if defined) in that initial window. PhoneGap then starts the WebView and opens it on top of the main Window. When a field is selected, the Android invalidates the component wach time it updates it based on a focus event or keypress, or whatever, and Android redraws everything. So it redraws the main window behind the WebView and then redraws the WebView with the HTML page content on top of it. Since the device is not properly double-buffered, you see all of this redrawing in all its ugly glory right in front of your eyes.
We have seen serious glitches with Android web forms on some Android 2.x phones we have tested, and this looks like yet another glitch, but this time on the Galaxy Tab running Honeycomb (3.0).
We have attempted to use CSS -webkit-backface-visibility to resolve issues on some phones when experiencing flicker in the past - but this has caused serious rendering issues in HTML forms. Be warned! In theory this should be a viable fix to introduce some double-buffering into the mix, but in our experience it causes more problems than it solves.
I am not confident that this can be resolved, except by an Android software update from Google/Samsung.