BoardConfig.mk revision 5abaa4eead07ffcc844b370d6f2c558169f89f95 
1# config.mk
2#
3# Product-specific compile-time definitions.
4#
5
6# The generic product target doesn't have any hardware-specific pieces.
7TARGET_NO_BOOTLOADER := true
8TARGET_NO_KERNEL := true
9TARGET_ARCH := arm
10
11# Note: we build the platform images for ARMv7-A _without_ NEON.
12#
13# Technically, the emulator supports ARMv7-A _and_ NEON instructions, but
14# emulated NEON code paths typically ends up 2x slower than the normal C code
15# it is supposed to replace (unlike on real devices where it is 2x to 3x
16# faster).
17#
18# What this means is that the platform image will not use NEON code paths
19# that are slower to emulate. On the other hand, it is possible to emulate
20# application code generated with the NDK that uses NEON in the emulator.
21#
22TARGET_ARCH_VARIANT := armv7-a
23TARGET_CPU_VARIANT := generic
24TARGET_CPU_ABI := armeabi-v7a
25TARGET_CPU_ABI2 := armeabi
26
27HAVE_HTC_AUDIO_DRIVER := true
28BOARD_USES_GENERIC_AUDIO := true
29
30# no hardware camera
31USE_CAMERA_STUB := true
32
33# Enable dex-preoptimization to speed up the first boot sequence
34# of an SDK AVD. Note that this operation only works on Linux for now
35ifeq ($(HOST_OS),linux)
36  ifeq ($(WITH_DEXPREOPT),)
37    WITH_DEXPREOPT := true
38  endif
39endif
40
41WPA_SUPPLICANT_VERSION := VER_0_8_X
42
43# Build OpenGLES emulation guest and host libraries
44BUILD_EMULATOR_OPENGL := true
45
46# Build and enable the OpenGL ES View renderer. When running on the emulator,
47# the GLES renderer disables itself if host GL acceleration isn't available.
48USE_OPENGL_RENDERER := true
49
50# Set the phase offset of the system's vsync event relative to the hardware
51# vsync. The system's vsync event drives Choreographer and SurfaceFlinger's
52# rendering. This value is the number of nanoseconds after the hardware vsync
53# that the system vsync event will occur.
54#
55# This phase offset allows adjustment of the minimum latency from application
56# wake-up (by Choregographer) time to the time at which the resulting window
57# image is displayed.  This value may be either positive (after the HW vsync)
58# or negative (before the HW vsync).  Setting it to 0 will result in a
59# minimum latency of two vsync periods because the app and SurfaceFlinger
60# will run just after the HW vsync.  Setting it to a positive number will
61# result in the minimum latency being:
62#
63#     (2 * VSYNC_PERIOD - (vsyncPhaseOffsetNs % VSYNC_PERIOD))
64#
65# Note that reducing this latency makes it more likely for the applications
66# to not have their window content image ready in time.  When this happens
67# the latency will end up being an additional vsync period, and animations
68# will hiccup.  Therefore, this latency should be tuned somewhat
69# conservatively (or at least with awareness of the trade-off being made).
70VSYNC_EVENT_PHASE_OFFSET_NS := 0
71
72TARGET_USERIMAGES_USE_EXT4 := true
73BOARD_SYSTEMIMAGE_PARTITION_SIZE := 576716800
74BOARD_USERDATAIMAGE_PARTITION_SIZE := 209715200
75BOARD_CACHEIMAGE_PARTITION_SIZE := 69206016
76BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ext4
77BOARD_FLASH_BLOCK_SIZE := 512
78TARGET_USERIMAGES_SPARSE_EXT_DISABLED := true
79
80BOARD_SEPOLICY_DIRS += build/target/board/generic/sepolicy
81BOARD_SEPOLICY_UNION += domain.te surfaceflinger.te
82