VNC keyboard not removed when server stopped (with solution) about droidvncserver

[oNaiPs]

Thanks for you interest and contribution to the project! I'm not sure if it is safe to put a file on /system, wouldnt work if we simply close the virtual device before closing the daemon? I'm not sure if i'm doing it!

Best

[m-ric]

Q: "wouldnt work if we simply close the virtual device before closing the daemon?"
A: you are already closing the device: close_app() calls cleanupInput(), which calls suinput_close(inputfd). This part is ok.
Problem is that the device is set as built-in, and Android refuses to close built-in devices!
sample of frameworks/base/services/input/InputReader.cpp:

void InputReader::removeDeviceLocked(nsecs_t when, int32_t deviceId) {
    InputDevice* device = NULL;
    ssize_t deviceIndex = mDevices.indexOfKey(deviceId);
    if (deviceIndex >= 0) {
        device = mDevices.valueAt(deviceIndex);
        mDevices.removeItemsAt(deviceIndex, 1);
    } else {
        ALOGW("Ignoring spurious device removed event for deviceId %d.", deviceId);
        return;
    }

    if (device->isIgnored()) {
        ALOGI("Device removed: id=%d, name='%s' (ignored non-input device)",
                device->getId(), device->getName().string());
    } else {
        ALOGI("Device removed: id=%d, name='%s', sources=0x%08x",
                device->getId(), device->getName().string(), device->getSources());
    }

    device->reset(when);
    delete device;
}

Maybe only ICS does that, I don't know. But I don't think there is a safe way to force ICS to close a built-in device. Do you see my point?

A safe solution would be to use a non built-in device for keyboard, thus not using the default qwerty.idc but some other file. Or to force qwerty.idc not to be built-in for the purpose of vnc-server. I don't know how to do this latter...

[oNaiPs]

Thanks for your suggestions... I am as well considering adding support for a second input method, which i think should work in even more devices than uinput brings us (i've heard some comments of not working on some devices)....

That would be to startup the "monkey --port PORT" android cmd that listens on a determined PORT, and injects touch/key events directly on the Java framework... have you acknowledge this already?

best

[m-ric]

I have used the monkey for stress test only, not as a uinput wrapper. Probably worth trying if the execution overhead is acceptable.

[oNaiPs]

I've made some research on this lately. Monkey uses the IWindowManager.aidl Binder interface to inject keys/touch through the WindowManagerService.java. Ideally we should have a AIDL->CPP translator so we could put the daemon injecting keys directly to the service, but we do not have that.

Any thoughs on this? My question would be, is it easier to implement the stubs by hand or adapting the AIDL translator to generate cpp files?

[m-ric]

Sorry for the delay, but to answer your question : I have no idea.

[ADTC]

Facing this problem still on Android 4.4.4 Samsung Galaxy S3 GT-I9305 (a European stock ROM). Is this solution already added in the app? Android still thinks a physical keyboard is present, hence doesn't show virtual keyboard no matter what I try (except restart).

Duplicate issues: #61 #103