This variable is used to build the fingerprint and description on
signed builds, and the dash can't go in there. Add it only when
constructing the final display version variable
Change-Id: I0736d3a88e5f9980c28e6e9afa7e2f9e2d23f815
On low-end devices, the current 48 fps boot animation can use more than
50% of CPU time, and if the texture cache is enabled, a majority of main
memory as well. For these devices, add half-resolution variants of the
lower-resolution boot animations which display 2x upscaled -- this
greatly speeds the boot process and makes the boot animation run more
smoothly.
Change-Id: I0140616ca38c52a06dd4622f1c20a9ca0da95f4b
The variable used does not exist at this stage of the build. Switch
to PRODUCT_DEFAULT_DEV_CERTIFICATE, which does exist when in use.
Change-Id: Icb3bbaa437e68b96e1ce05a09f6525cd1ddb9a6a
Don't assume the path to the signing key is the default, it can
be empty and have the same meaning...
Change-Id: Id545d6436e9f21d6b62eec5a317ea7665190f104
Similar to the ro.build.id/ro.build.display.id distinction, and with
the same rationale; signed builds are intended to be stable by
definition, the release types have different meanings (user vs
userdebug), and the full CM version has too much duplicated information:
the device's name and build date are already present elsewhere in the
same information screen.
For signed builds, remove the duplicated information and the type,
leaving only the actual numeric version and the verbose build identifier,
turning for example "11-20140109-SNAPSHOT-HappyPonies-device" into just
"11.0-HappyPonies". If a simplified display version can't be built,
it'll be the same as the full ro.cm.version
Change-Id: I7d8cccbb3205bde710f0004df0a6bd12c39693f1
* Remove all this stuff. If a device wants ZRAM, it should be
enabled by the maintainer and properly configured and tuned.
* This stuff currently causes a conflict with the ZRAM support
added in Kitkat. Kill it.
Change-Id: Ib2488ea4463e32ec44b65fe786f732145b5b6e23
By defining TARGET_UNOFFICIAL_BUILD_ID in a device's cm.mk, users can
build custom CM builds with their own identifier in place.
This adheres to CM's policy that unofficial builds must be
marked as such, as both the filename and internal version will still
contain the word UNOFFICIAL.
Example:
TARGET_UNOFFICIAL_BUILD_ID := CatEater01
results in
cm-11-20131211-UNOFFICIAL-CatEater01-device(.zip)
Change-Id: I61acdf4698a7fe2b35d3d5315be4b444b1b97987
* These need to be installed setuid, which is a no-no for CTS.
Change-Id: I68d111db2db675116e214108776aa13c848d0c9a
Put procmem and procrank back into non-user builds
Change-Id: I193a9607dad40043649de6fea1f9bf0ab0c437f1
Also, set the default root_access property to 0, and
explicitly add to the build packages tools we always
want, to avoid relying on PRODUCT_TAGS that may change
upstream
Change-Id: Iecfb8501cfb2f556d5cafe7d18d06539c0433839
* Replace the 1-to-1 variable-to-buildtype stuff with a single
environment variable. CM_[TYPE]=true becomes CM_BUILDTYPE=[TYPE]
* Change the placement of the extra version tag: 10.2-21234567-TYPE-model-TAG
becomes 10.2-21234567-TYPE-TAG-model, for consistency with the rest.
The last component of the version should always be the model.
* Add support for the SNAPSHOT build type, for use with the monthlies
* Unknown types will still fallback to UNOFFICIAL
* Accept the jenkins RELEASE_TYPE variable as an alternative to
CM_BUILDTYPE for compatibility with older branches
Change-Id: Idf96c7ca887747a5ae49a17cf5adf642fb1d561f
* This package contains Bluetooth profiles implemented by Qualcomm on
top of Bluedroid.
* Currently contains support for MAP and FTP profiles.
* Also included is BTC for wlan coex on QC chipsets.
Change-Id: I933b14de4576691c31087c9de4d60f21cbe3678b
* There are a number of issues with this app, and it's currently not
working very well on most devices.
Change-Id: I36094c68fa0f642921d478aa72387bce2b88a224
This reverts commit ea14a88a2a.
Using the Package Manager prevents any danling wakelock from
killed service/receiver.
Change-Id: Ie3162ca4b18a7bc9c55613af39e88ea980407e5f
Rather than having to maintain out of tree changes, it is often
easier to maintain a hiearchy of changes, starting with the vendors
common config file. From there, inheriting products can pick up a base
and start to add or remove certain bits from it, making use of the
BOARD_SEPOLICY_* functions documented in external/sepolicy/README.
Change-Id: I28a4aaf6c126535f0a88001582641b234a750015
