- 浏览: 1149841 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
MyEyeOfJava:
产生问题的主要原因:1.方洪波与南枫公司的直接主管李琼在合作共 ...
人力资源管理案例-左右为难的经理 -
吾名长弓:
学习了,作为一个管理新手,从文章里学到了很多东西,感谢 ...
2018新年管理感言 -
MyEyeOfJava:
非常不错,看过很多文章,说到管理者必然不能抛弃技术,我的主张是 ...
IT行业技术部门人员架构设计 -
小灯笼:
JMeter测试从入门到精通网盘地址:https://pan. ...
LR与Jmeter相关资料 -
flying6071:
“(2)CERT.SF:这是对摘要的签名文件。对前一步生成的M ...
Android签名与认证详细分析之一(CERT.RSA剖析)
Power Profiles for Android
IN THIS DOCUMENT
Battery Usage Statistics
Battery usage statistics are tracked by the framework. This involves keeping track of time spent by different device components in different states. This includes components such as WiFi chipset, Cellular Radio, Bluetooth, GPS, Display and CPU. When these components change state from off to on, or from idle to full power, low brightness to high brightness, etc., their controlling service reports to the framework’s BatteryStats service, which collects such information over time and persists to storage so that it is available across reboots.
The service isn’t keeping track of battery current draw information directly. It’s collecting mostly timing information so that it can be used to approximate battery consumption by different components.
Consumption of these resources is also (where possible) attributed to the applications using the resources, sometimes sharing the blame across multiple applications using a resource simultaneously. For instance, multiple apps could be holding wakelocks, keeping the system from going into suspend state. Blame is shared across these apps (not necessarily equally).
Statistics are persisted to flash periodically (approximately every half hour or so) to avoid losing the information on a shutdown (such as due to battery reaching zero remaining capacity, which may indicate a battery power consumption problem).
Statistics gathering can happen in two ways - push or pull. When services are aware of changes happening to a component, they will push state changes to the BatteryStats service. With components such as the CPU usage by apps, we pull the data periodically (at certain transition points such as starting or stopping an activity, etc) to take a snapshot.
All of the above is automatically done by the framework, and OEMs don’t need to do anything in addition to that.
Power Profile Values
The power profile is where the device manufacturer needs to provide current consumption values for various components and their states in order to approximate the actual battery drain caused by these components over time. The power consumption of a component is specified in units of milliamps (mA) of current draw (at a nominal voltage) in the power profile, and can be a fractional value specifying microamps. The value specified should be the mA consumed at the battery (and not a value applicable to a power rail that does not correspond to current consumed from the battery).
For instance, to attribute the cost of keeping the display on for a duration of time, the framework gathers brightness levels and times spent at each level (quantized to some number of bins). The power profile values specify how many milliamps of current are required to keep the display on at minimum brightness and at maximum brightness. The time spent at each brightness level can then be multiplied by an interpolated display brightness cost to compute an approximation of how much battery was drained by the display component.
Similarly, CPU time for each application is multiplied by the mA to keep the CPU running at a certain speed to get a comparative ranking of how much battery each app is consuming due to executing CPU code (time as the foreground app and total time including background activity are reported separately).
Computing power consumption for individual components
Note: manufacturers usually supply information about how much current an individual component consumes. It may be possible to use these values if they are an accurate representation of the the current drawn from the device’s battery in practice. However, we encourage you validate manufacturer-provided values before entering them in your device’s power profile.
Current consumption for an individual component is calculated by:
Measuring the current drawn by the device when the component is in the desired state (e.g., on, active, or scanning)
Measuring the current drawn by the device when the component is off
subtracting (2) from (1).
We recommend that you measure the current (usually the average instantaneous current) drawn on the device at a nominal voltage. This can be accomplished using a bench power supply or using specialized battery-monitoring tools (such as Monsoon Solution Inc.’s Power Monitor and Power Tool software).
Take the measurements with no external charger connected to the device, including no USB connection to a host (as used for connecting to development hosts via the adb Android Debug Bridge), which may draw current from the host and lower the measurements at the battery. If the device supports USB On The Go (OTG) then having an OTG device connected may draw additional power from the device being measured, so disconnect any such OTG device.
While taking measurements, you’ll want to try to keep the rest of the system other than the component being measured running at a constant level of power consumption, to avoid introducing inaccuracies in the measurements due to changes in other components. System activities that may introduce unwanted changes to power measurements include:
Cellular, Wi-Fi, and Bluetooth receive, transmit, or scanning activity. You may want to put the device into airplane mode when not measuring cell radio power, and individually enable Wi-Fi or Bluetooth when appropriate.
Screen/backlight on or off. The colors displayed while screen is on can also affect power draw on certain screen technologies. Measurements for components other than the screen on values should be made with screen turned off. But see the next item for an important consideration when the screen is off.
System suspended/resumed state. When the screen is off the system may enter a suspend state where much of the device may be powered off or placed in a low-power state, probably affecting power consumption of the component being measured and possibly introducing large variances in power readings as the system periodically resumes to service alarms and such. See Controlling and Measuring System Suspend State for more instructions.
CPUs changing speed and entering/exiting low-power scheduler idle state. The system may make frequent adjustments to the speeds of CPUs, how many CPU cores are online, and other system core state such as memory bus speed and voltages of power rails associated with CPUs and memory. If these are changing during your measurements then you may want to prevent CPU speed scaling operations, which may also reduce the amount of clock and voltage scaling of memory busses and other system core components. Scheduling activity may also affect what percentage of the time the CPUs spend in low-power idle states. See Controlling and Measuring CPU Speeds for more instructions.
For instance, to compute the value for screen.on, you would run the device in a stable state, with CPU speed held constant, device in airplane mode, with a partial wakelock held to prevent system suspend. The current readings in this state should be stable. Take the reading - say 200mA. Now turn on the screen at minimum brightness. If the power monitor shows 300mA, then screen.on = (300 - 200) = 100mA.
For components that don’t have a flat waveform of current consumption when active (such as the cellular radio or wifi), you may need to measure an average current over a period of time. Your power monitoring tool may be able to compute this average for you.
Replacing the battery with an external power source may require working around problems that can occur due to not connecting battery thermistor or integrated fuel gauge pins. For example, the system might take an invalid battery temperature reading or remaining battery capacity reading that could cause the kernel or Android system to shut down. Sometimes these problems are avoided through the use of “fake batteries” that replace normal batteries for power measurement purposes, constructed to match the dimensions and electrical properties of the batteries for the product being measured. Fake batteries can provide signals on thermistor or fuel gauge pins that mimic temperature and state of charge readings for a normally running system, and may also provide convenient leads for connecting to external power supplies. In other cases it may be easier to modify the system to ignore the invalid data from the missing battery.
Controlling and Measuring System Suspend State
As mentioned above, system suspend can introduce unwanted variance in power measurements and place system components in low power states not appropriate for measuring active power use. But at some point you’ll also need to measure the power draw of system suspend state. This section describes how to avoid system suspend state when you don’t want it to interfere with other measurements, and how to measure the power draw of system suspend state when you do want to measure it.
To avoid system suspend you can temporarily connect the device to a development host and issue the following command to hold a “partial wakelock”:
$ adb shell "echo temporary > /sys/power/wake_lock"
which will prevent the system from suspending while the screen is off. Disconnect the USB cable before making measurements.
You can undo the effect of this later with:
$ adb shell "echo temporary > /sys/power/wake_unlock"
The power consumption of the system suspend state is measured for the value of cpu.idle in the power profile. For this measurement it may be best to place the device in airplane mode to avoid any concurrent activity by the cellular radio, which may run on a processor separate from the portions of the SoC controlled by the system suspend. To ensure the measurement is made while the system is in the correct state, it may be necessary to first confirm the current readings settle to a steady value within the expected range for the consumption of the suspend state of the SoC entered plus the consumption of additional system components that remain powered (such as the USB PHY). A system console or other external indication of system status (such as turning off an LED when not in suspend) may also be observed during the measurement.
Controlling and Measuring CPU Speeds
While active, CPUs can be brought online or put offline, change clock speeds and associated voltages (possibly also affecting memory bus speeds and other system core power state), and can enter lower power idle states while in the kernel idle loop. Not only are these different CPU power states measured for the power profile, it may be necessary to avoid the power draw variance when measuring other parameters.
The power profile currently assumes all CPUs have the same available speeds and power characteristics.
While measuring CPU power, or holding CPU power constant in order to make other measurements, it may be best to hold the number of CPUs brought online constant, such as to have one CPU online and the rest offline / hotplugged out. Keeping all CPUs but one in scheduling idle may deliver acceptable results. Stopping the Android framework with adb shell stop can help reduce system scheduling activity.
You’ll specify the available CPU speeds for your device in the power profile cpu.speeds entry. You can get a list of these using
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
These speeds are matched with their corresponding power measurements in value cpu.active.
If your platform’s power consumption is significantly affected by how many cores are brought online then you may need to modify the cpufreq driver or governor for your platform to control this. For many platforms, the easiest way to control CPU speed is to use the “userspace” cpufreq governor and use sysfs interfaces to set the speed. The exact commands differ depending on your platform’s cpufreq implementation. The following commands from the system console or adb shell could be used to set a speed for 200MHz on a system with only 1 CPU, or all CPUs sharing a common cpufreq policy:
echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
which makes sure the new speed is not outside the allowed bounds, sets the new speed, and then prints which speed the CPU is actually running at for verification. (If the current minimum speed prior to executing the above is above 200000, you may have to reverse the order of the first two lines, or execute the first line again, to drop the minimum speed prior to setting the maximum speed.)
To measure current consumed by a CPU while running at various speeds, you may need to place a CPU in a CPU-bound loop such as:
# while true; do true; done
on the system console and take the measurement while the above runs.
If your device may limit maximum CPU speed while thermal throttling due to a high temperature measurement, possibly as a result of running CPUs at high speeds for sustained periods, then watch out for this while taking measurements. You may need to watch system console output, or check the kernel log after measuring.
For the cpu.active value you can measure the power consumed when the system is not in suspend but not executing tasks. The CPU should be in a low-power scheduler “idle loop”, possibly executing an ARM Wait For Event instruction or in an SoC-specific low power state with a fast exit latency suitable for idle use. There may be more than one idle state in use on your platform with differing levels of power consumption; choose a representative idle state for longer periods of scheduler idle (several milliseconds). You may need to examine the power graph on your measurement equipment and choose samples where the CPU is at its lowest consumption, discarding higher samples where the CPU exited idle.
Measuring Screen Power
Screen on power is typically measured with all other devices that are turned on with the screen also enabled. For example, the touchscreen and any display backlight would normally also be turned on during the measurement, to get a more realistic example of screen on power usage.
Some display technologies vary in power consumption according to the colors displayed, and so power measurements may vary considerably depending on what is on the screen at the time. It’s best to choose to display something that has power characteristics of a realistic screen, somewhere between the extremes of an all-black screen (which consumes the lowest power for some technologies) and an all-white screen. A common choice is a view of a schedule in the calendar app, which has a mix of white background and non-white elements.
The cost of having the screen on is measured at two points: at minimum display/backlight brightness, and at maximum brightness. Setting the display brightness to minimum using the Settings app Display Brightness slider might not produce accurate results. The Android UI will typically only allow you to set the brightness to a minimum of about 10-20% of the possible panel/backlight brightness -- it doesn't allow the user to set brightness so low that the screen might not be visible without great effort. If you have a sysfs file that controls panel brightness all the way down to the minimum brightness supported by the hardware then that's even better.
If your platform provides sysfs files that turns the LCD panel, backlight, and touchscreen on and off then that’s a good way to take measurements with the screen on and off. Otherwise, holding a partial wakelock so the system doesn't go to suspend, and turning on and off the screen with the power button, should be fine.
Measuring Wi-Fi Power
It’s recommended to perform Wi-Fi measurements on a relatively quiet network, without introducing a lot of additional work processing high volumes of broadcast traffic unrelated to the activity being measured.
The wifi.on value measures the power consumed when Wi-Fi is enabled but not actively transmitting or receiving. This is often measured as the delta between the current draw in system suspend (sleep) state with Wi-Fi enabled vs. disabled.
The wifi.scan value measures the power consumed during a Wi-Fi scan for access points. Wi-Fi scans can be triggered by an app using the WifiManager class startScan() API, which is documented at http://developer.android.com/reference/android/net/wifi/WifiManager.html . You can also open Settings > Wi-Fi, which will perform scans for access points every few seconds with an apparent jump in power consumption, but the screen power must be subtracted from these measurements.
Network receive and transmit traffic can be generated using controlled setup such as iperf if desired.
List of values and their meaning
Name Meaning Example value Notes
none Nothing 0
screen.on Additional power used when screen is turned on at minimum brightness 200mA Includes touch controller and display backlight. At 0 brightness, not the Android minimum which tends to be 10 or 20%.
screen.full Additional power used when screen is at maximum brightness, compared to screen at minimum brightness 100- 300mA A fraction of this value (based on screen brightness) is added to the screen.on value to compute the power usage of the screen.
bluetooth.active Additional power used when playing audio through bluetooth A2DP 14mA
bluetooth.on Additional power used when bluetooth is turned on but idle 1.4mA
wifi.on Additional power used when wifi is turned on but not receiving, transmitting, or scanning 2mA
wifi.active Additional power used when transmitting or receiving over Wifi 31mA
wifi.scan Additional power used when wifi is scanning for access points 100mA
dsp.audio Additional power used when audio decoding/encoding via DSP 14.1mA Not currently used
dsp.video Additional power used when video decoding via DSP 54mA Not currently used
gps.on Additional power used when GPS is acquiring a signal 50mA
radio.active Additional power used when cellular radio is transmitting/receiving 100- 300mA
radio.scanning Additional power used when cellular radio is paging the tower 1.2mA
radio.on Additional power used when the cellular radio is on. This is a multi-value entry, one per signal strength (no signal, weak, moderate, strong) 1.2mA Some radios boost up their power when there’s no signal and they’re trying to find a cell tower. So these numbers could all be the same or decreasing with increasing signal strength. If you provide only one value, the same value will be used for all strengths. If you provide 2 values, the first will be for no-signal and the second for all other strengths, and so on.
cpu.speeds Multi-value entry that lists each possible CPU speed in KHz 125000, 250000, 500000, 1000000, 1500000 The number and order of entries need to correspond to the mA entries in cpu.active
cpu.idle Total power drawn by the system when CPUs (and the SoC) are in system suspend state 3mA
cpu.awake Additional power used when CPUs are in scheduling idle state (kernel idle loop); system is not in system suspend state 50mA
cpu.active Additional power used by CPUs when running at different speeds 100, 120, 140, 160, 200 Set the max speed in the kernel to each of the allowed speeds and peg the CPU at that speed. The number of entries here correspond to the number of entries in cpu.speeds, in the same order.
battery.capacity The total battery capacity in mAh 3000mAh
The power_profile.xml file is placed in an overlay in device///frameworks/base/core/res/res/xml/power_profile.xml
Sample file
没有编辑格式,原文地址:https://source.android.com/devices/tech/power.html
IN THIS DOCUMENT
Battery Usage Statistics Power Profile Values Computing power consumption for individual components Controlling and Measuring System Suspend State Controlling and Measuring CPU Speeds Measuring Screen Power Measuring Wi-Fi Power List of values and their meaning Sample file Battery usage information is derived from battery usage statistics and power profile values.
Battery Usage Statistics
Battery usage statistics are tracked by the framework. This involves keeping track of time spent by different device components in different states. This includes components such as WiFi chipset, Cellular Radio, Bluetooth, GPS, Display and CPU. When these components change state from off to on, or from idle to full power, low brightness to high brightness, etc., their controlling service reports to the framework’s BatteryStats service, which collects such information over time and persists to storage so that it is available across reboots.
The service isn’t keeping track of battery current draw information directly. It’s collecting mostly timing information so that it can be used to approximate battery consumption by different components.
Consumption of these resources is also (where possible) attributed to the applications using the resources, sometimes sharing the blame across multiple applications using a resource simultaneously. For instance, multiple apps could be holding wakelocks, keeping the system from going into suspend state. Blame is shared across these apps (not necessarily equally).
Statistics are persisted to flash periodically (approximately every half hour or so) to avoid losing the information on a shutdown (such as due to battery reaching zero remaining capacity, which may indicate a battery power consumption problem).
Statistics gathering can happen in two ways - push or pull. When services are aware of changes happening to a component, they will push state changes to the BatteryStats service. With components such as the CPU usage by apps, we pull the data periodically (at certain transition points such as starting or stopping an activity, etc) to take a snapshot.
All of the above is automatically done by the framework, and OEMs don’t need to do anything in addition to that.
Power Profile Values
The power profile is where the device manufacturer needs to provide current consumption values for various components and their states in order to approximate the actual battery drain caused by these components over time. The power consumption of a component is specified in units of milliamps (mA) of current draw (at a nominal voltage) in the power profile, and can be a fractional value specifying microamps. The value specified should be the mA consumed at the battery (and not a value applicable to a power rail that does not correspond to current consumed from the battery).
For instance, to attribute the cost of keeping the display on for a duration of time, the framework gathers brightness levels and times spent at each level (quantized to some number of bins). The power profile values specify how many milliamps of current are required to keep the display on at minimum brightness and at maximum brightness. The time spent at each brightness level can then be multiplied by an interpolated display brightness cost to compute an approximation of how much battery was drained by the display component.
Similarly, CPU time for each application is multiplied by the mA to keep the CPU running at a certain speed to get a comparative ranking of how much battery each app is consuming due to executing CPU code (time as the foreground app and total time including background activity are reported separately).
Computing power consumption for individual components
Note: manufacturers usually supply information about how much current an individual component consumes. It may be possible to use these values if they are an accurate representation of the the current drawn from the device’s battery in practice. However, we encourage you validate manufacturer-provided values before entering them in your device’s power profile.
Current consumption for an individual component is calculated by:
Measuring the current drawn by the device when the component is in the desired state (e.g., on, active, or scanning)
Measuring the current drawn by the device when the component is off
subtracting (2) from (1).
We recommend that you measure the current (usually the average instantaneous current) drawn on the device at a nominal voltage. This can be accomplished using a bench power supply or using specialized battery-monitoring tools (such as Monsoon Solution Inc.’s Power Monitor and Power Tool software).
Take the measurements with no external charger connected to the device, including no USB connection to a host (as used for connecting to development hosts via the adb Android Debug Bridge), which may draw current from the host and lower the measurements at the battery. If the device supports USB On The Go (OTG) then having an OTG device connected may draw additional power from the device being measured, so disconnect any such OTG device.
While taking measurements, you’ll want to try to keep the rest of the system other than the component being measured running at a constant level of power consumption, to avoid introducing inaccuracies in the measurements due to changes in other components. System activities that may introduce unwanted changes to power measurements include:
Cellular, Wi-Fi, and Bluetooth receive, transmit, or scanning activity. You may want to put the device into airplane mode when not measuring cell radio power, and individually enable Wi-Fi or Bluetooth when appropriate.
Screen/backlight on or off. The colors displayed while screen is on can also affect power draw on certain screen technologies. Measurements for components other than the screen on values should be made with screen turned off. But see the next item for an important consideration when the screen is off.
System suspended/resumed state. When the screen is off the system may enter a suspend state where much of the device may be powered off or placed in a low-power state, probably affecting power consumption of the component being measured and possibly introducing large variances in power readings as the system periodically resumes to service alarms and such. See Controlling and Measuring System Suspend State for more instructions.
CPUs changing speed and entering/exiting low-power scheduler idle state. The system may make frequent adjustments to the speeds of CPUs, how many CPU cores are online, and other system core state such as memory bus speed and voltages of power rails associated with CPUs and memory. If these are changing during your measurements then you may want to prevent CPU speed scaling operations, which may also reduce the amount of clock and voltage scaling of memory busses and other system core components. Scheduling activity may also affect what percentage of the time the CPUs spend in low-power idle states. See Controlling and Measuring CPU Speeds for more instructions.
For instance, to compute the value for screen.on, you would run the device in a stable state, with CPU speed held constant, device in airplane mode, with a partial wakelock held to prevent system suspend. The current readings in this state should be stable. Take the reading - say 200mA. Now turn on the screen at minimum brightness. If the power monitor shows 300mA, then screen.on = (300 - 200) = 100mA.
For components that don’t have a flat waveform of current consumption when active (such as the cellular radio or wifi), you may need to measure an average current over a period of time. Your power monitoring tool may be able to compute this average for you.
Replacing the battery with an external power source may require working around problems that can occur due to not connecting battery thermistor or integrated fuel gauge pins. For example, the system might take an invalid battery temperature reading or remaining battery capacity reading that could cause the kernel or Android system to shut down. Sometimes these problems are avoided through the use of “fake batteries” that replace normal batteries for power measurement purposes, constructed to match the dimensions and electrical properties of the batteries for the product being measured. Fake batteries can provide signals on thermistor or fuel gauge pins that mimic temperature and state of charge readings for a normally running system, and may also provide convenient leads for connecting to external power supplies. In other cases it may be easier to modify the system to ignore the invalid data from the missing battery.
Controlling and Measuring System Suspend State
As mentioned above, system suspend can introduce unwanted variance in power measurements and place system components in low power states not appropriate for measuring active power use. But at some point you’ll also need to measure the power draw of system suspend state. This section describes how to avoid system suspend state when you don’t want it to interfere with other measurements, and how to measure the power draw of system suspend state when you do want to measure it.
To avoid system suspend you can temporarily connect the device to a development host and issue the following command to hold a “partial wakelock”:
$ adb shell "echo temporary > /sys/power/wake_lock"
which will prevent the system from suspending while the screen is off. Disconnect the USB cable before making measurements.
You can undo the effect of this later with:
$ adb shell "echo temporary > /sys/power/wake_unlock"
The power consumption of the system suspend state is measured for the value of cpu.idle in the power profile. For this measurement it may be best to place the device in airplane mode to avoid any concurrent activity by the cellular radio, which may run on a processor separate from the portions of the SoC controlled by the system suspend. To ensure the measurement is made while the system is in the correct state, it may be necessary to first confirm the current readings settle to a steady value within the expected range for the consumption of the suspend state of the SoC entered plus the consumption of additional system components that remain powered (such as the USB PHY). A system console or other external indication of system status (such as turning off an LED when not in suspend) may also be observed during the measurement.
Controlling and Measuring CPU Speeds
While active, CPUs can be brought online or put offline, change clock speeds and associated voltages (possibly also affecting memory bus speeds and other system core power state), and can enter lower power idle states while in the kernel idle loop. Not only are these different CPU power states measured for the power profile, it may be necessary to avoid the power draw variance when measuring other parameters.
The power profile currently assumes all CPUs have the same available speeds and power characteristics.
While measuring CPU power, or holding CPU power constant in order to make other measurements, it may be best to hold the number of CPUs brought online constant, such as to have one CPU online and the rest offline / hotplugged out. Keeping all CPUs but one in scheduling idle may deliver acceptable results. Stopping the Android framework with adb shell stop can help reduce system scheduling activity.
You’ll specify the available CPU speeds for your device in the power profile cpu.speeds entry. You can get a list of these using
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
These speeds are matched with their corresponding power measurements in value cpu.active.
If your platform’s power consumption is significantly affected by how many cores are brought online then you may need to modify the cpufreq driver or governor for your platform to control this. For many platforms, the easiest way to control CPU speed is to use the “userspace” cpufreq governor and use sysfs interfaces to set the speed. The exact commands differ depending on your platform’s cpufreq implementation. The following commands from the system console or adb shell could be used to set a speed for 200MHz on a system with only 1 CPU, or all CPUs sharing a common cpufreq policy:
echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
which makes sure the new speed is not outside the allowed bounds, sets the new speed, and then prints which speed the CPU is actually running at for verification. (If the current minimum speed prior to executing the above is above 200000, you may have to reverse the order of the first two lines, or execute the first line again, to drop the minimum speed prior to setting the maximum speed.)
To measure current consumed by a CPU while running at various speeds, you may need to place a CPU in a CPU-bound loop such as:
# while true; do true; done
on the system console and take the measurement while the above runs.
If your device may limit maximum CPU speed while thermal throttling due to a high temperature measurement, possibly as a result of running CPUs at high speeds for sustained periods, then watch out for this while taking measurements. You may need to watch system console output, or check the kernel log after measuring.
For the cpu.active value you can measure the power consumed when the system is not in suspend but not executing tasks. The CPU should be in a low-power scheduler “idle loop”, possibly executing an ARM Wait For Event instruction or in an SoC-specific low power state with a fast exit latency suitable for idle use. There may be more than one idle state in use on your platform with differing levels of power consumption; choose a representative idle state for longer periods of scheduler idle (several milliseconds). You may need to examine the power graph on your measurement equipment and choose samples where the CPU is at its lowest consumption, discarding higher samples where the CPU exited idle.
Measuring Screen Power
Screen on power is typically measured with all other devices that are turned on with the screen also enabled. For example, the touchscreen and any display backlight would normally also be turned on during the measurement, to get a more realistic example of screen on power usage.
Some display technologies vary in power consumption according to the colors displayed, and so power measurements may vary considerably depending on what is on the screen at the time. It’s best to choose to display something that has power characteristics of a realistic screen, somewhere between the extremes of an all-black screen (which consumes the lowest power for some technologies) and an all-white screen. A common choice is a view of a schedule in the calendar app, which has a mix of white background and non-white elements.
The cost of having the screen on is measured at two points: at minimum display/backlight brightness, and at maximum brightness. Setting the display brightness to minimum using the Settings app Display Brightness slider might not produce accurate results. The Android UI will typically only allow you to set the brightness to a minimum of about 10-20% of the possible panel/backlight brightness -- it doesn't allow the user to set brightness so low that the screen might not be visible without great effort. If you have a sysfs file that controls panel brightness all the way down to the minimum brightness supported by the hardware then that's even better.
If your platform provides sysfs files that turns the LCD panel, backlight, and touchscreen on and off then that’s a good way to take measurements with the screen on and off. Otherwise, holding a partial wakelock so the system doesn't go to suspend, and turning on and off the screen with the power button, should be fine.
Measuring Wi-Fi Power
It’s recommended to perform Wi-Fi measurements on a relatively quiet network, without introducing a lot of additional work processing high volumes of broadcast traffic unrelated to the activity being measured.
The wifi.on value measures the power consumed when Wi-Fi is enabled but not actively transmitting or receiving. This is often measured as the delta between the current draw in system suspend (sleep) state with Wi-Fi enabled vs. disabled.
The wifi.scan value measures the power consumed during a Wi-Fi scan for access points. Wi-Fi scans can be triggered by an app using the WifiManager class startScan() API, which is documented at http://developer.android.com/reference/android/net/wifi/WifiManager.html . You can also open Settings > Wi-Fi, which will perform scans for access points every few seconds with an apparent jump in power consumption, but the screen power must be subtracted from these measurements.
Network receive and transmit traffic can be generated using controlled setup such as iperf if desired.
List of values and their meaning
Name Meaning Example value Notes
none Nothing 0
screen.on Additional power used when screen is turned on at minimum brightness 200mA Includes touch controller and display backlight. At 0 brightness, not the Android minimum which tends to be 10 or 20%.
screen.full Additional power used when screen is at maximum brightness, compared to screen at minimum brightness 100- 300mA A fraction of this value (based on screen brightness) is added to the screen.on value to compute the power usage of the screen.
bluetooth.active Additional power used when playing audio through bluetooth A2DP 14mA
bluetooth.on Additional power used when bluetooth is turned on but idle 1.4mA
wifi.on Additional power used when wifi is turned on but not receiving, transmitting, or scanning 2mA
wifi.active Additional power used when transmitting or receiving over Wifi 31mA
wifi.scan Additional power used when wifi is scanning for access points 100mA
dsp.audio Additional power used when audio decoding/encoding via DSP 14.1mA Not currently used
dsp.video Additional power used when video decoding via DSP 54mA Not currently used
gps.on Additional power used when GPS is acquiring a signal 50mA
radio.active Additional power used when cellular radio is transmitting/receiving 100- 300mA
radio.scanning Additional power used when cellular radio is paging the tower 1.2mA
radio.on Additional power used when the cellular radio is on. This is a multi-value entry, one per signal strength (no signal, weak, moderate, strong) 1.2mA Some radios boost up their power when there’s no signal and they’re trying to find a cell tower. So these numbers could all be the same or decreasing with increasing signal strength. If you provide only one value, the same value will be used for all strengths. If you provide 2 values, the first will be for no-signal and the second for all other strengths, and so on.
cpu.speeds Multi-value entry that lists each possible CPU speed in KHz 125000, 250000, 500000, 1000000, 1500000 The number and order of entries need to correspond to the mA entries in cpu.active
cpu.idle Total power drawn by the system when CPUs (and the SoC) are in system suspend state 3mA
cpu.awake Additional power used when CPUs are in scheduling idle state (kernel idle loop); system is not in system suspend state 50mA
cpu.active Additional power used by CPUs when running at different speeds 100, 120, 140, 160, 200 Set the max speed in the kernel to each of the allowed speeds and peg the CPU at that speed. The number of entries here correspond to the number of entries in cpu.speeds, in the same order.
battery.capacity The total battery capacity in mAh 3000mAh
The power_profile.xml file is placed in an overlay in device///frameworks/base/core/res/res/xml/power_profile.xml
Sample file
<!-- Most values are the incremental current used by a feature, in mA (measured at nominal voltage). OEM's must measure and provide actual values before shipping a device. Example real-world values are given, but they are totally dependent on the platform and can vary significantly, so should be measured on the shipping platform with a power meter. --> 0 200 160 10 <!-- Bluetooth stereo audio playback 10.0 mA --> 1.3 0.5 30 100 12 50 50 75 1.1 <!-- Strength 0 to BINS-1 (4) --> 1.1 <!-- Different CPU speeds as reported in /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state --> 250000 500000 750000 1000000 1200000 <!-- Power consumption when CPU is idle --> 3.0 50.1 <!-- Power consumption at different speeds --> 100 <!-- 250 MHz --> 120 <!-- 500 MHz --> 140 <!-- 750 MHz --> 155 <!-- 1 GHz --> 175 <!-- 1.2 GHz --> <!-- This is the battery capacity in mAh --> 3000 <!-- Battery capacity is 3000 mAH (at 3.6 Volts) -->
没有编辑格式,原文地址:https://source.android.com/devices/tech/power.html
发表评论
-
[ATC]Facebook开源弱网模拟工具
2016-03-26 14:24 2704需要注意如下:1.笔者使用了linux USB网卡,是让 ... -
【远程真机管理】openstf
2016-03-24 11:36 2926网站地址:https://github.com/ope ... -
AndroidStudio性能优化
2016-03-15 16:39 1145Android Studio慢、吃内存!启动时后会立即通过Gr ... -
Drozer使用手册
2016-01-18 15:22 2224Drozer ⼯具的安装与启动:源码地址(https:// ... -
TCPDUMP抓包
2015-12-17 20:56 778tcpdump 使用方法:唯有使用文章描述的参数移动手机的 ... -
HTML5安全
2015-10-30 19:43 1319移动安全问题汇总:htt ... -
Android插件DSL配置文档
2015-07-29 15:54 1024Android Plugin DSL Reference -
Gradle-Android打包文档
2015-07-29 15:29 1819http://tools.android.com/tech- ... -
Android性能优化典范(一)
2015-06-02 17:26 13122015年伊始,Google发布 ... -
Android性能系列-电量篇
2015-05-29 16:28 1343电量篇 1) Understanding Battery ... -
Android性能系列-内存篇
2015-05-29 16:27 823内存篇 1) Memory, GC, and Perfor ... -
Android性能系列-运算篇
2015-05-29 16:26 579运算篇 1) Intro to Compute ... -
Android性能系列-渲染篇
2015-05-29 16:25 834Google近期在Udacity上发布了Android性能优 ... -
如何通过wifi在android手机上安装调试应用
2015-05-29 14:42 7011. 首先还是要打开手机 ... -
[Android]解决android65K方法引用限制
2015-01-14 11:39 1621解决方案如下: 1.Google官方的andr ... -
[Android]获取整体APP CPU信息
2015-01-07 14:34 4787通过proc获取CPU信息。adb shell cat / ... -
genymotion-安卓模拟器-IMEI修改方法
2015-01-05 15:44 4414看淘宝动辄就几十元卖这么个破玩意儿,实在是懒得说什么了,人总 ... -
[android]创建固定大小文件
2014-12-29 19:27 2206dd if=/dev/zero of=yourfile ... -
[总结]无线测试
2014-12-18 16:33 1142本文主要介绍测试在项目的各个阶段应该要做的事情、使用的工具和 ... -
[适配性]移动Webapp自适应方案
2014-12-18 16:15 1869此次方案的优化点 页面元素会随宽度的变化而自适应的放大 ...
相关推荐
Android Studio 创建指dpi的模拟器的 device.xml 资源 ...下载完成后,可以根据自己的需求,进行修改,修改完成后再 Android studio中的Device Manager中, 点击Import Hardware Profiles,导入即可。
在无线通信领域,"Power Delay Profile"(功率延迟剖面)是分析信号传播特性的重要概念。这个主题主要涉及信号在传播过程中的能量分布以及不同路径到达接收器的时间差。通过模拟"power delay profile",我们可以深入...
PULL(Pull Parsing for XML)是Android特有的一种轻量级解析方式,类似于SAX,也是事件驱动的,但使用API更加简洁。PULL解析器允许开发者创建一个解析器实例,然后通过调用next()方法逐步推进解析过程,处理遇到的...
Post processing 3 profiles for PC/Mac and Mobile 21 different settings for Post Processing V3. With the help of these settings you could get realistic graphics just in few clicks. Effects: UE, Cry, ...
**CXMLProfile 简介** CXMLProfile 是一个针对应用程序的简单XML配置文件处理库,它使得在C++项目中使用XML配置文件变得更加容易。这个库的主要目标是提供一个轻量级、易于理解和使用的解决方案,让开发者可以方便...
CiA 408 DS V1.5.2: CANopen profile fluid power technology proportional valves and hydraulic transmissions IGCO_408_v01050202.pdf CiA 410 DS V1.3: CANopen profile for inclinometer IGCO_410_v01030000....
当我们进行自动化测试时,Maven的profiles功能可以帮助我们根据不同的环境设置来构建和运行测试。本篇文章将详细探讨如何在Idea中配置Maven的profiles以实现test自动测试。 首先,让我们理解什么是Maven的profiles...
Tasker For Android 使用教程综述 Tasker 是 Android 系统上的一个真正的神器,它是一款系统增强型的软件,能够控制多个系统状态,成为 Android 系统中最闪亮的明星。 Tasker 的功能极其强大,但同时也使得它变得...
整理了android高通平台蓝牙所支持的功能profile,根据BQB认证需求,关闭和打开部分profile。
Post processing 3 profiles for PC/Mac and Mobile 21 different settings for Post Processing V3. With the help of these settings you could get realistic graphics just in few clicks. Effects: UE, Cry, ...
同样地,打开 PowerBuilder 并进入 Database Profiles 界面。 ##### 第二步:选择 ODBC 配置 在列表中找到“ODBC”配置项,并双击它以进行编辑。 ##### 第三步:创建新的连接配置 点击“New...”按钮,打开...
`profiles`是Maven配置中的一个重要概念,它允许我们在不同的环境中使用不同的构建设置。本示例将详细介绍`profiles`的使用及其在实际项目中的应用。 `profiles`在Maven中的作用主要体现在以下几点: 1. **环境...
Wifi Key View for Android (root required) No ads. No unnecessary permissions. Clear style. Open-source. This app displays all the wireless passwords and their associated name (SSID) stored on your ...
行业调查报告 、研究报告
在iOS应用开发过程中,高效的打包和发布流程是至关重要的。"ios打包下载脚本" 提供了一种自动化的方法,使得开发者能够快速地将应用打包并上传到第三方分发平台如fir.im和蒲公英,以便进行内部测试或Alpha/Beta测试...
Tool_for_visualizing_GitHub_profiles_profile-summary-for-github
Advanced Gradle for Android Tips Testing with JUnit4 Testing with UI Automator Measuring Test Coverage Unit Testing MonkeyRunner and the Test Monkey Notifications Advanced Notifications Introducing ...
profiles_settings.xml