Is there any way to assure that my application's window is not obscured by any other application's view using with SYSTEM_ALERT_WINDOW permission?
If not, then is there any better way to assure that my app is not obscured by such window apart from obtaining the same permission and refreshing/showing/whatever my own view (of course shown in alert window) every 100ms or so to keep it visible?
Eventual flickering, in case my application is obscured, is actually a good thing and an indicator to the user that something is wrong.
EDIT: It seems that there is no way to do it except from going through KNOX on Samsung or some other proprietary solution for Trusted UI. Accepted answer is enough for my purpose, but it is not an answer for the question asked.
Even if it's not exactly what you're asking, the closest replacement I know of is:
Either setting android:filterTouchesWhenObscured="true" in your layout (touch events will be filtered and not reach your View if they are going through an overlay, regardless is transparent or opaque). See View#setFilterTouchesWhenObscured(boolean),
Or overriding View#onFilterTouchEventForSecurity(android.view.MotionEvent) and checking for FLAG_WINDOW_IS_OBSCURED. See View#onFilterTouchEventForSecurity(android.view.MotionEvent).
Later can be implemented like so:
override fun onFilterTouchEventForSecurity(event: MotionEvent): Boolean {
if ((event.flags and MotionEvent.FLAG_WINDOW_IS_OBSCURED) == MotionEvent.FLAG_WINDOW_IS_OBSCURED) {
Toast.makeText(context, "Screen overlay detected!", Toast.LENGTH_LONG).show()
return false // touch event is cancelled
}
return super.onFilterTouchEventForSecurity(event)
}
See also the Security section of View class documentation.
Notice that this functionality is available from API 9+. A workaround for older APIs can be found in this SO Question: Analogue of android:filterTouchesWhenObscured for API level below 9.
Specifically, I'm seeing this issue on an Android tablet, but I'm told it's with ALL mobile devices -- iPhones, Nexus tablets, etc.
But I have the common problem of change events not firing. Here's the function code that has the click events assigned:
function do_this(with_this_data)
{
var that = this;
this.with_this_data = with_this_data;
this.period = 900;
this.updateHours();
$('#date').change(function() {
that.updateHours();
});
$('#time_hour').change(function() {
that.updateMinutes();
});
// extra irrelevant data trimmed out
}
Now...one fix that should work is to move those .change() statements into a $(document).ready block -- but the problem is, if I do, then i get all sorts of undefined variable issues and stuff....all of the "update" functions are within said $(document).ready block and defined by names like "FutureStuff.prototype.updateMinutes."
What are my options???
Mifeet, again, I appreciate your feedback; I know you weren't able to fully get me up and running, but I'm still thankful.
But anyway, I solved the issue...it meant that basically I had to rewrite a new version of the JS code and stick it in an "if this chap is using a mobile browser" block. So yeah, one huge block of code for desktop users, another for mobile...but it works. :) And it was a pain in the hiney.
Background:
I recently purchased a Motorola XOOM Tablet along with the Desktop Dock and Bluetooth Keyboard accessories.
The dock and keyboard work great, but when I take the tablet off the dock to move away from my desk, the keyboard still remains paired with the device and I have to manually change the settings to use the soft keyboard. The same goes for when I set it back on the dock, I need to manually switch it back. It's not a huge problem, but it would be nice not to have to think about it.
So I tried downloading an app from the market that simply toggled Bluetooth on and off when connected or disconnected from a power source, which worked well for a while, but the background service would die after period and become useless until I manually restarted that.
TO THE POINT: I'm trying to write a little app/service for my tablet that will recognize when it has been docked/undocked and switch the "Use Physical Keyboard" setting accordingly.
I have started with a BroadcastReciever to recognize the Dock State:
public class DockBroadcastReciever extends BroadcastReceiver {
private final String DOCK_STATE_LABEL = "android.intent.extra.DOCK_STATE";
#Override
public void onReceive(Context context, Intent intent) {
Bundle extras = intent.getExtras();
String message = (extras.getInt(DOCK_STATE_LABEL) == Intent.EXTRA_DOCK_STATE_UNDOCKED) ? "Undocked" : "Docked";
Toast toast = Toast.makeText(context, message, Toast.LENGTH_LONG);
toast.show();
}
}
But I'm having trouble figuring out the best way to update the setting after the event is fired. I've poked around some examples using InputMethodManager, but all the methods seem to need a specific EditText or some other input to bind to.
Furthermore, I can't seem to find a corresponding constant that represents that setting anywhere in the docs, but graphically, it is located here: http://i.stack.imgur.com/esFaw.png
Can anyone help me out with this?
I would like for there to be a solution for changing the setting, but I am open to other ideas as well.
I have an app that does something similar. It can toggle wifi and bluetooth based on power.
You'll need to register some of this stuff in the AndroidManifest.xml file.
http://code.google.com/p/futonic-wifioncall/source/browse/AndroidManifest.xml
Project Open Source Site: http://code.google.com/p/futonic-wifioncall/
This isn't the solution but hopefully will give guidance on what you're trying to accomplish.
The following problem seems unique to 2.1, happens both on an emulator and on a nexus. The same example works fine on other platforms I've tested (1.5, 1.6 and 2.0 emulators).
I've added created gestureListener as described in this post.
The difference is that I've added the listener on a TextView which also has a contextMenu registered, i.e. sth like the following:
onCreate(...) {
...
// Layout contains a large TextView on which I want to add a context menu
tv = findViewById(R.id.text_view);
tv.registerForContextMenu(this);
// create the gestureListener according above mentioned post.
gestureListener = ...
// set the listener on the text-view
tv.setOnTouchListener(gestureListener);
...
}
When testing it, the correct gesture is recognized alright, but every other time it also causes the context menu to be opened.
As the same example is working on non 2.1 platforms, I've got a feeling it is not my code that is the problem...
Thankful for any suggestions.
Update:
Seems that the return value is flipped somewhere. If I let onFling() return the "wrong" value, i.e. true when the event is skipped and false when it was consumed, it works correctly in 2.1. But of course, that doesn't work on the other platforms. Seems like its time for an ugly workaround...
Thanks for the link steelbytes. I implemented the cancel-and-return-false solution in the last comment (Dec 27, 2010) but just for my onFling event and it appears to work on 1.6 as well as 2.x devices.
I'm building a mobile web app targeting Android users. I need to know what DOM events are available to me. I have been able to make the following work, but not terribly reliably:
click
mouseover
mousedown
mouseup
change
I have not been able to get the following to work:
keypress
keydown
keyup
Does anyone know the full list of what is supported and in what contexts (e.g., is onchange only available to form inputs?)? I can't find a reference for this on The Googles.
Thanks!
Update: I asked the same question on the Android developers list. I will be doing some more testing and will post my results both here and there.
OK, this is interesting. My use case is that I have a series of links (A tags) on a screen in a WebKit view. To test what events area available, using jQuery 1.3.1, I attached every event listed on this page (even ones that don't make sense) to the links then used the up, down, and enter controls on the Android emulator and noted which events fired in which circumstances.
Here is the code I used to attach the events, with results to follow. Note, I'm using "live" event binding because for my application, the A tags are inserted dynamically.
$.each([
'blur',
'change',
'click',
'contextmenu',
'copy',
'cut',
'dblclick',
'error',
'focus',
'keydown',
'keypress',
'keyup',
'mousedown',
'mousemove',
'mouseout',
'mouseover',
'mouseup',
'mousewheel',
'paste',
'reset',
'resize',
'scroll',
'select',
'submit',
// W3C events
'DOMActivate',
'DOMAttrModified',
'DOMCharacterDataModified',
'DOMFocusIn',
'DOMFocusOut',
'DOMMouseScroll',
'DOMNodeInserted',
'DOMNodeRemoved',
'DOMSubtreeModified',
'textInput',
// Microsoft events
'activate',
'beforecopy',
'beforecut',
'beforepaste',
'deactivate',
'focusin',
'focusout',
'hashchange',
'mouseenter',
'mouseleave'
], function () {
$('a').live(this, function (evt) {
alert(evt.type);
});
});
Here's how it shook out:
On first page load with nothing highlighted (no ugly orange selection box around any item), using down button to select the first item, the following events fired (in order): mouseover, mouseenter, mousemove, DOMFocusIn
With an item selected, moving to the next item using the down button, the following events fired (in order): mouseout, mouseover, mousemove, DOMFocusOut, DOMFocusIn
With an item selected, clicking the "enter" button, the following events fired (in order): mousemove, mousedown, DOMFocusOut, mouseup, click, DOMActivate
This strikes me as a bunch of random garbage. And, who's that cheeky IE-only event (mouseenter) making a cameo, then taking the rest of the day off? Oh well, at least now I know what events to watch for.
It would be great if others want to take my test code and do a more thorough run through, perhaps using form elements, images, etc.
Since this is the second most popular Android + JavaScript post on SO (which is just a sad commentary on the state of web development targeting the Android platform), I thought it may be worthwhile including a link to pkk's touch event test results at http://www.quirksmode.org/mobile/tableTouch.html and also http://www.quirksmode.org/mobile/ in general.
As of Android 1.5, the same touch(start|move|end|cancel) events that the iPhone supports work in Android as well.
One problem I found was that touchmove ends get queued up. No workaround yet.