/system/sepolicy/public/ |
D | incident.te | 3 # reports that have already been taken, and monitor for new ones.
|
D | init.te | 538 # Set scheduling info for psi monitor thread.
|
/system/sepolicy/prebuilts/api/28.0/public/ |
D | incident.te | 3 # reports that have already been taken, and monitor for new ones.
|
/system/sepolicy/prebuilts/api/29.0/public/ |
D | incident.te | 3 # reports that have already been taken, and monitor for new ones.
|
D | init.te | 485 # Set scheduling info for psi monitor thread.
|
/system/sepolicy/prebuilts/api/30.0/public/ |
D | incident.te | 3 # reports that have already been taken, and monitor for new ones.
|
D | init.te | 516 # Set scheduling info for psi monitor thread.
|
/system/sepolicy/prebuilts/api/27.0/public/ |
D | incident.te | 3 # reports that have already been taken, and monitor for new ones.
|
/system/sepolicy/prebuilts/api/26.0/public/ |
D | incident.te | 3 # reports that have already been taken, and monitor for new ones.
|
/system/sepolicy/prebuilts/api/31.0/public/ |
D | incident.te | 3 # reports that have already been taken, and monitor for new ones.
|
D | init.te | 538 # Set scheduling info for psi monitor thread.
|
/system/extras/simpleperf/doc/ |
D | android_platform_profiling.md | 79 by the kernel to monitor memory latency. So only 3 counters are available. It's fine to monitor up 80 to 3 PMU events at the same time. To monitor more than 3 events, the `--use-devfreq-counters` option
|
D | executable_commands_reference.md | 122 we can select which events to use, which processes/threads to monitor, how long to monitor and the 126 # Stat using default events (cpu-cycles,instructions,...), and monitor process 7394 for 10 seconds. 199 We can select which processes or threads to monitor via -p or -t. Monitoring a 201 process to run the new command and then monitor the child process. 223 When monitoring existing threads, we can use --duration to decide how long to monitor. When 239 If you want to write a script to control how long to monitor, you can send one of SIGINT, SIGTERM, 331 By passing options, we can select which events to use, which processes/threads to monitor, 332 what frequency to dump samples, how long to monitor, and where to store samples. 404 The way to decide how long to monitor in record command is similar to that in the stat command. 418 If you want to write a script to control how long to monitor, you can send one of SIGINT, SIGTERM,
|
/system/bt/service/doc/ |
D | IBluetooth.txt | 45 * ADAPTER_STATE_ON. Callers can monitor the status of this call by observing 56 * ADAPTER_STATE_OFF. Callers can monitor the status of this call by observing
|
/system/chre/apps/test/common/proto/ |
D | chre_cross_validation_wifi.proto | 39 // The step where the nanoapp is configured to monitor for wifi scans and the
|
/system/vold/binder/android/os/ |
D | IVold.aidl | 29 void monitor(); in monitor() method
|
/system/vold/ |
D | VoldNativeService.h | 36 binder::Status monitor();
|
D | VoldNativeService.cpp | 157 binder::Status VoldNativeService::monitor() { in monitor() function in android::vold::VoldNativeService
|
/system/core/fs_mgr/libsnapshot/android/snapshot/ |
D | snapshot.proto | 176 // of sectors modified to monitor and show the progress of the merge during
|
/system/chre/doc/ |
D | nanoapp_developer_guide.md | 245 * Make a WiFi on-demand scan request only if the WiFi scan monitor doesn’t
|
/system/core/rootdir/ |
D | init.rc | 378 # make the PSI monitor accessible to others 607 # Set up a tracing instance for system_server to monitor error_report_end events.
|
/system/sepolicy/prebuilts/api/29.0/private/ |
D | system_server.te | 127 # Set scheduling info for psi monitor thread.
|
/system/sepolicy/prebuilts/api/30.0/private/ |
D | system_server.te | 145 # Set scheduling info for psi monitor thread.
|
/system/sepolicy/private/ |
D | system_server.te | 180 # Set scheduling info for psi monitor thread.
|
/system/sepolicy/prebuilts/api/31.0/private/ |
D | system_server.te | 180 # Set scheduling info for psi monitor thread.
|