Sending Raw events to the framework

[Naseer]

Hi,
I want to be able to get Raw Events of type EV_SW (switches) to my
user space app. Is it possible at all ?

[Dianne Hackborn]

Nope, sorry.  If you are making your own phone, you can implement your own mechanism for doing so (such as publishing the driver as world readable so your app can directly read it, adding an IPC to the process that can read it, etc).

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[Naseer]

Thanks for your reply Dianne. We are working on a phone.
Some other possibilities are to change the KeyEvent class or
modifying WindowManagerPolicy to have an API to push raw events to the
activity (on demand).

On Dec 23, 1:36 am, "Dianne Hackborn" <hack...@android.com> wrote:
> Nope, sorry.  If you are making your own phone, you can implement your own
> mechanism for doing so (such as publishing the driver as world readable so
> your app can directly read it, adding an IPC to the process that can read
> it, etc).
>

> On Mon, Dec 22, 2008 at 10:33 AM, Naseer <naseer.ah...@gmail.com> wrote:
>
> > Hi,
> > I want to be able to get Raw Events of type EV_SW (switches) to my
> > user space app. Is it possible at all ?
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

Please do not change KeyEvent or any of the other platform APIs, unless you do that by submitting a patch that is accepted to the platform.

Also trying to push raw events to the application through WindowManagerPolicy is incredibly intrusive, since you need to dispatch that even all the way from the input reader, through the window manager, to ViewRoot, and down the view hierarchy.

What are you actually trying to do?  What kind of raw events are you trying to dispatch?  Why can't you just have app process read directly from the device?  (If access control is needed, do like is done with sensors where another process opens the device and hands the fd to the app.)

hac...@android.com

[Naseer]

Thanks again for your detailed response.
For example, I want certain apps to know the state of the slider
(type:EV_SW, code: SW_LID) - Currently the WindowManagerPolicy changes
the orientation based on this raw event.
I was hoping this could be sent through the view as a KeyEvent instead
of opening the device separately and polling. On the driver side, our
driver uses the keypad driver to send this event (/dev/input/event0).
Since the fd is already open in EventHub and the event has already
reached the WindowManagerPolicy anyway, I thought I could take it a
bit further and send it to the view.
Opening another fd for just this seems overkill when it could be
treated as a key event sent to the activity.


-Naseer

[Joe Onorato]

A better way to do this would be to change WindowManagerPolicy to update the Configuration differently.  On the G1, it rotates the screen, but on your hardware, that might not make sense.  Change it to just show that the keyboard is exposed.  You want to update the keyboardHidden field on android.content.res.Configuration, but not the orientation field.  The configuration changed broadcasts are the right place to broadcast those state changes, not through key events.  We don't use fake key events to signal state changes.

-joe

[Naseer]

Thank you for the reply Joe. This seems like a good solution for the
slider/orientation case. Hardware manufacturers may want to add more
parameters to this class - for example, there is the headset switch
event and there could be more. Would patches of this sort to be
accepted to this class?

-Naseer

On Dec 27, 7:42 pm, "Joe Onorato" <j...@android.com> wrote:
> A better way to do this would be to change WindowManagerPolicy to update the
> Configuration differently.  On the G1, it rotates the screen, but on your
> hardware, that might not make sense.  Change it to just show that the
> keyboard is exposed.  You want to update the

> keyboardHidden<http://code.google.com/android/reference/android/content/res/Configur...>field

> on android.content.res.Configuration, but not the

> orientation<http://code.google.com/android/reference/android/content/res/Configur...>field.

>  The configuration changed broadcasts are the right place to
> broadcast those state changes, not through key events.  We don't use fake
> key events to signal state changes.
>
> -joe
>

[Joe Onorato]

I think we'd be interested in patches along this line.  What do you mean by the headset switch event?  Is that the hang up button?  If so, in that case, we do have a key event for it.  http://code.google.com/android/reference/android/view/KeyEvent.html#KEYCODE_HEADSETHOOK

