We comment out the names of the parameters we're intentionally
not using.
(cherrypick of 44a0eb4d8cdf4ab881f5d5a1acc1155266a46f6a.)
Change-Id: I0a92d9200ca26cdc4700d2ff9e3ab33c102520d5
I'll come back and remove klog_init when I've removed other calls to it.
Change-Id: Iad7fd26d853b4ddc54e9abd44516b6f138cbbfcb
Test: booted N9, looked at "adb shell dmesg" output.
The <hardware/qemu_pipe.h> header isn't related to any loadable
hardware module, this patch thus relocates it to <system/qemu_pipe.h>
which is a much more logical location.
Note the following changes:
- The pipe name must begin with the 'pipe:' prefix to avoid an
un-necessary snprintf() and buffer copy.
- Does not probe for the obsolete /dev/goldfish_pipe device, i.e.
only use /dev/qemu_pipe instead.
- Use QEMU_PIPE_DEBUG() instead of D() as the debugging macro.
+ Update ADB to use the newest <system/qemu_pipe.h>
+ Add qemu_pipe_frame_send() and qemu_pipe_frame_recv() utility
functions which replace the obsolete qemud_channel_send() and
qemud_channel_recv() from the defunct <hardware/qemud.h>
header.
BUG=25875346
Change-Id: Ic290a5b79d466c2af64b49bd9134643277c11bfd
If the underlying local map changes, it's possible for multiple
threads to try and modify the map data associated with the UnwindLocalMap
object. Add a lock when generating the local map to avoid this problem.
In addition, add a read lock whenever any caller gets the maps iterator.
Updated all iterator callers to make this lock.
Bug: 29387050
Change-Id: Ie34822c3d8fd3bdb3dd126aeeb399969c36508c1
clang doesn't do the frontend inlining/dead code elimination needed for
the fortified implementation to work. Therefore, turn it off.
Bug: http://b/28381737
Change-Id: Ie8dd970e3908b1daaa587ad2bd041e8f6e2089db
am: 6a29fe931d
* commit '6a29fe931d9fd3bf7f2aad3713dc70c080970763':
Add utility to prepare files in a similar way to directories
Change-Id: I288024d55e8cead1c902950938b03bfa8dcc3df3
Add comment that SharedBuffer is deprecated.
Both aref and SharedBuffer had memory ordering bugs. Aref has no
clients.
SharedBuffer had several bugs, which are fixed here:
mRefs was declared neither volatile, not atomic, allowing the
compiler to, for example, reuse a stale previously loaded value.
It used the default android_atomic release memory ordering, which
is insufficient for reference count decrements.
It used an ordinary memory read in onlyOwner() to check whether
an object is safe to deallocate, without any attempt to ensure
memory ordering.
Comments claimed that SharedBuffer was exactly 16 bytes, but
this was neither checked, nor correct on 64-bit platforms.
This turns mRef into a std::atomic and removes the android_atomic
dependency.
Bug: 28826227
Change-Id: I39fa0b4f70ac0471b14ad274806fc4e0c0802e78
(cherry picked from commit 3e4c076ef2)
Add comment that SharedBuffer is deprecated.
Both aref and SharedBuffer had memory ordering bugs. Aref has no
clients.
SharedBuffer had several bugs, which are fixed here:
mRefs was declared neither volatile, not atomic, allowing the
compiler to, for example, reuse a stale previously loaded value.
It used the default android_atomic release memory ordering, which
is insufficient for reference count decrements.
It used an ordinary memory read in onlyOwner() to check whether
an object is safe to deallocate, without any attempt to ensure
memory ordering.
Comments claimed that SharedBuffer was exactly 16 bytes, but
this was neither checked, nor correct on 64-bit platforms.
This turns mRef into a std::atomic and removes the android_atomic
dependency.
Bug: 28826227
Change-Id: I39fa0b4f70ac0471b14ad274806fc4e0c0802e78
Convert to use std::atomic directly.
Consistently use relaxed ordering for increments, release ordering
for decrements, and an added acquire fence when the count goes to
zero.
Fix what looks like another race in attemptIncStrong:
It seems entirely possible that the final adjustment for
INITIAL_STRONG_VALUE would see e.g. INITIAL_STRONG_VALUE + 1,
since we could be running in the middle of another initial
increment.
Attempt to somewhat document what this actually does, and
what's expected from the client. Hide the documentation in
the .cpp file for now.
Remove a confusing redundant test in decWeak. OBJECT_LIFETIME_STRONG
and OBJECT_LIFETIME_WEAK are the only options, in spite of some
of the original comments.
It's conceivable that either of these issues has resulted in
actual crashes, though I would guess the probability is small.
It's hard enough to reason about this code without the bugs.
Bug: 28705989
Change-Id: I4107a56c3fc0fdb7ee17fc8a8f0dd7fb128af9d8
(cherry picked from commit e263e6c633)
Convert to use std::atomic directly.
Consistently use relaxed ordering for increments, release ordering
for decrements, and an added acquire fence when the count goes to
zero.
Fix what looks like another race in attemptIncStrong:
It seems entirely possible that the final adjustment for
INITIAL_STRONG_VALUE would see e.g. INITIAL_STRONG_VALUE + 1,
since we could be running in the middle of another initial
increment.
Attempt to somewhat document what this actually does, and
what's expected from the client. Hide the documentation in
the .cpp file for now.
Remove a confusing redundant test in decWeak. OBJECT_LIFETIME_STRONG
and OBJECT_LIFETIME_WEAK are the only options, in spite of some
of the original comments.
It's conceivable that either of these issues has resulted in
actual crashes, though I would guess the probability is small.
It's hard enough to reason about this code without the bugs.
Bug: 28705989
Change-Id: I4107a56c3fc0fdb7ee17fc8a8f0dd7fb128af9d8
It's no longer specific to make_ext4fs, will be used for mksquashfs as
well.
BUG: 27467028
Change-Id: I41b8c2b168ada45c8378dee522391edfb8f6b9a6
Signed-off-by: Mohamad Ayyash <mkayyash@google.com>
BUG: 28704419
These are needed for aapt to find javadoc comments that contain
"@removed" in order to skip them when printing styleable docs.
Bug: 28663748
Change-Id: I8866d2167c41e11d6c2586da369560d5815fd13e
Not to be confused with <cutils/ashmem.h> or <linux/ashmem.h>, one or other
of which is what you should be using instead.
Change-Id: Ie158530591b28b94c2cda9e2686cae56b7aeb1a3
Most of the system/core/include/log/log.h file uses the C99 syntax of
variadic macros (that is, '...' in parameter list and __VA_ARGS__
in arguments). Except for andoid_printLog and android_printAssert
which still uses GCC custom extension syntax.
Switched the remaining macros to use C99 syntax. GCC extension syntax
makes my editor's code parser puke.
BUG: None
Change-Id: Ia6ebc0f2044b64182c425b179da0229c7046be4a
Disambiguate between base and android::base namespaces. This matters
when headers from libbase are indirectly included.
Bug: 27804373
Test: Compiles in that referenced situation.
Change-Id: Icb26595bb0013733aa8c03971c9f4a950c8b2ab1
Greg Kaiser