Cast away the const qualifier in BBinder::findObject. C11, unlike C++11,
does not allow loads from const atomics. This is widely regarded as
a bug (see WG14 DR 459). This is a hack to work around it until it's
officially fixed in the spec.
load_const_atomic was adapted from commit
1e8587a479fd8b1ce9b594298a93f517816e8f15
I don't think we want to dignify this by putting it into a header file.
Bug:17067219
Change-Id: Icbfcbda2722e6f80d2bb065a0bb3ec7634bcacb2
In C++11 mode, "foo"MACRO_THAT_EXPANDS_TO_STRING gets lexed as a user
defined literal. Add space around the macro.
Change-Id: I2741f5be9c0b1562e0f413d1309ef9d687e89b41
Change the mExtras field in Binder.h to be a stdatomic.h atomic
value, and replace references to it with proper stdatomic.h calls.
This removes one of a small number of remaining 64 bit
android_atomic references. It also replaces the erroneously
non-atomic read accesses to mExtras.
It would be better if this used the C++11 <atomic> facility,
but we don't quite have that yet.
Bug: 16513433
Change-Id: Ibabb88d05025187ee1ce6c7f1aa670b133a547f8
All uses of this API have been removed. It should
never have been made public in the first place.
bug: 15424960
(cherry picked from commit 7da40c0a84)
Change-Id: I8d89f62dbdaee7149ef908e0c97417b85e0c48a2
Write string lengths as uint32_t so that their width is
the same on 32 and 64 bit processes.
Note that this fixes another bug as a side effect; getFlattenedSize
was assuming that sizeof(uint32_t) == sizeof(size_t).
Change-Id: I7b6e3993e1f1ac45c14832ce59c59e0772855a2f
To make sure the stature which pass between 32/64bit process have
same memory layout for 32/64bit.
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Co-Authored-by: Narayan Kamath <narayan@google.com> (Unit test only.)
Change-Id: I1bc2d12cce41ec0bc484adcaf968f274bec75c12
This ensures it's the same size in both 32 and 64 bit
processes and also brings it in line with struct
MotionEntry.
(cherry-picked from bc6001b026)
Change-Id: I28e87050478920a54132efbbb8138076ebad1409
The gralloc API now provides a way for using lock/unlock with the Android
explicit synchronisation concept. This changes updates the GraphicBuffer class
to also expose this functionality, and updates the Surface class to make use of
in line with the dequeueBuffer/queueBuffer mechanism.
This new behaviour is dependent on GRALLOC_MODULE_API_VERSION_0_3. If the local
gralloc module does not support this then the existing synchronous lock/unlock
mechanism will be used.
Change-Id: I8c3fd9592e0c5400ac9be84450f55a77cc0bbdc5
The gralloc API now provides a way for using lock/unlock with the Android
explicit synchronisation concept. This changes updates the GraphicBuffer class
to also expose this functionality, and updates the Surface class to make use of
in line with the dequeueBuffer/queueBuffer mechanism.
This new behaviour is dependent on GRALLOC_MODULE_API_VERSION_0_3. If the local
gralloc module does not support this then the existing synchronous lock/unlock
mechanism will be used.
Change-Id: I77daa1beb197b63b1c2f281b8414ac4ae4b5b03c
It can help to detect some kind of error, such as why GraphicBuffer::flatten
will crash when handle is null.
Change-Id: I703cd035b96edb7afb324cf24d8230d4e55f4f52
Signed-off-by: Jun Jiang <jun.a.jiang@intel.com>
The Fence object was writing a size_t into the binder buffer
in flatten, which changes size if the producer and consumer
are running in a 32-bit and a 64-bit process. Use a uint32_t
instead.
Change-Id: Ifed526513800ce27f9d605101cddd922292cca37
These weren't really being used and they make it
very hard to reason about who looks at command line
arguments.
Processes started via app_process (this includes all
zygote forks and the system_server) can get information
about command line arguments from the AndroidRuntime
class, which is available via a call to
AndroidRuntime::getRuntime.
bug: 13647418
Change-Id: I6f92680c3619a68c6d4b0995db4cdc9adc788e36