Regardless of how they're implemented in the driver -- the basic theory is that if it's a momentary button, like keys or things that are obviously buttons, then we treat them as keys.  But if it's a latch, like whether the keyboard is opened or not, then we try to find some other mechanism for it.  The problem is that there's no good reliable way for an app to always get all of the events to manage their state.  I'm not sure how we'd implement something like a silent mode switch.  My instinct would be to handle it entirely in WindowManagerPolicy, and not even try to send the events to the app.

-joe

[Dianne Hackborn]

There isn't one, always appropriate, solution we can give you.  The approach you take depends very much on your exact situation, along a number of dimensions:

(1) Is this something that you would like to have incorporated into the base platform, so will be contributing patches for it?  If so, then it may make sense to add it to the Configuration class; if not, I would strongly discourage this since there are a lot of repercussions to doing this.  In fact, for the same reasons, I would generally discourage this unless it really makes sense: everything in Configuration impacts resources, so anything you add there also needs to be correctly propagated into the resource compiler, the resource selection code, the bit field for apps to select which configuration change values they handle, and elsewhere.  If it is not especially worth allowing resource values to change based on it, going to the trouble of adding this state to Configuration is not something that should be done.

(2) Is this just a new kind of key event, which only the currently focused application would care about receiving?  If so, it may make sense to just define a new key code and dispatching.  Doing so will, however, require submitting a patch to the base project that adds this keycode, but that is fairly trivial.  Optionally you may want to add default handling of the key in PhoneWindow to start an activity with a new Intent action (I suggest not doing a broadcast here, though some of the existing default key stuff does use broadcasts, it doesn't let the user go through the normal process of selecting one of multiple possible applications to perform the action.)

(3) Is this some general change in state?  Flipping the lid or a silent switch are probably examples of this.  In this case you will probably do some work in PhoneWindowManager to handle the new event, and if needed expose this to any interested applications in some higher-level way.  For example, a silent switch might be handled in PhoneWindowManager by setting the volume of all media channels to 0, and also send a broadcast (perhaps a sticky broadcast) that any interested apps could receive.

Note that for the case you are talking about of the state of the slider, to me it really doesn't make sense to expose this as a key event -- the raw event itself after all is not a key event, it is a switch, which is a very different thing.  Adding a sticky broadcast for this would certainly make sense, though if you want something in the base platform we should really talk about what this is: without knowing the exact hardware, what does the "slider" being open or closed -mean-?  What could an application do with this that would not be tied to a particular hardware configuration?  This is one of the reasons why we don't expose to applications the raw state of the G1 lid, but rather the repercussions of that changing (the keyboard being exposed, the orientation being changed).

hac...@android.com

[Naseer]

Dianne and Joe - Thank you for the detailed and informative replies.

[Naseer]

Hi Dianne and Joe,
We saw that in cupcake this issue has been taken care of with the
slider state is exposed with the hardKeyboardHidden flag.
Now we need to add a configuration value for the dock switch. End
applications can modify their behavior based on the dock state and we
think this needs to be in the base framework.
We need to know which of the above methods you will accept as a patch
from us, we are inclining to make the changes in the Configuration
class.

Thanks,
-Naseer



On Dec 29 2008, 11:11 am, "Dianne Hackborn" <hack...@android.com>
wrote:

[Dianne Hackborn]

You may be misunderstanding that change -- all that happened there is that hardKeyboardHidden now has the same value has keyboardHidden used to, because keyboardHidden is now always true if there is a soft keyboard available.

As far as adding new values to Configuration, keep in mind that doing so requires all of the following:

- Updating ResourcesTypes.h to define the new configuration value, and perform the correct matching when looking for resources.
- Modifying aapt to parse the new configuration names out of directory paths and setting the resource configuration value appropriately, along with all of the related code in aapt for dealing with configurations.
- Extending the Resources JNI bridge to include this new value when setting the configuration, and passing it through in the various places where the framework calls it.
- Adding a new flag for android:configChanges for activities to say they do not want to be restarted when this configuration changes.
- Implementing the code to detect when the value changes between two Configuration objects, and setting the new flag you have defined.

Honestly, I don't think a "docked" state belongs at the level of a Configuration.

How about just doing this as a broadcast?

hac...@android.com

[Naseer]

Thanks for your reply Dianne.

Wow - I did not realize that it would be so much work to change
Configuration.
We will look into broadcasting a sticky intent.

Thanks,
-Naseer

On Feb 14, 7:03 am, Dianne Hackborn <hack...@android.com> wrote:
> You may be misunderstanding that change -- all that happened there is that
> hardKeyboardHidden now has the same value has keyboardHidden used to,
> because keyboardHidden is now always true if there is a soft keyboard
> available.
>
> As far as adding new values to Configuration, keep in mind that doing so
> requires all of the following:
>
> - Updating ResourcesTypes.h to define the new configuration value, and
> perform the correct matching when looking for resources.
> - Modifying aapt to parse the new configuration names out of directory paths
> and setting the resource configuration value appropriately, along with all
> of the related code in aapt for dealing with configurations.
> - Extending the Resources JNI bridge to include this new value when setting
> the configuration, and passing it through in the various places where the
> framework calls it.
> - Adding a new flag for android:configChanges for activities to say they do
> not want to be restarted when this configuration changes.
> - Implementing the code to detect when the value changes between two
> Configuration objects, and setting the new flag you have defined.
>
> Honestly, I don't think a "docked" state belongs at the level of a
> Configuration.
>
> How about just doing this as a broadcast?
>

> ...
>
> read more »

[Dianne Hackborn]

On Fri, Feb 13, 2009 at 9:12 PM, Naseer <naseer...@gmail.com> wrote:

Wow - I did  not realize that it would be so much work to change
Configuration.

Well configurations are pretty fundamental so have far-reaching repercussions. :)

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[Naseer]

