IssueTracker

I have the same issue. The floating toolbar keeps on stealing the focus. You can mouse click on text area but keyboard input wont work. Sometimes i can get the emulator to get the focus but it is so random. Sometimes clocing both left and mouse button on the emulator would fix it.


OS:
Xubuntu 15.10

I have the same issue.

Clicking on the window title bar of the "device window" does not move the focus to the device but to the control button toolbar. I am unable to move the focus to the device via any other means (task bar or Alt-Tab etc.).
The workaround described by remcohaszing works, but I have to do this everytime after the device lost the focus, which is quite often, when developing.
So it's a real show stopper for me.

The only practical workaround I found is to set "focus on mouse over" instead of "focus on click" (which I don't like otherwise).
But even in this mode, when I move the mouse over the title bar (not the window contents) for the first time after the device lost it's focus by a *click* on another window, the toolbar gets the focus instead.

It works when I move the mouse to the title bar a second time *and* as long as I do not *click* somewhere outside the device window. Tabbing away is also like clicking.

So where is the difference between loosing the focus by click or tab against moveing the mouse?

My system is a current debian testing/unstable mix using xfce4 with xfwm4.

I have narrowed the issue to using xfwm4 (I usually use 4.12.x and also tried 4.10.x).
I changed any corresponding options like "focus stealing prevention" and "honour ICCCM focus hint" and even disabled compositing, but all this doesn't matter.

I then tried several alternate window managers and they all worked including clicking, tabbing etc.:
openbox
fluxbox
jwm
lwm

I still don't blame xfwm4 alone, because I never ever had any other focus issue with xfwm4 since several generations. So I believe it's a combination of emulator's behaviour *and* xfwm4's behaviour.

Another hint: when I click on the avd and then on another window e.g. a shell window and then close this focused window, the emulator device gets the focus.

... so a simple launcher like "xterm -e exit" allows to give the focus back to the emulator device.

While testing window managers etc. I somehow managed to get rid of the control buttons toolbar window (may be it was on another workspace, or closed by someone). Then the device window worked well apart from the missing buttons.

I also tried with wmctrl:

wmctrl -i -a 0x06200003
wmctrl -i -R 0x06200003
  with the hex number being the Android Emulator window (=device)
  both remove the focus from my shell window, but the device window doesn't get it
  (as usual the button bar gets the focus)

t=0.1; w=0x06200003; for s in modal sticky maximized_vert maximized_horz skip_taskbar skip_pager hidden fullscreen above below; do echo $s; wmctrl -i -r $w -b toggle,$s; sleep $t; wmctrl -i -a $w; sleep $t; wmctrl -i -r $w -b toggle,$s; sleep $t; wmctrl -i -a $w; sleep $t; done
  doesn't move focus to the device

but...

t=0.0; t2=0.5; w=0x06200003; s=shaded; echo $s; while true; do wmctrl -i -r $w -b remove,$s; sleep $t; wmctrl -i -a $w; sleep $t; sleep $t2; wmctrl -i -r $w -b add,$s; sleep $t2; wmctrl -i -a $w; sleep $t; wmctrl -i -r $w -b remove,$s; sleep 3; done
  moves the focus to the device every other time

Generally the focus works, when the device window is in shaded mode ("rolled up").
This even works when selecting the mode via window menu and then clicking on the title or on the task bar entry.
In this mode the toolbar doesn't come to front either.

if the device window has the focus and it's moved via mouse and title bar, it looses focus.

Over all, something like a setFocus-event seems to be used to explicitly set the focus to the toolbar.

Thinking about that, it seems to be a conflict situation.
Some keys should go to the toolbar and some should go to the device.
I think, the natural way to handle that would be:
the toolbar gets all keys (so it has the focus all the time).
Keys not used by the toolbar should then be forwarded to the device window.

I also don't really understand, why there are two windows which are strictly glued together. Two windows would make sense, if they can be moved independently (at least sometimes) or may be the offset would be adjustable. But when I move the toolbar by Alt-Mouse window movement, it always jumps back to the device window when I move that.

btw. my emulator version is 25.2.2-3098464 (Stable update channel)

is there a newer version for testing?

For those facing this, it is relatively easy to substitute Metacity for xfwm4 as the window manager for Xfce4 (on Debian): download the metacity package, and run "metacity --replace".  The emulator keyboard immediately works again.  However, it's not a satisfactory fix: window manager xfwm4 UI tools stop working, window behavior is slightly different (e.g. snap behavior), and for me, XRDP broke.  Pity to have to deal with all this because of what may be a relatively minor bug. Please consider fixing soon. Thanks in advance.

Xubuntu is using an unsupported windows & desktop manager...we can look into the issue, but by default, we test and support Ubuntu running GNOME or KDE.

I am having the same issue on Arch Linux x64, also running with XFCE4 and XFWM4

Hello,

I created my own solution to solve this.
Place this "win.class" in home folder and make new shortcut with
"java win" assign some key with this for example Alt+z.

To assign keyboard shortcut In peppermint os, from "Menu->Preference->Pappermint Control Center->Keyboard Shortcut"

Now in emulator to gain focus press Alt+z now AVD gets focus and do your work :)

