I have not been able to replicate this, but is anyone aware of what might cause the entire screen on an Android device to go light blue? It seems related to selecting a radio buttons and then scrolling. It happens on Nexus 5x with Android 8.
Here is what it looks like:
I have only heard of one other instance of this occurring. Could it be device specific? Strangely enough, once it happens it seem to stay this way, though the user says it is somewhat intermittent.
Update:
This only seems to happen on Android 8, if that helps anyone...
So, I eventually found the offending code. I verified this is only happening on Android 8 devices, maybe only Samsung? The offending code was:
mFormScrollView.setDescendantFocusability(ViewGroup.FOCUS_BEFORE_DESCENDANTS);
mFormScrollView.setFocusable(true);
mFormScrollView.setFocusableInTouchMode(true);
// Hide the keyboard when moving the screen up or down. This should only
// be an issue when
// on a text edit field. Also disable focus jump using
// "requestFocusFromTouch"
mFormScrollView.setOnTouchListener(new OnTouchListener() {
public boolean onTouch(View view, MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_UP || event.getAction() == MotionEvent.ACTION_DOWN) {
Utilities.hideKeyBoard(FormActivity.this, view);
}
// Keeps screen from jumping to nearest EditText
// view.requestFocusFromTouch();
return false;
}
});
The offending line is commented out - the view.requestFocusFromTouch() method, which was meant to keep the screen from auto jumping to the next text field when the keyboard was hidden and focus lost. On Android 8 this is not happening, but I need to verify with older versions.
Related
I'm trying to troubleshoot a tricky, difficult to reproduce (therefore possibly hardware related) problem for the open source Panic Button application I'm working on for Amnesty. There's an issue on github about it.
The issue is with a LinearLayout View with Buttons. When displayed in this fragment, when I try to hold a button, it just unpresses itself after one second exactly. When logging the onClick event, it triggers itself automatically even though I haven't released my finger from the screen.
This happens on the Cherry Gem phone, and I wasn't able to reproduce the problem on other phones.
I've been removing a lot of code and adding lots of logging statements to try and isolate the bug when I discovered the strangest thing, which led me to post this on Stack Overflow since it's strange enough that maybe someone will recognise the pattern:
When I drag my finger on the screen, then the bug goes away! More precisely, after confirming on the screen that the button unpresses itself a few times, if I hold and drag my finger around, then release it, after that I can hold buttons pressed without them unpressing themselves. Wat?
Please note that I'm not asking to solve the problem of trying to detect a long press (which this leads to of course), but trying to understand this problem of unwanted unpressing before I move on to implement a workaround. Therefore I'd also would prefer not to move the events to onTouch listeners, because I'm worried it would not address the root cause of the problem and I'd like to understand why this is happening first.
I'm not a 100% sure if there could be an unwanted interaction with the rest of the code and will also try to create a minimalistic project from scratch with only that code, if no-one recognises the pattern here.
I can also post a small video of the problem if that helps. I'm also happy to post code excerpts or logcat results.
Thanks for your time!
Jun
Update
I've looked at the adb shell getevent log which confirms that after .9 seconds there is an EV_KEY BTN_TOUCH UP
event. Does this confirm that from the OS's standpoint, it's receiving an event from the hardware about a button up? I guess this might be also triggered by software.
This led me to look into software that is installed on the phone and could interfere with the input devices. I've deactivated the Google voice typing, and then holding buttons worked again. Reactivating Google voice typing didn't make the bug reappear. Rebooting the phone then makes the bug reappear.
I tried to look at whether only some applications were affected. The pre-installed calculator was also affected. When using the default virtual keyboard the bug didn't happen. But then when returning to my app the bug had gone away again. Rebooted again. Calculator still affected. Go back to using the virtual keyboard in the browser. Now the bug stays... Wat?
After a while, I removed the Google voice typing input device again and the bug disappeared once more.
I have tracked a forum where there seems to be a rom for this phone, I'm trying to find out whether it's more recent than the version I have, or if anyone else with this phone experienced that problem as well.
(I also updated the relevant github issue)
Update 2
I noticed the following in the logcat:
04-01 12:05:30.484: V/PhoneWindow(2749): DecorView setVisiblity: visibility = 0
04-01 12:05:30.525: V/InputMethodManager(2749): onWindowFocus: null softInputMode=288 first=true flags=#1810100
04-01 12:05:30.528: V/InputMethodManager(2749): START INPUT: com.android.internal.policy.impl.PhoneWindow$DecorView{41aa5ef8 V.E..... R.....ID 0,0-480,800} ic=null tba=android.view.inputmethod.EditorInfo#41a3fef8 controlFlags=#104
04-01 12:05:30.530: V/InputMethodManager(2749): Starting input: Bind result=InputBindResult{com.android.internal.view.IInputMethodSession$Stub$Proxy#41a48da8 com.android.inputmethod.latin/.LatinIME #45}
04-01 12:05:30.608: I/InputMethodManager(2749): handleMessage: MSG_SET_ACTIVE true, was false
Could this be part of the problem?
For odd problems such as this, I think it's useful to override the onTouchEvent listener, and observe which MotionEvent is triggered (like ACTION_MOVE, ACTION_UP/DOWN). The root problem may be the touch screen driver of the device. So it may be good to test that driver with onTouchEvent.
There is, I think, a good webpage # Touch Device Configuration. Search text for "Driver reports signal strength as pressure". I think this is interesting and perhaps you could simply change the values for touch.pressure.calibration or/and scale for troubleshooting. This file has extension of idc, should reside on system subdirectory.
I want to provide sample code to override mouse/swiping events:
#Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
switch (ev.getAction() & MotionEvent.ACTION_MASK) {
// Make sure ACTION_DOWN is dispatched to children view
case MotionEvent.ACTION_DOWN:
onTouchEvent(ev);
// Allow the children view to process this action
return false; // skip calling onInterceptTouchEvent
case MotionEvent.ACTION_MOVE:
onTouchEvent(ev);
return false;
default:
break;
}
return super.onInterceptTouchEvent(ev);
}
#Override
public boolean onTouchEvent (MotionEvent event) {
switch (event.getAction() & MotionEvent.ACTION_MASK) {
case MotionEvent.ACTION_DOWN:
mDownX = (int)event.getX();
mDownY = (int)event.getY();
break;
case MotionEvent.ACTION_MOVE:
...
Notes:
Method onInterceptTouchEvent occurs before onTouchEvent.
This method intercepts all touch screen motion events. This allows you to watch events as they are dispatched to your children.
i'm working on a project wich require the use of a custom soft keyboard developed by some one else. The problem is that the setOnEditorActionListener does not work in a specific windows where a fragment is used. Does not work means that the onEditorAction is not fired at all. The problem appens only with the custom keyboard, with the default one every thing is working well. The problem is that the soft keyboard project is very complex because i don't know soft keyboard logics and I need to solve the problem before tomoroow morning. Does anyone have an idea of this behavior? Please help
this is the part where i set the listener, this code is working all around the project but here, even the first listener's line is not reached
((EditText) getView().findViewById(R.seatDetailCommonHeader.txtName)).setOnEditorActionListener(new OnEditorActionListener() {
#Override
public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
if (event != null && event.getAction() != KeyEvent.ACTION_DOWN) {
return true;
}
// KeyboardHelper.setKeyboardVisibilty(v, false);
executeCheck();
return true;
}
});
i went into further investigations, i put a breakpoint on every method's first line in the keyboard code (which is the one taken from the sdk samples with just some layout modification) and the same EditText in two different activities fires different methods:
in one case (the working one) this methods are fired when action button is clicked:
LatinKeyboard.isInside
LatinKeyboard.isInside
LatinKeyboard.isInside
LatinKeyboard.isInside
LatinKeyboard.isInside
LatinKeyboard.isInside
LatinKeyboard.isInside
LatinKeyboard.isInside
LatinKeyboard.isInside
SoftKeyboard.onKey
SoftKeyboard.isWordSeparator
SoftKeyboard.sendKey
SoftKeyboard.keyDownUp
SoftKeyboard.keyDownUp
SoftKeyboard.updateShiftKeyState
in the other case (the one that is not working) the same methods are fired, plus these:
SoftKeyboard.onFinishInput
SoftKeyboard.onStartInput
SoftKeyboard.updateShiftKeyState
LatinKeyboard.setImeOptions
SoftKeyboard.onStartInputView
hope someone has some idea of this behavior because i'm really in trouble
Is there an opportunity to implement an element that is able to get pressed longer then 30 sec until the MotionEvent Action_up timeout gets automatically fired?
Maybe an other concept of doing that job?
At the moment i have changed the image of an ImageButton by using the onTouchListener and the action_up and action_down define. But this concept is getting ruined by the auto action_up from android.
Edit:
The problem could be caused by samsungs android mod. It occurs on the Galaxy Tab2 7.0 Wifionly edition but not on the HTC Sensation XE. Does anyone got an Galaxy Tab2 to cross check this behavior?
Try this code for your solution i suppose this will help you.
#Override
public boolean onKeyLongPress(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_CALL) {
// a long press of the call key.
// do our work, returning true to consume it. by
// returning true, the framework knows an action has
// been performed on the long press, so will set the
// canceled flag for the following up event.
return true;
}
return super.onKeyLongPress(keyCode, event);
}
The following Link will lead you to the correct result with other uses of Hard Keys.The link is as follows:-Imp Link
I tested this issue on other samsung tablets. The result is that there is no problem at all. Just the Tablet i am using Samsung Galaxy Tab 2 WiFi 7.0 (P3110) got that issue.
I'm coding an app specifially designed for the blind and vision impaired and I'm trying to override the behavior of TextView when specific AccessibilityEvent are fired. The screen layout consists in 4 TextView arranged vertically that fill the screen. I just want to change the color of the background to reflect which one is "focused" so in my custom TextView I have this method
#Override
public boolean dispatchPopulateAccessibilityEvent(AccessibilityEvent event) {
System.out.println(event.toString());
if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_HOVER_ENTER ||
event.getEventType() == AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUSED) {
this.setBackgroundColor(mColorArray[2]);
}
if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_HOVER_EXIT ||
event.getEventType() == AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUS_CLEARED) {
this.setBackgroundColor(mColorArray[0]);
}
return super.dispatchPopulateAccessibilityEvent(event);
}
My problem is that AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUS_CLEARED is never fired. The three others fire correctly when using ExploreByTouch or swiping left/right up/down.
Any help would be greatly appreciated
If I understood correctly, the accepted answer from this link might solve your problem.
Be careful that if you set your target sdk to 17, there's some extra similar steps to do as described in the comments of the link.
Well I might have read this too fast, it's strange that some are fired and others are not.
I'm currently fighting against the OnLongClickListener on Android Api Lvl 8.
Take this code:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
System.out.println("long click");
return true;
}
});
It works perfectly. I can press anywhere on the WebView and the event triggers every time.
Now take a look at this one:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
final EditText editText = getUrlTextField();
switch (editText.getVisibility()) {
case View.VISIBLE:
editText.setVisibility(View.GONE);
return true;
case View.GONE:
editText.setVisibility(View.VISIBLE);
return true;
default:
return false;
}
}
});
Assuming the URL EditText components is currently visible, it gets gone from the display and should be shown again when another long click event is triggered.
But if you run this, the event just works once (!) when one performs a long click on any position on the WebView. To make things complicated, the long click works again when it is performed on a link on the website...
Can anyone explain if it is a bug in the sdk and/or if there is a mistake in my thinking how the OnLongClickListener is working?!? :/
EDIT:
I've run now several different scenarios on a Nexus One and come to following conclussion: Changing the layout on runtime more or less kills the OnLongClickListener... I haven't found a way to get it work reliably at all...
I would really appreciate if anyone could give me a hint... I'm at my wits end :(
Personnally, I ended up by re-setting the listener after each relayout.
I've run into this issue as well. It seems that if the view layout changes in a way that child view bounds need to be modified (i.e. TextView is wrap_content width and you set its text to something longer/shorter than it was before), views in the hierarchy will have their onStartTemporaryDetach method called (most likely due to a layout pass, although I haven't dug deep enough to find out for sure). If you look at the source for View that onStartTemporaryDetach ultimately unsets the pressed state of the view.
Changing the views in your layout that will be updated periodically to have bounds that will not change regardless of the value you set, will fix the issue. Although, that is still not awesome.