8c6cedc9bc
This is a very simply implementation: upon receiving an IPC, if the handling thread is at a background priority (the driver will have taken care of propagating this from the calling thread), then stick it in to the background scheduling group. Plus an API to turn this off for the process, which is used by the system process. This also pulls some of the code for managing scheduling classes out of the Process JNI wrappers and in to some convenience methods in thread.h. |
||
---|---|---|
.. | ||
Android.mk | ||
Asset.cpp | ||
AssetDir.cpp | ||
AssetManager.cpp | ||
BackupData.cpp | ||
BackupHelpers.cpp | ||
BufferedTextOutput.cpp | ||
CallStack.cpp | ||
CharacterData.h | ||
Debug.cpp | ||
FileMap.cpp | ||
misc.cpp | ||
MODULE_LICENSE_APACHE2 | ||
NOTICE | ||
README | ||
RefBase.cpp | ||
ResourceTypes.cpp | ||
SharedBuffer.cpp | ||
Static.cpp | ||
StopWatch.cpp | ||
String8.cpp | ||
String16.cpp | ||
StringArray.cpp | ||
SystemClock.cpp | ||
TextOutput.cpp | ||
Threads.cpp | ||
Timers.cpp | ||
Unicode.cpp | ||
VectorImpl.cpp | ||
ZipFileCRO.cpp | ||
ZipFileRO.cpp | ||
ZipUtils.cpp |
Android Utility Function Library If you need a feature that is native to Linux but not present on other platforms, construct a platform-dependent implementation that shares the Linux interface. That way the actual device runs as "light" as possible. If that isn't feasible, create a system-independent interface and hide the details. The ultimate goal is *not* to create a super-duper platform abstraction layer. The goal is to provide an optimized solution for Linux with reasonable implementations for other platforms.