"killing Settings" is meaningless without context, we are killing the
Settings application to pull in new values, so make this clearer!
Change-Id: Ice0b950040bd05dcd49b7315def4dac3dd93eb27
Since the equality operator '==' has higher precedence than the
assignment operator '=', we were assigning 'prev' to the result of
our comparison and not the result of mRefs.fetch_sub().
This means that 'prev' would only receive the values 0 or 1. In
the cases where fetch_sub() returned 0 or 1, we were happening to
get the correct value. But if fetch_sub() was greator than 1,
we would return to the user 0, instead of the previous reference
count.
We fix this by properly adding parentheses. We also adjust the
whitespace a little to hopefully make the groupings of the logic
easier to see.
Change-Id: Ib129798a7076854b9ca4f6385c42edbf4fb75e57
Show transfer rate for individual files, and for the overall transfer.
Bug: http://b/30411535
Change-Id: If2f3008f1287b1d1add4a23c3430b39885b6c904
Test: inspected output manually
Previously, we weren't printing a newline when reporting transfer
rates, so only the last transfer rate printed would be visible.
Bug: http://b/30667841
Change-Id: Id341147912d057673de4ad26a8f618f04a8c02f3
Test: inspected output manually
sync with list-only was using SyncConnection::Error to print its output
persistently, which would prepend "adb: error: " to messages.
Change-Id: I90df5fc1123b8c613c811cf66c37aef05663b1e4
This is broken on all devices other than N9, and has no real path to fixing
it because there are so many different values already in use (41, 43, 47,
127), with no way to tell which you should use on any given device.
Bug: http://b/30597190
Change-Id: I07eeaaf6f5dc03c5532ffbfbb85ef2ad750206a0
This lets us see what's going on in init.
Bug: http://b/29751426
Merged-In: I73432dc7608ca0dc8e421a2f3a750b37c6743f62
Change-Id: I73432dc7608ca0dc8e421a2f3a750b37c6743f62
killProcessGroup actually works on cgroups. Kill the POSIX process
group ourselves.
Bug: http://b/29751426
Change-Id: I1a2808488510f4262811b6407bcd0948ad23bc60
stat on Windows fails with ENOENT when passed a path with a trailing
slash or backslash, regardless of whether the target is actually a
directory. Emulate the correct POSIX behavior by stripping trailing
path separators and then checking if the target is a directory if
successful.
Bug: http://b/30481559
Bug: https://code.google.com/p/android/issues/detail?id=214633
Change-Id: I1d398d19a9bce1ecb3fdc4aabc31aa98c82c3f93
Test: Relevant adb_tests pass on Linux and Windows 10.
* Use const reference type for parameters to avoid unnecessary copy.
* Suppress warning of not using faster overloaded string find function.
Bug: 30407689
Bug: 30411878
Change-Id: I6cfdbbd50cf5e8f3db6e5263076d3a17a9a791ee
Test: build with WITH_TIDY=1
Merged-In: Ie79dbe21899867bc62031f8618bb1322b8071525
The compensating onLastStrongRef call could be made even when there
was no onIncStrongAttempted call to compensate for. This
happened in the OBJECT_LIFETIME_STRONG case when e.g. curCount
was initially zero, but was concurrently incremented by another
thread.
I believe the old code was also incorrect in the
curCount = INITIAL_STRONG_VALUE + 1 case,
which seems to be possible under unlikely conditions.
In that case, I believe the compensating call IS needed.
Thus the condition was also changed.
Bug: 30503444
Change-Id: I44bcbcbb1264e4b52b6d3750dc39b041c4140381
The PR_SET_TIMERSLACK_PID number has collided with upstream
changes a number of times, and thus the number is not consistent
between AOSP common kernel versions.
In 4.6+, the upstream kernel added equivalent functionaity via
the /proc/<tid>/timerslack_ns entry.
This patch changes the sched_policy logic to support
/proc/<tid>/timerslack_ns if its available, falling back to the
older PR_SET_TIMERSLACK_PID method if not.
NOTE: Eventually PR_SET_TIMERSLACK_PID usage will need to be
removed as it is likely to conflict with valid future upstream
PR_* entries.
Also add missing O_CLOEXEC to other open calls in this file.
Change-Id: Iec0b8a62de0dc8bdd57b60df82bd4d31c5d64709
Signed-off-by: John Stultz <john.stultz@linaro.org>
In rare cases the hardware storage on the device may be hosed and return
garbage. Use ParseInt which handles bad input instead of stoi.
BUG: 29334139
Change-Id: I91aedc169df110bea8097775f73dda11def22311
