Do not call 'setEnabled' before mapper is configured
The mappers have a specific lifecycle:
1. constructor
2. configure(0)
3. reset
4. use it
However, currently, this could be broken because the 'reset' function is
getting invoked before the first configure(0).
If a mapper's 'configure(0)' method isn't called, then there will be
uninitialized variables inside.
Specifically, in TouchInputMapper, this will mean that:
a. mPointerUsage may be set to something like "STYLUS".
b. mPointerSimple::down or mPointerSimple::hovering may be set to true
The above combination could cause a crash, because it would try to
access mPointerController, which isn't yet initialized.
This is a speculative fix, because we can't reproduce the crash, since
it relies on a specific state of the uninitialized variables.
Ideally, we would simply eliminate these possibilities by either using
the constructor (and calling "configure" there), or providing some
default values.
To keep the fix simple, in this CL we just avoid calling 'setEnabled'
too early.
Bug: 255739891
Bug: 255839467
Test: atest inputflinger_tests
Change-Id: I44038c5ce5bfdd5ac4c2933e0dc4fa714c5cf260
diff --git a/services/inputflinger/reader/InputDevice.cpp b/services/inputflinger/reader/InputDevice.cpp
index 5291776..e6ab872 100644
--- a/services/inputflinger/reader/InputDevice.cpp
+++ b/services/inputflinger/reader/InputDevice.cpp
@@ -313,7 +313,10 @@
}
}
- if (!changes || (changes & InputReaderConfiguration::CHANGE_ENABLED_STATE)) {
+ if (changes & InputReaderConfiguration::CHANGE_ENABLED_STATE) {
+ // Do not execute this code on the first configure, because 'setEnabled' would call
+ // InputMapper::reset, and you can't reset a mapper before it has been configured.
+ // The mappers are configured for the first time at the bottom of this function.
auto it = config->disabledDevices.find(mId);
bool enabled = it == config->disabledDevices.end();
out += setEnabled(enabled, when);