This patch makes the Renamer class destructor virtual and fixes
the incorrect constructor initialization list ordering.
These issues and related compiler warnings have been suppressed
by the build system which uses the gcc isystem command
line option, unless a project explicitly adds the include the path
system/core/include to Android.mk and uses the templates.
Change-Id: Iff76a655eb8bd547adfe994c7315a005e98aed41
Signed-off-by: Ukri Niemimuukko <ukri.niemimuukko@intel.com>
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
Signed-off-by: Yong Yao <yong.yao@intel.com>
Without this patch we get:
system/core/adb/commandline.c:1629:16: error: array subscript is above
array bounds [-Werror=array-bounds]
Change-Id: I494eb8b4d0e8082f8ff57bdd33d8d46c8c481c6f
Signed-off-by: Alexander Ivchenko <alexander.ivchenko@intel.com>
Use truncate64 instead of truncate so we don't truncate (ho ho) the offset.
(cherrypick of 4568565e85bf2e1ea11b2e09d72e244088c05dbc.)
Bug: https://code.google.com/p/android/issues/detail?id=74039
Change-Id: I63711ccd299e3ebc475563b1999817d1919571ab
Ideally bootchart collects system data every BOOTCHART_POLLING_MS ms.
However, the current bootchart pacing logic would collect data every
time the main loop in init.c is executed. This results in:
1. Multiple data samples being taken consecutively or prematurely. In
many cases, these data samples have the same timestamp (in jiffies).
The off-line data processing tool would complain about dividing by
zero "interval" and bail out.
2. Because of the ineffective pacing, bootchart data collection would
terminate prematurely. The total duration of data collection is usually
much shorter than what the user specifies.
The fix is to check whether BOOTCHART_POLLING_MS ms has elapsed
before taking a new data sample. For this purpose, /proc/uptime
is used to get the time values, consistent with the precision of
bootchart timestamps.
Change-Id: I106bf91dbda01059b719df6c73b8bd1cd54a64f0
Signed-off-by: Bo (Andover) Zhang <zhang@broadcom.com>
- test -f -n and -r flags
- fix issue with parse error for sizes in bytes (no multiplier)
Bug: 16147190
Change-Id: Iadf2fd903d5e881d02f1d2b491441cc8090ee1c9
debuggerd allows uid-0 processes to dump tombstones or backtraces
of any process, and uid-system processes to dump backtraces of any
processes. Restrict these operations via SELinux based on the
client context, the target process context, and the action.
Depends on I8e120d319512ff207ed22ed87cde4e0432a13dda for the
corresponding policy definitions.
Change-Id: Ib317564e54e07cc21f259e75124b762ad17c6e16
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
When built with "#define FUSE_TRACE 1" numerous TRACE statements
failed to compile because of mismatches between format strings and
types (uint64_t and size_t). These have been corrected by using the
format strings from the inttype.h header file, or %zu.
Change-Id: I36cd6f8da0790f1218d7dbaaa5b3bbfa4df7fdee
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Use more upstream NetBSD, and update those things that were already NetBSD.
Note that unlike bionic, the upstream-netbsd directory isn't pristine; we have
changes marked by __ANDROID__.
Bug: 16493461
Change-Id: I99762bfe02caa0945ea4a184670888a4b5435a1d
Before running the sdcard daemon, make sure that installd has
completed all upgrades to /data that it needs to complete.
This avoids race conditions between installd and the sdcard daemon.
Maybe fixes bug 16329437.
(cherrypicked from commit 8d28fa71fc)
Bug: 16329437
Change-Id: I5e164f08009c1036469f8734ec07cbae9c5e262b
Bug: 16408818
These targets are no longer in use, since we have a proper way to create both
32-bit and 64-bit host libraries in a single build now.
Change-Id: Icd09f795acd220de5b5e956a8d8e1b4ab4864fa9
Elliott Hughes