| # config.mk |
| # |
| # Product-specific compile-time definitions. |
| # |
| |
| # The generic product target doesn't have any hardware-specific pieces. |
| TARGET_NO_BOOTLOADER := true |
| TARGET_NO_KERNEL := true |
| TARGET_ARCH := arm |
| |
| # Note: we build the platform images for ARMv7-A _without_ NEON. |
| # |
| # Technically, the emulator supports ARMv7-A _and_ NEON instructions, but |
| # emulated NEON code paths typically ends up 2x slower than the normal C code |
| # it is supposed to replace (unlike on real devices where it is 2x to 3x |
| # faster). |
| # |
| # What this means is that the platform image will not use NEON code paths |
| # that are slower to emulate. On the other hand, it is possible to emulate |
| # application code generated with the NDK that uses NEON in the emulator. |
| # |
| TARGET_ARCH_VARIANT := armv7-a |
| TARGET_CPU_VARIANT := generic |
| TARGET_CPU_ABI := armeabi-v7a |
| TARGET_CPU_ABI2 := armeabi |
| |
| HAVE_HTC_AUDIO_DRIVER := true |
| BOARD_USES_GENERIC_AUDIO := true |
| |
| # no hardware camera |
| USE_CAMERA_STUB := true |
| |
| # Enable dex-preoptimization to speed up the first boot sequence |
| # of an SDK AVD. Note that this operation only works on Linux for now |
| ifeq ($(HOST_OS),linux) |
| ifeq ($(WITH_DEXPREOPT),) |
| WITH_DEXPREOPT := true |
| endif |
| endif |
| |
| # Build OpenGLES emulation guest and host libraries |
| BUILD_EMULATOR_OPENGL := true |
| |
| # Build and enable the OpenGL ES View renderer. When running on the emulator, |
| # the GLES renderer disables itself if host GL acceleration isn't available. |
| USE_OPENGL_RENDERER := true |
| |
| # Set the phase offset of the system's vsync event relative to the hardware |
| # vsync. The system's vsync event drives Choreographer and SurfaceFlinger's |
| # rendering. This value is the number of nanoseconds after the hardware vsync |
| # that the system vsync event will occur. |
| # |
| # This phase offset allows adjustment of the minimum latency from application |
| # wake-up (by Choregographer) time to the time at which the resulting window |
| # image is displayed. This value may be either positive (after the HW vsync) |
| # or negative (before the HW vsync). Setting it to 0 will result in a |
| # minimum latency of two vsync periods because the app and SurfaceFlinger |
| # will run just after the HW vsync. Setting it to a positive number will |
| # result in the minimum latency being: |
| # |
| # (2 * VSYNC_PERIOD - (vsyncPhaseOffsetNs % VSYNC_PERIOD)) |
| # |
| # Note that reducing this latency makes it more likely for the applications |
| # to not have their window content image ready in time. When this happens |
| # the latency will end up being an additional vsync period, and animations |
| # will hiccup. Therefore, this latency should be tuned somewhat |
| # conservatively (or at least with awareness of the trade-off being made). |
| VSYNC_EVENT_PHASE_OFFSET_NS := 0 |
| |
| TARGET_USERIMAGES_USE_EXT4 := true |
| BOARD_SYSTEMIMAGE_PARTITION_SIZE := 576716800 |
| BOARD_USERDATAIMAGE_PARTITION_SIZE := 209715200 |
| BOARD_CACHEIMAGE_PARTITION_SIZE := 69206016 |
| BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ext4 |
| BOARD_FLASH_BLOCK_SIZE := 512 |
| TARGET_USERIMAGES_SPARSE_EXT_DISABLED := true |
| |
| BOARD_SEPOLICY_DIRS += build/target/board/generic/sepolicy |
| BOARD_SEPOLICY_UNION += domain.te surfaceflinger.te |