Hi, technically speaking you are not really supposed to just do that as there aren't much docs at all, and it can break CTS.
However, for a debug quickie - you can put "PRODUCT_LOCALES:=en_US" into your device's board configuration, also check PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD, PRODUCT_AAPT_PREF_CONFIG, PRODUCT_AAPT_PREBUILT_DPI, PRODUCT_AAPT_CONFIG aswell. Or check how build tags (inside package's Android.mk) are supposed to work Won't recommend DONT_DEXPREOPT_PREBUILTS though because it'd cause lot problems to QA because of phones acting slow.
Also, the speedy inhouse builds to test a feature or two should be either done with `make snod` or rely on unit tests to break first, compilation time if possible .
Also what's your work got to do with real document-heavy parts of ? If you're rebuilding framework/SDK that often, even a $2 per day of cloud 32gb/8 core instance would be a lesser expense than repeated standby costs over a developer's time, while such asset may be shared between a group of developers. Even more important if you're going to ship production/nightly builds from some date later. Might also look into structuring your changes - commits, branches, gerrit/CI etc, so they won't cause nearly identical rebuilds, and either ccache or less common solutions such as btrfs/overlay fs are a huge help there (at a cost of couple TBsof storage but its manageable).