Idea behind:
Simply open an another window and close it immediately so new window gains focus and on immediately closing that new window make your AVD focusable now keyboard works fine.

https://stackoverflow.com/a/42720450/120398 describes how to adjust the Window Manager so that focus follows the mouse, and that resolves this issue (if you're happy to have your window manager do that)

I get this also in xfce4, I use this in devilspie2:
```
if (get_application_name() == "Emulator") then
    set_window_opacity(0.6)
    set_skip_pager(true)
    set_window_type("_NET_WM_WINDOW_TYPE_SPLASH")
end
```
I tried all the windows "types" - the one above is the only one that makes it behave as should without side effects (noticeable to me anyway - I only use keyboard for nav, so don't know about other styles; win-lists and such)
Above is a cut out and reduced bit from my full setup — not tested. The `set_window_type` is the only important one for this case.

With new version of the emulator [27.2.9] I can not get it to focus no matter what.
The https://stackoverflow.com/a/42720450/120398 answer is no longer valid.
Does anyone at Google is reading this? This bug stands out for years, now the emulator is barely usable on lighter distros.

I have same issue on openSUSE Leap 42.3 and Xfce 4.12

Still an issue two years later.

Seeing it on Fedora 28 and Ubuntu 18.04 both with XFCE.

A different window manager works (e.g. OpenBox) but -

- No focus issues with any other app
- Don't understand "Xubuntu is using an unsupported windows & desktop manager" above - XUbuntu uses XFCE and it's not "unsupported" (???). Fedora can run XFCE too.
- Overall XFCE is one of major Linux desktop environments

It should not be too difficult for Google to install XFCE if you already have Linux installed, and then it should be easy to reproduce and hopefully fix.

Please please please. Not being able to use the keyboard is a major pain.

This is also affecting me, on Xubuntu 18.10 (using XFCE) using latest Emulator canary 28.1.0-5201539.

A work-around that seems to be working for me is to open Window Manager Tweaks: Focus tab > When a window raises itself > Do nothing. Once that setting is chosen, the main emulator window title bar remains active after you click in it and the app running in the emulator gets keypresses.

This lines up with some of the other comments, suggesting the problem is related to the emulator toolbox window requesting focus or being raised unnecessarily. Before changing the above setting (when the problem is occurring), when I click on the main emulator window I see the title bar of the emulator window flash active for a very short time. This is hard to see on the default Xubuntu window manage style, where title bar active/not-active are very similar colors, so it helps to pick window manager style "Moheli". Based on this, it appears that the emulator window is activated by the click, then very shortly later looses focus.

Work-around by lu...@ozrunways.com working for me but need have checked "Window Manager Tweaks: Focus tab > Activate focus stealing prevention" together with "Window Manager Tweaks: Focus tab > When a window raises itself > Do nothing"

openSUSE Leap 42.3 and Xfce 4.12 emuilator version 27.3.10-4969155

A simpler workaround that I've found is to click the emulator window / title bar like so:

1. Press and hold right mouse button.
2. Press and hold left mouse button.
3. Release right mouse button.
4. Release left mouse button.

At this point, the emulator window is properly focused.  If this doesn't work, try swapping the order in which you hold and release the mouse buttons.

This has the advantage that you don't have to change any window manager settings, which could negatively impact your workflow with other programs.

Isn't it possible for someone from Google to do "apt-get install xfce4-desktop" and then reproduce and actually fix the bug???

Project: platform/external/qemu
Branch: emu-master-dev

commit c2f3545758cbd66a8e99e52bcaa8977c6ba52ed6
Author: Joshua Duong <joshuaduong@google.com>
Date:   Thu Apr 11 14:57:54 2019

    Fix XFCE keyboard issue.
   
    We should never raise the tool window. we either give the keyboard
    focus to the emulator container or the extended window. Not calling
    parent class's raise() will never let the tool window gain focus, which
    is desired.
   
    BUG: b/73261949, b/37094173
   
    Test: For all of the below scenarios, the emulator should still receive
    keyboard events and not shut down. This bug also had focus on the close
    button of the tool window, so if you hit Space, it would close the
    emulator, so make sure to include the Space key when testing:
    1) Boot emulator, type some characters, including space.
    2) Click somewhere on the tool window, then type.
    3) Open the extended window, then click on the emulator window, then
    type.
    4) Open/click the extended window, then click on the tool window, then
    type
    5) Minimize the emulator, then unminimize, then type
    6) Bring another window (anything unassociated with emulator to the
    front, then click on the emulator/tool-window to bring it back to the
    front. Then type.
    7) Resize the emulator, then type.
   
    Change-Id: I9cdeb370a5201e9b35ef639a36262eec951efd82

M       android/android-emu/android/skin/qt/tool-window.cpp

https://android-review.googlesource.com/943759
https://goto.google.com/android-sha1/c2f3545758cbd66a8e99e52bcaa8977c6ba52ed6

Ammdsa1333zzz@gmail. Com