This factors out the boiler-plate code from the sample app to a common glue code that can be used for everyone writing this style of app: a dedicated app thread that takes care of waiting for events and processing them. As part of doing this, ALooper has a new facility to allow registration of fds that cause ALooper_pollOnce() to return the fd that has data, allowing the app to drive the loop without callbacks. Hopefully this makes some people feel better. :) Also do some other cleanup of the ALooper API, plus some actual documentation. Change-Id: Ic53bd56bdf627e3ba28a3c093faa06a92be522b8
19 lines
352 B
Makefile
19 lines
352 B
Makefile
BASE_PATH := $(call my-dir)
|
|
LOCAL_PATH:= $(call my-dir)
|
|
|
|
include $(CLEAR_VARS)
|
|
|
|
# our source files
|
|
#
|
|
LOCAL_SRC_FILES:= \
|
|
threaded_app.c
|
|
|
|
LOCAL_C_INCLUDES += \
|
|
frameworks/base/native/include \
|
|
frameworks/base/core/jni/android \
|
|
dalvik/libnativehelper/include/nativehelper
|
|
|
|
LOCAL_MODULE:= libthreaded_app
|
|
|
|
include $(BUILD_STATIC_LIBRARY)
|