Lines Matching refs:on

4 both Android applications and native processes running on Android. It can
5 profile both Java and C++ code on Android. The simpleperf executable can run on Android >=L,
6 and Python scripts can be used on Android >= N.
23 …- [Why we suggest profiling on Android >= N devices?](#why-we-suggest-profiling-on-android--n-devi…
38 1. It collects more info in profiling data. Since the common workflow is "record on the device, and
39    report on the host", simpleperf not only collects samples in profiling data, but also collects
44       to file. This is to save storage space on the device.
45    b. Support tracing both on CPU time and off CPU time with --trace-offcpu option.
46    c. Support recording callgraphs of JITed and interpreted Java code on Android >= P.
58    a. Builds static executables on the device. Since static executables don't rely on any library,
59       simpleperf executables can be pushed on any Android device and used to record profiling data.
60    b. Builds executables on different hosts: Linux, Mac and Windows. These executables can be used
61       to report on hosts.
62    c. Builds report shared libraries on different hosts. The report library is used by different
85 bin/android/${arch}/simpleperf: static simpleperf executables used on the device.
87 bin/${host}/${arch}/simpleperf: simpleperf executables used on the host, only supports reporting.
89 bin/${host}/${arch}/libsimpleperf_report.${so/dylib/dll}: report shared libraries used on the host.
116 ### Why we suggest profiling on Android >= N devices?
118 1. Running on a device reflects a real running situation, so we suggest
119 profiling on real devices instead of emulators.
134 2. Behave normally well on both ARM and ARM64, for both fully compiled Java code and C++ code.
142 2. Don't work well on ARM. Because ARM is short of registers, and ARM and THUMB code have different
144 3. Also don't work well on fully compiled Java code on ARM64. Because the ART compiler doesn't
146 4. Work well when profiling native programs on ARM64. One example is profiling surfacelinger. And
151 So if you need to profile code on ARM or profile fully compiled Java code, dwarf based call graphs
152 may be better. If you need to profile C++ code on ARM64, stack frame based call graphs may be
157 Simpleperf may need unstripped native binaries on the device to generate good dwarf based call
160 2. Download unstripped native libraries on device, as [here](#fix-broken-callchain-stopped-at-c-fun…
164 The simpleperf record command collects symbols on device in perf.data. But if the native libraries
165 you use on device are stripped, this will result in a lot of unknown symbols in the report. A
166 solution is to build binary_cache on host.
174 libraries on host. After running it, the native libraries containing symbol tables are collected
190 libraries on device, and ask simpleperf to use them when recording.
195 # create native_libs dir on device, and push unstripped libs in it (nested dirs are not supported).
216   a. Generate perf.data and pull it on host.