Hi Dianne,
I am sending the sticky broadcast for the dock in PhoneWindowManager's
adjustConfigurationLw function (same place where Configuration for
slider is changed)
However I am getting the same sticky broadcast twice. Logging in
adjustConfigurationLw shows that the broadcast is sent once, but
onReceive in my BroadcastReceiver logs the intent twice
.
Also reading another thread of yours (http://groups.google.com/group/
android-developers/browse_thread/thread/f37e3549a5e1be66/
fe16369a5894a7c5) I see that you generally disapprove of using sticky
broadcasts and that they could be deprecated. Can you clarify if this
is something that will be deprecated or will it remain available (at
least to the device manufacturers ? )


Thanks,
-Naseer



On Feb 15, 1:07 am, Dianne Hackborn <hack...@android.com> wrote:

> On Fri, Feb 13, 2009 at 9:12 PM, Naseer <naseer.ah...@gmail.com> wrote:
> > Wow - I did  not realize that it would be so much work to change
> > Configuration.
>
> Well configurations are pretty fundamental so have far-reaching
> repercussions. :)
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

Sticky broadcasts from the platform are okay.

You should sent the broadcast when you get the raw event, not every time the configuration is adjusted.  This stuff shouldn't be part of the configuration at all.

hac...@android.com

[Naseer]

Thanks, I'll do this in the preprocess event function.
Another question - media button and camera events are broadcast as
extra key events in the intent. However, dock is not a key event.
Right now I have made an ACTION_DOCK_EVENT intent and sent the state
in it as an extra boolean. Where do I define this extra event ? It
does not seem that it should be a key event, a boolean would be fine.
Can I add this in the Intent class itself or maybe Context ?

Sorry to keep bothering you, but we worry about our changes not
getting accepted back to the platform and minimizing our rework.

Thanks,
-Naseer

