GitLab

forceencrypt= will encrypt the drive at boot if it is not encrypted. This change
will not have an impact until we set this flag in appropirate fstabs.

Bug: 11985952

Change-Id: I6c65eda7f109e4936aa160da50f871703aefb351

* commit '6a8c3164':
  Create an UnwindMapLocal object.

* commit 'e35cba9a':
  Create an UnwindMapLocal object.

* commit 'a97798af':
  Create an UnwindMapLocal object.

* commit '4fe18615':
  Handle errno properly to avoid corrupt str_parms

* commit '56d57e88':
  Handle errno properly to avoid corrupt str_parms

The way libunwind handles local unwinds is different from remote unwinds,
so create a new map object to handle the differences.

Add new test to verify the map data is being generated correctly.

Add new tests to check for leaks.

Refactor the BACK_LOGW code into a single header file.

Change-Id: I01f3cbfc4b927646174ea1b614fa25d23b9b3427

* commit '5f130216':
  Handle errno properly to avoid corrupt str_parms

A normal sequence of calls is as follows:
str_parms_create_str, str_parms_add_str, str_parms_destroy.
In some cases the destroy caused double free.

str_parms_add_str will clone the input and send it to hashmapPut
for storage. If hashmapPut did not store the strings it will raise
errno = ENOMEM and leave caller with ownership of the strings.
In any of these cases it will be safe to destroy the str_parms.

But what if it wasn't hashmapPut that said NOMEM? What if there
was a stale NOMEM already before a successful hashmapPut?
In that case the strings will be successfully added to the list
(if new), but when str_parms_add_str sees the NOMEM it will free
them anyway, leaving dangling pointers in the str_parms!!

It is the responsibility of the caller to clear errno before any
interesting call. This patch makes sure that str_parms_add_str
reacts only on errno emmitted from hashmapPut.

Change-Id: If87e4bcc482f09e1c66133d33517b152ebdac65f

This checks ro.debuggable to determine whether a device is in the
debuggable state or not, disabling verification if it is.

Eventually we'd like to narrow this down to only devices which
need to disable it, but we aren't there yet.

Change-Id: I06a329fe5449deab6bae595877dbb1f200850241

* commit 'f84b61b3':
  Add CleanSpec for zygote changes.

* commit 'b5e13749':
  Add CleanSpec for zygote changes.

* commit '223fc42b':
  Add CleanSpec for zygote changes.

default.prop is generated out of several makefile variables,
and it isn't possible to neatly express a dependency on those
variables (except perhaps by adding every possible makefile that
could define them to the deps list).

Change-Id: I93ea45c956aa22922f2389f735c058700621f674

* commit '990cdb14':
  logd: build breakage in user

* commit 'eb69b9a5':
  logd: build breakage in user

* commit '075828b8':
  logd: build breakage in user

* commit 'cb6daaaf':
  Fix stack trace logging in RefBase.

* commit '022fa5cc':
  init: unused paramter warning messages

build breakage in branch: git_klp-dev-gpl @ 1101951

Change-Id: I4c9681bf4c97368ec19f5a79fef134aba937f337

* commit '9d379a1e':
  Fix stack trace logging in RefBase.

* commit 'dfdbb64f':
  Fix stack trace logging in RefBase.

* commit '7f92f390':
  init: unused paramter warning messages

* commit '5b0ad963':
  init: unused paramter warning messages

Change-Id: I1667371106be4b230ac3850e9819e4549eea2973

* commit 'b3d94f0a':
  logd: Add minimum time bucket statistics

This was broken about 5 months ago in change I78435ed49aa196a0efb45bf9b2d58b62c41737d3.
See: https://goto.google.com/jhtss

Change-Id: Icc32993552efed3015bc1b79a7bd872d7510e020

* commit 'c76e38ba':
  logd: Add minimum time bucket statistics

* commit 'e7f3cce7':
  logd: Add minimum time bucket statistics

* Only enabled for dev builds because halves performance.
- Used to establish if /proc/sys/net/unix/max_dgram_qlen
  is appropriate for the platform
  (see logd/LogStatistics.cpp comments)
- enabled if logd.dgram_qlen.statistics is not zero/empty

Change-Id: Ib8ecfeb75b6f0f954c099a6b1032b8afb5efcbd4

Change-Id: Ie123b4fff76ef43e2b1c0583731e88997504320e