as of today, audio policy manager determines where to route audio.
we did similar exercise on surface flinger to support multiple display
panels => modify surface flinger to be aware of multiple displays and apps
to use specific display if desired (say video playback on TV, while regular
GUI on lc
when u talk about android kernel => only board support patches are required
to make it work on a platform.
note: for kernel.org linus's kernel tree => u need android patchset and your
platform patches.
> I was just wondering if someone could explain to me the actual need of
patching the Android ke
each application can create a sensor listener and configure the frequency (
SENSOR_DELAY_UI,SENSOR_DELAY_NORMAL,SENSOR_DELAY_GAME,SENSOR_DELAY_FASTEST)
you can refer how froyo videoplayer app uses this
http://git.omapzoom.org/?p=platform/packages/apps/Gallery3D.git;a=blob;f=src/com/cooliris/media/R
Hi,
I am in a situation where too many RIL_REQUEST_DATA_CALL_SETUP
failures are there per hour and this results in one of the IOT test
failure.
How can one control that there should not be more than n requests per
hour for setting pdp context? Is it possible to control?
Regards,
Hvr
--
unsubsc
Hi Hamilton:
"as far as I know the behavior should be the same no matter
what bootloader you are using."
Yes! I definitely agree.
And yes, I also tried to find the answer from the MX51 data
Sheet(MCIMX51RM.pdf), but actually, I think the datasheet does NOT make
things clearly.
Ther
