There was a regression caused by a change in Honeycomb that removed
mediaserver process from system group to improve security: This prevents
the audio HAL (which runs in mediaserver process) from taking wake locks
while audio is playing thus causing the pcm stream to get unexpectedly
suspended.
This temporary workaround is just to allow ICS dogfood in better conditions until
a real fix taking into account the security issue is implemented.
Change-Id: Ic19a23da4b4383559188b6f5c3a82604c3d95d74
Fixed a bug printing the event value when using labels.
Stop trying to print the available codes for EV_SYN because
we cannot actually query them. EVIOCGBIT(0, size) is a special
case that returns the set of events that are supported, and
EV_SYN == 0.
Change-Id: Iea086ba24300ca0815e4814a3bc5ff60756612c2
By overriding the netlink cache pointer, able to pass nl80211 family id.
Scan and connecting open access point work
Added legal stuff to headers
Change-Id: I1c60452f35fdd1f80edebc03fef33067722d0543
* changes:
Workaround Motorola ril.so incompatiblity with Netlink changes
Cleanup NetlinkListener and NetlinkEvent
Revert "Revert "Add NETLINK_ROUTE processing to the netlink client code, so that Ethernet""
-- This is needed so the modems (LTE & CDMA) are powered on and running
before unlocking encrypted devices
Change-Id: I842f5286499fd76abc554ded550fb837d12b324e
To workaround a binary incompatiblity with Motorola's ril.so, I had to
temporarily provide the old constructor for NetlinkListener as well as
a new contructor that takes an additional format argument.
There's still a slight chance of a problem because the size of the
NetlinkListener has changed with the addition of the
mFormat member, but so far I've not seen any obvious problem with that
incompatiblity.
Another way we could have worked around the incompatiblity is to have
netd (the main user of the new format argument to NetlinkListener) keep
track of the format itself in it's NetlinkHandler (derived from NetlinkListener)
and supply it's own version of onDataAvailable() that's almost 100% identical
to NetlinkListener's except for the decode() call. That would allow us
not to modify NetlinkListener at all. Worth considering but I think it's
more properly divided right now and we just have to make Motorola fix their
code (and ideally not use our private APIs).
This change should be reverted when Motorola's has fixed their ril to
either not use our private APIs or to use our updated ones.
Change-Id: I255cca6908444e56cbbbed7eef1fa0cf1d8f0918
Signed-off-by: Mike J. Chen <mjchen@google.com>
To make it easier to be compatible with older existing code, use
default parameters instead of separate functions for setting.
Also, reintroduce the const usage that was not in the original
changes by Stan.
Also fix some indent spacing.
Change-Id: Ice9ec7f0d5c4a0673037e2e04a764d88a98f68eb
Signed-off-by: Mike J. Chen <mjchen@google.com>
This reverts commit 1d504eeb50.
Conflicts:
libsysutils/src/NetlinkEvent.cpp
Bring back the changes from Stan Chesnutt regarding adding NETLINK_ROUTE
processing. The original commit message description was:
Add NETLINK_ROUTE processing to the netlink client code, so that Ethernet
physical-layer up/down events can be tracked. Upper layers will use these
events to enable/disable Ethernet connectivity.
The original change was reverted due to an incompatiblity with Motorola's
ril.so binary. I'll submit a patch to workaround that incompatiblity
separately.
Change-Id: I4e97ac98833b10543e654c63ecae3b9b8c7db44f
Signed-off-by: Mike J. Chen <mjchen@google.com>
Introduces new "net_bw_stats" group which will protect reading
detailed bandwidth statistics. Also introduce "net_bw_acct" group
which will enable specific applications to request that their network
traffic be counted against other UIDs.
Change-Id: Ic0ec04e0d2bb9573f3c2a094ebd6d6a8cae0aae6
The adb gadget driver used to reset the USB bus when the adbd daemon exited,
and the host side adb relied on this behavior to force it to reconnect
with the new adbd instance after init relaunches it. The new gadget
drivers no longer automatically reset the USB bus when adbd is restarted
which caused adb to hang since it was no longer forced to reconnect with the
device. We attempted to work around this on the host side adb, but that
work around has not been reliable.
This change adds a property trigger on the service.adb.root system property
which will reset the USB bus and restart the adbd daemon when adbd sets
the property to 1. This should be much closer to the previous behavior
and will hopefully fix some problems with automated testing.
Change-Id: I177c37400009a3d83f21a5f9431f94fd1cc19b9b
Signed-off-by: Mike Lockwood <lockwood@android.com>
This reverts commit d15e6ac95d.
Also increment adb version to 1.0.29
Change-Id: I890643f0c18a2fe90f170134df039c54116cecda
Signed-off-by: Mike Lockwood <lockwood@android.com>
The buggy behavior was that the 'adb backup ....' host command line
invocation would hang forever, even after the backup finished and
the forked device-side subprocess had been reaped. The reason for
this is that the device adbd end of the socketpair used to send
the data back from the forked subprocess was still stuck readable
even after the remote end of it had been closed.
With this patch, the thread whose job it is to waitpid() in order
to harvest the forked child process also closes the local (adbd)
end of the socketpair. This makes the fdevent logic notice that
the socket is dead, at which point it cleans up everything including
the communication back to the host.
Change-Id: I90e7e4e5db36c5a6f7363708b29a6d2c56d1250e
* Increase transfer buffer size to 32K
* Add logging about error conditions and fd teardown
* Pass the fd number as a command line option to the 'bu' subprocess
* Properly harvest the 'bu' subprocess after it's done
Change-Id: Id44dde25778ecf43c5604fd9d01d726ba58861e5
