* mdns.cpp:153:20: warning: an integer is interpreted as a character code
when assigning it to a string; if this is intended, cast the integer to
the appropriate character type; if you want a string representation, use
the appropriate conversion facility [bugprone-string-integer-assignment]
Test: WITH_TIDY=1 make
Change-Id: Id9a790ac31722c6ee8886703939977b913ce95fe
In case multiple threads try to reference this variable while it is
being set, it should be atomic so that all threads always see a valid
value.
Bug: 150898477
Test: liblog, libbase unit tests
Change-Id: If6c9e291f2471b96a752dc6e76e3e63458b71391
In particular, always include the file name in the log.
Bug: http://b/144462309
Test: adb kill-server && adb devices -l && cat /tmp/adb.*.log
Change-Id: I66b5e063b00381f9dfa9ace222cad3e415e4f43b
The rollback indicator is created during first stage init and
is unlabeled. Need to restorecon it properly so that it can
be properly deleted by update_engine later.
Bug: 149956852
Bug: 150907679
Test: apply OTA, reboot, look at serial console
Change-Id: Ie954023b557865691fec2ae378145596bf1973a9
For now this leaves the ability to cross-unwind a mips process, but we
should probably clean that up too. We need to remove the build remnants so
that we can clean up the build system itself (otherwise it sees us talking
about an architecture it doesn't know about, and assumes that something's
wrong).
Test: treehugger
Change-Id: I2862c630cec95dbdd474e34c3568d0e1a6d44b16
Add a "track-app" service in adbd. For every debuggable or
profileable-from-shell process, ART sends related info to
adbd and adbd surfaces the info through the "track-app"
service.
The output format of "track-app" is a line summarizing
the number of reported processes, followed by a protobuf
message in human readable form. For example,
Process count: 2
process {
pid: 3307
profileable: true
architecture: "arm64"
}
process {
pid: 3341
debuggable: true
profileable: true
architecture: "arm64"
}
Bug: 149050485
Test: manually unplugged/replugged, "adb track-app",
"adb track-jdwp"
Change-Id: Id1f1a920e1afc148c7e4d2add790baab796178e1
Logic of unwinding dm-device stack to figure out what entry was used to
mount userdata turned out to be a little bit more involved, and it
shouldn't be part of libfstab
This CL just moves code around and cleans API a little bit, actual fix
will be in the follow-up CL.
Test: atest CtsFsMgrTest
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 148612148
Change-Id: If0f8a765dba63adb0e6a711eb81fffdcabea3480
Merged-In: If0f8a765dba63adb0e6a711eb81fffdcabea3480
(cherry picked from commit 8f50cfc28d)
This reverts commit eb94c7802d.
Reason for revert: b/150949964 - Broke boot test on aosp-master-with-phones.
Merged-In tags to revert just aosp-master/stage-aosp-master where boot
is broken.
Change-Id: Ic76e36b42060b5948f48af41f67544598d6f9f87
Merged-In: I0e1e7da1cfbe320ba6605f8de9dcdb5091c41e4f
Merged-In: Icff3bd68b31f8c1d5a71f05c7c52eae6e896bfc2
Previously, we were waiting for the other end to respond after every
file sent, which results in massive slowdown when there's any amount of
latency on the transport.
This improves performance on a cuttlefish instance with ~7ms RTT from:
system/: 2037 files pushed, 0 skipped. 2.8 MB/s (762803979 bytes in 262.964s)
to:
system/: 2037 files pushed, 0 skipped. 11.9 MB/s (762803979 bytes in 61.278s)
Bug: https://issuetracker.google.com/150827486
Test: ./test_device.py
Change-Id: I3a0c893faa5d455cc6ccbc86915a17e1b5abbfbe
The file accessing API in liblp don't work on win32. Add the O_BINARY
to correct the file stream access.
This patch follow the AOSP change 829979.
Change-Id: I97180e2f07cacf109a86593b6a12975597552053
Signed-off-by: Haoran.Wang <elven.wang@nxp.com>
Apexes do not support "on" macros, so we are moving
them into the system partition
Bug: 145923087
Test: m -j
Change-Id: Ic671a51f2ec5b91f2f631bae0f509b4aa2d057b4
Merged-In: Ic84e77269f80097b675d6a1b0d206c2bae7d918d
Change API for SnapshotMergeStats so that it is easier
for update_engine to use.
Test: apply OTA and look at stats
Bug: 147696014
Bug: 138817833
Change-Id: Ie4036ac7382102c00f0761f443d78e00b9e585d5
Now that update_engine is responsible for initiating the
merge, WaitForMerge function becomes useless.
Bug: 147696014
Test: compiles
Change-Id: I3779bdf9dd8d1716238e21d09acf0499e3fc90a3
In CheckMergeState / HandleCancelledUpdate, if removing update state
fails, just return the previous state. It used to return Cancelled,
and the error goes unnoticed.
Test: pass
Bug: 147696014
Change-Id: I9cb3d20c5c886afa1913740c903eaad08f0cc041
If updated then immediately flashed target slot at unverified
stage, update_engine attempts to call RemoveAllSnapshots, but
it used to fail because unmapping fails. In reality, these devices
are dm-linear targets, so unmapping them is optional.
- Introduce a GetSnapshotFlashingStatus function that expose more
information than AreAllSnapshotsCancelled. We can use the returned
map<string, bool> to determine whether a partition is flashed or
not.
- Introduce ShouldUnmapDeleteSnapshot which determines whether
unmapping / deleteting a snapshot is needed in RemoveAllSnapshots.
Test: apply OTA, flash target slot, then inspect logs
Bug: 147696014
Change-Id: I0853d1e213566af2a3401e46fac7d9586cee7aaf
If rollback is detected in ProcessUpdateState, call
RemoveUpdateState and return UpdateState::Cancelled. Now that
update_engine is reponsible for initiating the merge, it can react to
this state and clean up markers appropriately.
Test: libsnapshot_test
Test: apply OTA, manually rollback (by setting the active slot), then
inspect /metadata/ota as well as /data/misc/update_engine/prefs.
Bug: 147696014
Change-Id: Ibfee11fb50e4f4fb7c6cf02b4921b35e77b8f5a5
Treehugger Robot