On Feb 19, 11:55 pm, Dianne Hackborn <hack...@android.com> wrote:
> Sticky broadcasts from the platform are okay.
>
> You should sent the broadcast when you get the raw event, not every time the
> configuration is adjusted.  This stuff shouldn't be part of the
> configuration at all.
>
>
>
> On Thu, Feb 19, 2009 at 4:32 AM, Naseer <naseer.ah...@gmail.com> wrote:
>
> > Hi Dianne,
> > I am sending the sticky broadcast for the dock in PhoneWindowManager's
> > adjustConfigurationLw function (same place where Configuration for
> > slider is changed)
> > However I am getting the same sticky broadcast twice. Logging in
> > adjustConfigurationLw  shows that the broadcast is sent once, but
> > onReceive in my BroadcastReceiver logs the intent twice
> > .
> > Also reading another thread of yours (http://groups.google.com/group/
> > android-developers/browse_thread/thread/f37e3549a5e1be66/

> > fe16369a5894a7c5<http://groups.google.com/group/%0Aandroid-developers/browse_thread/th...>)

[Dianne Hackborn]

You can just define an EXTRA_DOCK_STATE at the same place where you define ACTION_DOCK_EVENT.  Having it just be a boolean seems completely reasonable, since there is no high-level event associated with it.

hac...@android.com

[Joe Onorato]

On Thu, Feb 19, 2009 at 11:57 AM, Naseer <naseer...@gmail.com> wrote:

Thanks, I'll do this in the preprocess event function.

Hi.  The best place to put this is actually PhoneWindowManager.interceptKeyTi.  preprocessEvent doesn't have any other policy stuff there except the screen on-off stuff.  preprocessEvent and interceptKeyTq are also running in the key input queue thread, which it'd be better not to put as much stuff into. 

In the WindowManagerPolicy functions, the Ti suffix means it's called from the "input thread" in the window manager, " and Tq means that it's called from the queue thread that reads directly out of the driver.  The queue thread needs to remain responsive, otherwise the ANR handling won't happen.  The input thread is more flexible.

-joe




 

[Naseer]

Thanks Dianne and Joe for your quick response.
Joe - would you suggest putting the stickyBroadcast in a separate
runnable as is done for .ACTION_MEDIA_BUTTON in the same class ?


On Feb 20, 1:04 am, Joe Onorato <j...@android.com> wrote:

[Naseer]

Thanks Dianne and Joe for your quick response.
Joe - would you suggest putting the stickyBroadcast in a separate
runnable as is done for .ACTION_MEDIA_BUTTON in the same class ?


On Feb 20, 1:04 am, Joe Onorato <j...@android.com> wrote:

[Dianne Hackborn]

Nope there shouldn't be any need for that.  Just do the broadcast when you get the event.

hac...@android.com

[Joe Onorato]

What Dianne said.  IIRC, the runnable there is to handle long press for the ACTION_MEDIA_BUTTON.

-joe

[naseer]

PhoneWindowManager.interceptKeyTi does not get a raw event. Dock
events are raw input events of type EV_SW. Hence I am back to using
preprocessInputEventTq.
I am also sending it in readDockState (which is the same as
readLidState) if the previous state is different.

Thanks,
-Naseer

On Feb 20, 2:27 am, Joe Onorato <j...@android.com> wrote:
> What Dianne said.  IIRC, the runnable there is to handle long press for the
> ACTION_MEDIA_BUTTON.
>
> -joe
>

> On Thu, Feb 19, 2009 at 1:06 PM, Dianne Hackborn <hack...@android.com>wrote:
>
> > Nope there shouldn't be any need for that.  Just do the broadcast when you
> > get the event.
>

[Naseer]

Hi Dianne and Joe,
As per our previous discussion I used a sticky broadcast for the dock
state.
However, at the receiver end I am getting the intent twice

Here are the relevant code snippets and logs. You can see that Dock
State:1 received is printed twice.

Broadcast -
----------------------------------------------------------------------------------------------------------
mDockIntent.putExtra(Intent.EXTRA_DOCK_STATE, DOCKED_DESK);
mContext.sendStickyBroadcast(mDockIntent);
Log.d(TAG, "Dock State Broadcast : DOCKED_DESK: "+DOCKED_DESK);
----------------------------------------------------------------------------------------------------------

Receiver -

BroadcastReceiver dockBroadcastReceiver = new BroadcastReceiver
(){
@Override
public void onReceive(Context context, Intent intent) {
String intentAction = intent.getAction();
if (intentAction.equals(DOCK_EVENT)) {
int extra = intent.getIntExtra(DOCK_EXTRA, 0);
Log.d("DEBUG", "Dock State:"+extra+" received");
mTextView.setText("Dock State:"+extra+"
received");
}
}
};

----------------------------------------------------------------------------------------------------------
Resulting log -

D/WindowManager( 53): Dock State Broadcast : DOCKED_DESK: 1
D/DEBUG ( 280): Dock State:1 received
I/WindowManager( 53): Input configuration changed: { scale=1.0
imsi=0/0 locale=en_US touch=3 key=2/1/2 nav=3 orien=2 }
D/KeyguardViewMediator( 53): pokeWakelock(10000)
V/ActivityThread( 280): Resuming ActivityRecord{436f7240
token=android.os.BinderProxy@436f6d28 {com.somecompany.docktest/
com.somecompany.docktest.DockTest}} with isForward=true
D/DEBUG ( 280): Dock State:1 received
D/StatusBar( 53): updateResources
D/dalvikvm( 53): GC freed 1029 objects / 46408 bytes in 95ms

----------------------------------------------------------------------------------------------------------

On Feb 20, 6:12 pm, naseer <naseer.ah...@gmail.com> wrote:
> PhoneWindowManager.interceptKeyTi does not get a raw event. Dock
> events are raw input events of type EV_SW. Hence I am back to using
> preprocessInputEventTq.
> I am also sending it in readDockState (which is the same as
> readLidState) if the previous state is different.
>
> Thanks,
> -Naseer
>
> On Feb 20, 2:27 am, Joe Onorato <j...@android.com> wrote:
>
> > What Dianne said.  IIRC, the runnable there is to handle long press for the
> > ACTION_MEDIA_BUTTON.
>
> > -joe
>
> > On Thu, Feb 19, 2009 at 1:06 PM, Dianne Hackborn <hack...@android.com>wrote:
>
> > > Nope there shouldn't be any need for that.  Just do the broadcast when you
> > > get the event.
>

> > > On Thu, Feb 19, 2009 at 12:19 PM,Naseer<naseer.ah...@gmail.com> wrote:
>
> > >> Thanks Dianne and Joe for your quick response.
> > >> Joe - would you suggest putting the stickyBroadcast in a separate
> > >> runnable as is done for .ACTION_MEDIA_BUTTON in the same class ?
>
> > >> On Feb 20, 1:04 am, Joe Onorato <j...@android.com> wrote:

> > >> > On Thu, Feb 19, 2009 at 11:57 AM,Naseer<naseer.ah...@gmail.com>

> > >> > > > On Thu, Feb 19, 2009 at 4:32 AM,Naseer<naseer.ah...@gmail.com>

> > >> > > > > > On Fri, Feb 13, 2009 at 9:12 PM,Naseer<naseer.ah...@gmail.com

[Dianne Hackborn]

I have never seen this in the multitude of broadcasts, so I would assume it is something in your code, though there isn't really enough to tell.  Note that for sticky broadcasts you will receive the broadcast each time you register for it, so if you are registering a second time (such as due to an activity being restarted from a config change) you will receive it again.

hac...@android.com

[Naseer]

That explains it ..
The orientation of the screen changes on docking (We have a landscape
dock)

Thanks Dianne :)

-Naseer