Change-Id: Iee523fd75410718f0bd090f5fdcba50825a698c4

Add Android properties expansion to 'exec' arguments.
E.g.  exec /system/bin/log ${sys.usb.config}

CRs-Fixed: 390942
Change-Id: Ie520396d951e578bd9f591734a45d2f460b8f51d

…stem/core into kk-aosp-master

This reverts commit 688a8a7.

This reverts commit ddbdae8.

AID_AUDIT will be used for an audit daemon for gathering
and controlling the Linux audit subsystem.

Change-Id: I95d597524b5547a60f3a59f692b4b0a6df0a9645

Conflicts:

	include/private/android_filesystem_config.h

Conflicts:
	include/private/android_filesystem_config.h

Initial commit for an audit daemon that
writes kernel audit messages to a log
file. The daemon runs in uid "audit" or
AID_AUDIT.

The log files are located at /data/misc/audit/
The daemon maintains two files at this location:
audit.log and optionally audit.old. On boot (
if the file is non-zero in size), or
when a fixed threshold is hit, the daemon rotates
audit.log to audit.old.

Optionally, if passed the -k option, the daemon polls
dmesg for all lines that contain "audit" and writes
them into the log. After that it continues to operate
as normal, receiving the messages from the netlink
socket.

Change-Id: I5b5037a5a8b39a054213848249afb7808f8b0ffa

…stem/core into kk-aosp-master

This is a combination of 3 commits pulled from Motorola's github for
allowing f2_mgr to have "fallback" handling for a mount point. This
is most useful in the case of f2fs where some variants may be formatted
ext4 and some f2fs. These device can now be supported in 1 fstab.

Example snippet of fstab.* for userdata mount point:
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,discard,nosuid,nodev,noatime,nodiratime,noauto_da_alloc,nobarrier wait,check,encryptable=footer
/dev/block/platform/msm_sdcc.1/by-name/userdata /data f2fs rw,discard,nosuid,nodev,noatime,nodiratime,inline_xattr wait,encryptable=footer

Changes in logic ignore 1st failure as an automatic assumption of encryption.
Instead fstab is checked for another line describing mount point (2 retries)
Once all retries fail, encryption is assumed.

NOTE: Some logic was removed from the original sources: If userdata failed to mount
and was not encrypted a format of the filesystem was forced as a way of recovering
the device. Most custom ROM users have access to recovery where they can decide
what to do in this case.

REFERENCE COMMITS:

IKJBMR2-6556: don't assume that mount failure implies encryption
MotorolaMobilityLLC/system-core@f3c3b19

fs_mgr: support multiple file systems on a mount point
MotorolaMobilityLLC/system-core@84ea2cd

fs_mgr: rename "recover_userdata" relic to join fs_mgr
MotorolaMobilityLLC/system-core@a4ef7c2

…stem/core into kk-aosp-master