Provisioning of energy consumption information for mobile ads

Accepted Manuscript Provisioning of energy consumption information for mobile ads Seokjun Lee, Minyoung Go, Rhan Ha, Hojung Cha

PII: DOI: Reference:

S1574-1192(18)30081-6 https://doi.org/10.1016/j.pmcj.2019.01.002 PMCJ 990

To appear in:

Pervasive and Mobile Computing

Received date : 12 February 2018 Revised date : 24 December 2018 Accepted date : 9 January 2019 Please cite this article as: S. Lee, M. Go, R. Ha et al., Provisioning of energy consumption information for mobile ads, Pervasive and Mobile Computing (2019), https://doi.org/10.1016/j.pmcj.2019.01.002 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

Pervasive and Mobile Computing

Contents lists available at ScienceDirect

Pervasive and Mobile Computing jour nal homepage: www.elsevier.com/locate/pmc

Provisioning of energy consumption information for mobile ads Contents lists available at ScienceDirect a

Seokjun Lee , Minyoung Goa, Rhan Hab, Hojung Chaa,* Pervasive and Mobile Computing a b

Department of Computer Science, Yonsei University, Seoul, Republic of Korea Department of Computer Engineering, Seoul, j o u r n a l hHongik o m e pUniversity, age:www . e l s eRepublic v i e r . c oofmKorea /locate/pmc

A R T I C L E Article history: Submitted

Keywords: Mobile advertisement Energy consumption System API

I N F O

A B S T R A C T Advertisement-embedded mobile applications have been reported to consume a non-trivial amount of energy. Although a few studies have focused on the energy consumption of mobile advertisements (ads), no previous work has addressed the mobile ad ecosystem, which consists of users, application developers, and ad providers. In this paper, we define the advertisement energy information (AEI) required for the mobile ad ecosystem, and we propose a set of application programming interfaces (APIs) to provide AEI that considers various requirements of the underlying ecosystem. To realize the APIs, we developed a system service in Android to collect the AEI accurately and with low overhead. The experiment results show the validity of the proposed scheme, and the case studies demonstrate the usefulness of the proposed APIs.

1. Introduction In recent years, the mobile application market has grown rapidly. More than three million applications have been released on Google Play, and each user typically installs dozens of applications on his or her device. Accordingly, mobile advertisements (ads), which are currently used in more than half of all mobile applications [1], have become an important factor in the mobile application market. In 2016 alone, $101 billion was spent in the mobile ad market, which is 51% of the overall digital ad market [2].

* Corresponding author. Tel.: +82 2 2123 5711; E-mail: [email protected].

Pervasive and Mobile Computing

Mobile ads create an ecosystem of their own, where the advertisement provider (the ad provider), application developers, and users are the key players. The ad provider, such as AdMob or Facebook, provides ads on behalf of advertisers and gets a fee in return. Application developers put ads in their applications using the application programming interface (API) of the provider’s library and then are paid based on the users’ click counts or the duration of exposure. Users are able to download ad-embedded applications for free. This way, the ad providers and the application developers profit without end users being involved, and thus, the overall ecosystem works seamlessly. However, the ecosystem has hidden costs. Mobile ads generally degrade the users’ quality of experience (QoE) by occupying certain areas of the display screen, often leading to negative reviews for the applications [3]. Network traffic also increases because of the load from the ads’ content [4]. Moreover, mobile ads are reported to consume approximately 15% of an application’s overall energy consumption [3]. Despite the substantial energy consumption by mobile ads, the current ecosystem does not consider energy to be an important factor. When a mobile ad consumes a large amount of energy, the ad-embedded application is reported to be energy hungry. Then, users avoid using the application, and perhaps leave low ratings and negative reviews. This means the application developers may consider working with other ad providers to reduce energy consumption. Consequently, the energy consumption of mobile ads plays an important role in the mobile ad ecosystem and should be considered accordingly. Providing energy information for a mobile ad, called advertisement energy information (AEI) hereafter, is not easy because each player in the ecosystem has different interests. For example, users could use the AEI to select energy-efficient applications, and application developers could determine, based on the AEI, the ad type (e.g., image or video) or even the ad provider. Users require application-level AEI, whereas application developers need finegrained AEI, such as the energy difference between an image and a video or the energy consumption according to the image size. From the ad provider’s perspective, energy information about their libraries is required so that the ad providers can improve the energy efficiency or determine billing policies. Overall, AEI details should be provided at various levels, considering the many factors needed by each player in the ecosystem. Attempts have been made to provide AEI [5,6]. Previous works, however, mostly focused on application-level AEI, which is not sufficient for application developers and ad providers. Although Pathak et al. [7] calculated AEI based on a method-

Pervasive and Mobile Computing

level energy estimate, the scheme is not useful for providing a detailed level of AEI because of the lack of consideration for various types of ad-specific information. In this paper, we propose a set of APIs that can provide AEI for mobile ads while considering the various requirements of the underlying ecosystem. To this end, we first define the types of AEI needed for each player in the ecosystem. We then implement the system to trace ads embedded in the application with low overhead at runtime, and subsequently, we generate the AEI. Realizing the proposed APIs involves several challenges. First, we must define the types of AEI that are required by users, application developers, and ad providers. For this study, we empirically observed the relation between an ad’s features and its energy consumption and then designed APIs based on this observation. Second, ad operations should be traced accurately at run-time with low overhead. To acquire highly accurate AEI, various types of information should be monitored, such as the start point, end point, workload generated by the ad, and so on. Moreover, the system should work at run-time because the AEI is affected by dynamic factors, such as the network condition or the usage pattern. We developed a system that could monitor the ad operation accurately at run-time and with low overhead. Finally, the ad’s actual energy consumption should be estimated accurately. To this end, we modified the Android framework and its kernel to collect hardware usage, and we applied a utilization-based energy estimation method [8]. The contributions of this work are the following: 

We defined the AEI required for the mobile ad ecosystem and designed APIs for the relevant type of AEI.



We implemented the system to trace ad operations accurately and estimate AEI with low overhead.

2. API for ad energy information We analyzed the factors that contribute to an ad’s energy consumption on a mobile device. In our work, the energy consumption of an ad is defined as the sum of energy used by the CPU, GPU, and network interface of the mobile device. These are the main power sources that are required to display ads on the networked device. Note that other hardware components that have little impact on energy are excluded, and the uncontrollable environmental factors are excluded as well.

Pervasive and Mobile Computing

To develop the APIs so that they provide AEI, the requirements of the mobile ad ecosystem must be understood a priori. We experimentally observed the key factors of the AEI of a mobile ad and designed the APIs considering four levels of AEI: app, ad library, ad type, and ad features.

2.1.

Advertisement energy information App level. Application-level AEI is helpful for users, application developers, and ad providers. Thus, this

information is a key component of AEI. With AEI, users can select energy-efficient applications, and application developers can improve the energy efficiency of their applications. Ad providers are also able to determine the revenue model for application developers by showing the ad’s energy information. Ad library level. This level of energy information is required by application developers and ad providers. Application developers are able to select an appropriate ad library by considering tradeoffs between the revenue and the energy consumption of each ad library. Ad providers also assess the energy information of their own ads and accordingly, optimize the ad library based on comparative results with other libraries. Ad type level. Various types of mobile ads exist, such as image, video, interactive, and native1. In general, the revenue and energy consumption factors differ considerably depending on the ad type. For example, an image ad consumes less power than a video-playing ad, but the revenue from an image is typically lower than for a video. Ad-type AEI helps application developers consider the tradeoffs between energy consumption and revenue for each ad type. Ad providers are also able to determine the fee and revenue for each ad type, reflecting its energy consumption. Ad feature level. The ad library supports various features for each ad type, such as the image size and the refresh rate for image ads and the video size, frame per second (FPS), and playing time for video ads. An ad’s energy consumption depends on these features. Therefore, AEI about ad features is needed by application developers and ad providers. Table 1 summarizes the ad types and ad features for typical mobile ads.

1

The native ad means the ad customized by developers. For example, the Facebook application customizes its ad to look like it is being uploaded by the user.

Pervasive and Mobile Computing

Table 1. Ad types and ad features. Ad Type Description Features Image Ads with a static image showing banners and full-page ads Size and Refresh rate Video Video ads without user interactions Size, FPS, and Time Interactive Ads with user interaction: touching, swiping, and so on Size, FPS, Number of {touch, swipe, tilt}, and Time Native Ads that can be customized by the app developer N/A Others. In addition to the AEI above, other factors, such as the device model and the network condition, affect an ad’s energy consumption. In addition, the ad’s content impacts the ad’s energy consumption. For example, on an OLED device, a banner with a black image consumes less energy than one with a white image. In this work, we do not consider the device, network, and content factors regarding an ad’s energy consumption because they cannot be controlled in the proposed framework.

2.2.

API design The goal of the proposed APIs is to provide various levels of AEI. To this end, we designed APIs using Java

with two principles. First, the APIs should provide AEI in various forms to satisfy the mobile ad ecosystem. Second, the APIs should be easy to interpret and use [9]. Table 2 lists the proposed APIs. The APIs consist of three classes: AEIBuilder, AdMonitor, and AdAnalyzer. AEIBuilder is used to set the target parameters for the AEI. The builder design pattern [10] is adopted for AEIBuilder because the scheme sets various parameters easily. AdMonitor provides various levels of AEI. The energy consumption of videos and interactive ads is represented in joules because the ads are limited by playing time. An image ad is simply accessed by the average power consumption in milliwatts. Meanwhile, a power trace is required to analyze the temporal trend of an ad’s power consumption or energy difference according to the ad’s features. Therefore, the proposed APIs provide the energy consumption, average power consumption, and power trace. In addition, AEI should be collected from real users for an accurate estimation of an ad’s energy efficiency. The data should be processed on a server rather than on a mobile device to minimize battery consumption. As the proposed system sends only the accumulated energy information to the server, the energy overhead due to log transmission is trivial. The getJsonDump function provides the AEI data in the form of JSON.

Pervasive and Mobile Computing

Table 2. APIs for AEI. Class APIs AEIBuilder setApp(String name) AEIBuilder setLib(enum lib) AEIBuilder setType(enum type) AEIBuilder AEIBuilder setFeature(enum feature, int value) AEIBuilder setTime(long from, long to) AEIBuilder AEIBuilder(String app, …) float getEnergy(AEIBuilder builder) float getAvgPower(AEIBuilder builder) HashMap< Timestamp, float> AdMonitor getPowerTrace(AEIBuilder builder) JSONObject getJsonDump(AEIBuilder builder) void startTrace () void stopTrace ()

Description Set target application Set target Ad Library Set target Ad Type Set target Ad Features Set target period Constructor for AEI to set parameters at once Return total energy consumed by Ad (Unit: mJ) Return average power consumed by Ad (Unit: mW) Return the power trace of the AEI from time and power Return AEI data structure in JSON format

Start recording the profile result to DB Stop recording the profile result to DB Return {whether ad method or ad thread}, name, String getAdTrace(AEIBuilder builder) start time, end time, pid, uid, and child thread if it is AdAnalyzer created in the csv string format HashMap Return average power consumption of each getAdEnergy(AEIBuilder builder) AdWork (Unit: mA) HashMap Return energy consumption of each AdWork (Unit: getAdAvgPower(AEIBuilder builder) mA) AdAnalyzer is used by application developers to optimize an ad’s energy consumption. The component

provides detailed information about ad methods and ad threads, which are essential for finding the root cause of energy consumption. The getAdTrace() function returns the history of an ad method call and ad thread generation. The history is in the form of a CSV string, including various types of information, such as pid, uid, name, start time, end time, and so on. The energy and power consumption of individual ad methods and ad threads are also provided, making energy optimization easy. Because the history data are large, AdAnalyzer selectively stores logs in a database by calling the startTrace() and stopTrace() methods. Fig. 1 shows the use case of the proposed APIs. We requested the AEI of the AdMob library image ad with a 30 second refresh rate in the Calculator Plus application (lines 3–6). Through the getEnergy function of AdMonitor, 1. long currentTime = 2. System.currentTimeMillis(); 3. AEIBuilder aeiBuilder = 4. new AEIBuilder("Calculator-Plus", ADMOB, IMAGE) 5. .setFeature("RefreshRate", 30) 6. .setTime(currentTime - 10000, currentTime); 7. float energy = 8. AdMonitor.getEnergy(aeiBuilder);

Fig. 1. Code example.

Pervasive and Mobile Computing

Fig. 2. The AdMonitorService architecture. an ad’s energy is easily acquired. More usage scenarios are described in Section 5. 3. Implementation To realize the APIs, we added a system service, called AdMonitorService, in the Android framework. The service starts with device booting and handles the API calls. Fig. 2 shows the overall architecture of AdMonitorService, which consists of two parts: Ad Tracer and Ad Energy Estimator. Ad Tracer monitors the ad features and workloads of an ad. Ad Energy Estimator calculates an ad’s energy consumption based on the ad’s workload and stores the results in the database. When the APIs are called to acquire AEI, AdMonitorService searches the target AEI from the database and return the results.

3.1. Ad Tracer Tracing an ad’s workload accurately faces several challenges. First, the ad library’s method call should be monitored with low overhead. Although previous works [1,7,11–13] proposed various method-tracing techniques, they are not applicable to the proposed system due to the overhead issue. Second, the system should trace the ad’s workload across multiple threads. Finally, to estimate the GPU power consumption, the graphical workload of an ad should be extracted from the Android graphic pipeline. We developed Ad Method Tracer, Ad Thread Tracer, and Ad Graphic Workload Tracer to resolve these challenges. Ad Method Tracer. Android Runtime (ART) is the default application’s run-time environment for Android. ART adopts ahead-of-time (AOT) compilation that transforms Java bytecode into native code before execution. Because method tracing for native machine code is difficult, instead of AOT, we adopted a just-in-time (JIT) method

Pervasive and Mobile Computing

Fig. 3. Method and thread tracing. that interprets Java bytecode as native code when the app starts. Method tracing with Java bytecode can easily be done by modifying the interpreter. Fortunately, Android version 7.0 uses the AOT and JIT methods. We modified the ART interpreter to monitor the start and end points of every method call. As shown in Fig. 3(a), when the method for the ad library is invoked, we push that method to stack and pop it after termination. The start and end points of an ad’s operation are determined by inspecting the stack. In addition, various levels of AEI are extracted from the method call. With the preliminary tests, we found that the JIT method severely degrades system performance because this method is noticeably slower than the AOT method. Therefore, we selectively applied the JIT method only to identify the ad’s methods. Whenever the method is called for the first time, we label it the ad’s method if the method belongs to the ad library. This way, Ad Method Tracer observes the ad’s method call accurately and with low overhead. This kind of dynamic scheme is required for accurate method tracing to cope with the continuously updated library methods. Ad Thread Tracer. Typically, an ad generates several threads to process various works, such as content download and ad drawing. As shown in Fig. 3(b), AdMonitorService monitors the fork function in the kernel to trace the workload of an ad across multiple threads. When a thread invokes an ad’s method, the thread is labeled the ad’s thread. If a child thread forks away from the ad’s thread, the child thread is labeled the ad’s thread. Fig. 4 shows an example of the method and thread tracing when the AdMob image ad is displayed. When an application’s main thread invokes the loadAd() method which belongs to the AdMob library, AdMonitorService recognizes the start of the ad and identifies the ad type as an image through the com.google.android.gms.ads.AdView.loadAd()

Pervasive and Mobile Computing

Tracked Job (Admob Image)

com.google.android.gms.ads.AdView.loadAd com.google.android.gms.ads. BaseAdView.loadAd com.google.android.gms.ads. internal.client.n.onTransact

fork

com.google.android.gms.ads. BaseAdView.loadAd com.google.android.gms.ads.AdView.loadAd

AdWorker AdWorker AdWorker

Fig. 4. Method and thread tracing example while displaying the AdMob image ad. method. After the loadAd() method, all the methods called by the main thread, until loadAd() is terminated, are regarded as ad-related methods. In the case of thread tracing, AdMonitorService regards all threads forked during the loadAd() method execution as ad-related threads, called AdWorker. Even after the end of loadAd(), the workload generated by AdWorkers is collected until they are terminated. However, this causes a synchronization problem because method tracing and thread tracing are performed in the Android framework and in the kernel, respectively. Ad Method Tracer sends the method call information to Ad Thread Tracer via IOCTL, which has 30–150 μsec of delay. Note that IOCTL is a Linux interface to communicate between the kernel mode and the user mode. Because the kernel mode and the user mode cannot interact, the proposed system uses IOCTL to send various data between the kernel mode and the user mode. If child threads are forked before they receive IOCTL, Ad Thread Tracer would miss them because the parent thread is still labeled as the ad’s thread. Therefore, after receiving IOCTL, Ad Thread Tracer inspects the start time of all child threads forked from the ad’s thread and labels the child thread generated during the ad’s operation as the ad’s thread. Ad Graphic Work Tracer. In Android, graphic work is handled by system threads, such as SurfaceFlinger and RenderThread. Because the threads handle the graphic work of all applications, the exact workload for each thread is not easy to calculate. We simply decided that the graphic workload of an ad was in proportion to the ad’s display area. For example, when the area of an ad’s refreshed view occupies half of the entire refreshed view, the

Pervasive and Mobile Computing

ad’s workload is considered half the CPU and GPU workload generated by SurfaceFlinger and RenderThread. In addition to the graphic workload, ad features such as the FPS and the refresh rate are collected. Hardware Event Monitor. We collect the hardware utilization of the CPU, GPU, and WiFi in an event-driven method based on AppScope [14]. The system monitors the scheduler, WiFi interface, and GPU driver in the kernel to estimate the CPU ticks, the number of WiFi packets, and the GPU utilization of each thread. The exact workload of an ad is obtained by distinguishing the ad’s thread.

3.2. Ad Energy Estimator Ad Energy Estimator calculates the energy consumption of an ad based on Ad Tracer’s data and generates AEI. The AEI is stored in the database. Energy Estimator. An ad’s actual energy consumption is calculated using the utilization-based model [14]. We calculate the energy consumption of the CPU, GPU, and WiFi according to their power model. The CPU power model is as follows: 𝑐,𝑓 𝑐,𝑓 𝑐,𝑓 𝑓 𝑠 𝑠 𝑃𝐶𝑃𝑈 = ∑𝑚 𝑐=0 ∑𝑓=0 (𝛽𝑐𝑜𝑟𝑒 ⋅ 𝑢𝑐𝑜𝑟𝑒 + 𝑃𝑖𝑑𝑙𝑒 ) + ∑𝑓=0 𝑃𝑢𝑛𝑐𝑜𝑟𝑒 ,

where c is the core index, m the number of cores, f the CPU frequency index, s the number of CPU frequencies, 𝛽 the coefficient, and u the utilization. The GPU power model is expressed as: 𝑓

𝑓

𝑓

𝑃𝐺𝑃𝑈 = ∑𝑠𝑓=0 (𝛽𝐺𝑃𝑈 ⋅ 𝑢𝐺𝑃𝑈 + 𝑃𝑏𝑎𝑠𝑒𝐺𝑃𝑈 ), where f represents the GPU frequency index, s the number of GPU frequencies, 𝛽 the coefficient, and u the utilization. Finally, the WiFi power model is represented as 𝑃𝑊𝑖𝐹𝑖 = 𝛽𝑊𝑖𝐹𝑖 × 𝑢𝑊𝑖𝐹𝑖 + 𝑃𝑏𝑎𝑠𝑒𝑊𝑖𝐹𝑖 , where 𝛽 is the coefficient, and u the number of transmitted packets. Based on these component power models, the energy consumption of an individual process is estimated by acquiring each component’s hardware utilization. AEI Generator. To generate AEI, the tracing data of Ad Tracer should be integrated with the energy consumption collected by Energy Estimator. AEI Generator gathers ad data and energy data every second. First, the energy consumption of an individual process is collected from the proc file system. Then, the energy used by

Pervasive and Mobile Computing

1. public class AdMonitorService extends SystemService { 2. private List mAEIs; 3. 4. ... 5. 6. public class AdEnergyInformation { 7. public String packageName; 8. public enum adLibrary; 9. public enum adType; 10. public Map adFeature; 11. public long timestamp; 12. public float usedPower; 13. }; 14.};

Fig. 5. AEI class. AdWorkers is regarded as the ad’s energy consumption. In the case of the GPU, the ad’s energy consumption is calculated according to the View information of Ad Graphic Work Tracer. Finally, the data are stored as an AEI structure defined in Fig. 5. To minimize the overhead, we store AEI in the database every 30 min.

4. Evaluation We evaluated the proposed APIs in terms of accuracy and overhead. All the experiments were conducted on the Nexus 5X smartphone with Android 7.1 (Nougat) in the WiFi environment. 4.1. Energy estimation accuracy To evaluate the accuracy of the energy estimate, the ground truth of an ad’s energy consumption should be measured. However, measuring the ground truth is hard in practice because there is no direct way to distinguish an ad’s energy consumption from the application’s energy consumption. Therefore, we modified the application to eliminate the ad and compared the energy consumption of the original and modified applications. We then estimated the ground truth indirectly by comparing the applications’ energy consumption while running the same workload. We evaluated the accuracy of the energy estimate with various applications. First, we conducted experiments with a simple application and excluded environmental factors, such as a background job or network traffic. To this end, we developed an application that simply shows ads without doing anything else. The base power of the application was measured by disabling the ads. The ad’s power was then obtained by subtracting the base power

Pervasive and Mobile Computing

Image

Admob

Measured Estimated

-5.4%

Facebook

-7.8%

Video

Admob(30FPS)

-2.9%

Facebook(30FPS)

+7.4%

Facebook(60FPS)

-4.7%

0

500

1000

1500

2000

Mean Power (mW)

Fig. 6. Power estimation error. 6000

Estimated Ground Truth

Power (mW)

Power (mW)

6000

4000

2000

Estimated Ground Truth

4000

2000

0

0 0

200

100

Time (s)

(a) Image ad

0

100

200

Time (s)

(b) Video ad

Fig. 7. AdMob ad power trace. from the overall power measured by Monsoon2. For the experiment, the device was set to airplane mode, and all the background jobs were made not to be executed by a developer option. The ground truth and the estimated power were collected while specific types of ads were run continuously for 24 h. Fig. 6 shows the results. The ground truth shows that the AdMob ads consumed, on average, less power than the Facebook ads. The error for the mean power was less than 8%, and the mean absolute scaled error(MASE) [15] of the estimation result was less than 1, indicating that the proposed APIs traced the ads’ power accurately. For a detailed analysis, the power traces for the AdMob image ad and movie ad are analyzed. As shown in Fig. 7(a), the proposed APIs accurately estimated the power consumption of the image ads. Whenever the ad was switched, the power increased sharply because of the network communication and ad drawing. Fig. 7(b) shows the power trace when movie ads with 30 FPS are switched continuously. Note that the power consumed around 50, 100, and 150 sec was low because the delay in the ad switching was 2 sec.

2

We disassembled the Nexus 5X smartphone and then detached the battery from the device and directly connected Monsoon to the device.

Pervasive and Mobile Computing

8000

8000 w/ ad Estimated ad power

2000

50

100

150

200

Time(s)

(a) Image ad (Blood Pressure)

(d) Movie ad with 30 FPS (Angry Birds) Fig. 8. AdMob ad power trace.

4000 2000 0

50

100

w/ ad Estimated ad power

6000

Power(mW)

4000

0

6000

Power(mW)

Power(mW)

6000

8000 w/ ad Estimated ad power

4000 2000 0

40

Time(s)

80

120

Time(s)

(b) Image ads from different library (Calculator Plus)

(c) Energy inefficient image ad (Sudoku)

(e) Movie ad with 60 FPS (White House)

(f) Interactive ad (Ski Safari)

Next, to validate the practicality of the proposed system, we conducted experiments with many real applications that use various types of ads. The ground truth was measured by using Lucky Patcher [16], a tool for modifying the Java bytecode of an application, to eliminate the ad from the original application. The original and modified applications were executed by Monkey to generate the same workload. The difference in the energy consumption was then considered the ground truth. Fig. 8(a)–(c) show the energy estimation results of various image ads, while Fig. 8(d) and (e) show video ads with different FPS rates, and Fig. 8(f) shows an interactive ad. Fig. 8(a) presents the power consumption when the user records his or her pulse every 30 sec using the Blood Pressure application. The application shows the AdMob image ad and switches the image every 60 sec. We tested the accuracy of the energy estimate when the ad and the application consumed energy at the same time. As shown in the graph, the power increases sharply every 30 sec due to the interactions, and additional power is consumed every 60 sec due to the ad. The estimation result indicates that the proposed system accurately distinguished the energy consumption of the ad from that of application. Fig. 8(b) shows the power consumption when the Calculator Plus application was used for 2 min. The application is a commonly used calculator that shows AdMob and MoPub image

Pervasive and Mobile Computing

ads alternately. The estimation result shows that although two ad libraries operated simultaneously, the proposed system traced the ad’s energy consumption accurately. Meanwhile, we observed that the ad consumed a considerable amount of power in the original application. The AEI analysis revealed that the MoPub library runs continuously in the background even when an AdMob ad is displayed in the foreground. Fig. 8(c) shows the power trace while the Sudoku application is left in the game play screen without any interaction. On the game play screen, the AdMob image ad is loaded in the beginning and unchanged during game play, indicating the ad should not consume energy. However, the ad’s energy consumption is not trivial as shown in the graph. With AEI analysis, we found that the AdMob library runs redundantly in the background due to an application bug. This result validates that the proposed system estimates the ad’s energy consumption accurately even if the ad library works in the background. Fig. 8(d) and (e) show the power consumption of Angry Birds and White House which display video ads with different FPS rates. The ad in Angry Birds consumed more power than the one in White House although the FPS rate of the former was lower than that of the latter. This is because these applications were using different ad libraries, i.e., Unity and Facebook. The experimental results indicate that the proposed system estimates the ad’s energy consumption regardless of the ad library. Fig. 8(f) presents the power consumption when the Ski Safari application uses an interactive ad. An interactive ad usually requires users to answer a simple question or play a mini-game. Therefore, the power consumption varies dynamically according to the user’s interaction. Even in this case, the proposed system accurately estimated the energy consumption of the interactive ad.

4.2. Overhead To observe the overhead of the proposed APIs, we compared the FPS rate and the energy consumption of the original Android system with the modified system when the proposed APIs were implemented. For the overhead test, we used video ads on purpose, because they generate heavy workloads and have more overhead than the other type of ads such as image or interactive ads. Fig. 9 indicates that the overhead is negligible when videos are played. Because the proposed system traces only the methods of ad libraries, the overhead is almost nil when there are no ads. In the case of video ads, Facebook ads were virtually unaffected by the proposed APIs. In the case of the

AOSP AEI

+0.6%

4000 3000

+1.2%

+14.8% +0.1%

2000

40 -8.7%

-5.1%

20

1000 0

n (No

S)

)

Ad

be utu

Yo

-0.2%

AOSP AEI

-0.2%

60

FPS

Mean Power (mW)

Pervasive and Mobile Computing

b

mo

Ad

e vid

0FP o(3

ok

ebo

Fac

S) FP (30

eo vid

ebo

Fac

ok

eo vid

0

S) FP (60

)

d)

Yo

S) S) FP FP (30 (60 o o e e vid vid ok ok ebo ebo c c a a F F PS 30F

A on

N be( utu

b

mo Ad

eo( vid

Fig. 9. Overhead (power consumption and FPS rate). AdMob video ad, the power increased by 14.7%, and the FPS rate decreased by 8.6%. The AdMob library calls its method continuously while playing ads; thus, the overhead increases because of the method and the thread tracing. Although non-trivial overhead was observed for the video ad of a specific library, we believe that the proposed system would not degrade QoS considerably. As the average playing time of a video ad is about 15 sec, the overall battery lifetime would not be affected by this overhead. Moreover, video ads usually occupy the entire or most of the screen; therefore, the overhead affects the video ads only, not the underlying application. The ad quality is usually not related to the QoS; therefore, the overhead of the proposed system would not harm the QoS of a target application.

5. Case study We present the use cases of the proposed APIs from the perspective of application users and application developers. 5.1. Application users Generally, mobile users select applications without knowing the ad’s energy consumption. However, an ad’s energy information is important because more than 70% of the overall energy consumed by some applications is due to an ad [7]. Therefore, providing energy information about the application (i.e., AEI) is useful for users to select energy-efficient applications. Application markets, such as Google Play, can collect AEI from users using the proposed APIs. Then, useful information such as ranking the energy consumption of each application can be provided to users. Users can compare the ad’s energy consumption and select energy-efficient applications. Fig. 10

Pervasive and Mobile Computing

B a t t e r y l i fe t i m e lo s s ( m i n / h ) 7.8 2.9 0 5.4 6.5 0 3.6

Fig. 10. An example of an ad’s energy ranking for several calculator applications. shows the ad energy consumption of several calculator applications. The energy data were collected from two Nexus 5X smartphones while the applications were run for 20 h. With this information, users may select the most energyefficient application. For example, in the case of the Calculator plus application, users can analyze the tradeoff between an ad’s energy consumption in the free version and in the paid version. One useful information is to display an estimate of how many minutes of phone usage one would lose due to ads for each hour using the given application (i.e., the ‘Battery lifetime loss(min/h)’ column in the figure). This would provide a more tangible idea to phone users about the costs of advertisement embedded in the application. 5.2. Application developers Analysis of an ad’s energy consumption. About half of the applications that use ads are reported to use more than two ad libraries [1]. Moreover, applications usually show different types of ads dynamically according to the

Abnormal Power Consumption

(a)

(b)

Fig. 11. An analysis result of an ad’s energy consumption in the Sudoku application.

Pervasive and Mobile Computing

application’s content. This makes it hard for developers to analyze an ad’s energy consumption. The proposed APIs help developers monitor and analyze ads’ energy consumption. Fig. 11 shows the analysis tool implemented with the proposed APIs. Fig. 11(a) provides ads’ power consumption by an individual Activity in the Sudoku application and indicates that the game play Activity consumes a large amount of power due to the ad. Fig. 11(b) shows a detailed analysis of the Activity game play. The power is mostly consumed due to the AdMob image ad. Based on our observation, we conducted application debugging as follows. Debugging. The proposed APIs help application developers detect potential energy bugs in an ad and fix them. We found energy bugs in the Sudoku application. The application consists of two screens: the main and game playing screens. On both screens, the AdMob image ad is displayed at the bottom of the screen. By analyzing the ad’s energy consumption via the getPowerTrace() API, we observed that the ad’s average power is 120 mW on the main screen but 400 mW on the game playing screen. To find the cause of this difference, we analyzed the ad library’s operations using the getAdTrace() API. Fig. 12 shows the methods and threads for running the application. At launch, Sudoku calls the AdMob build() method to determine the ad’s features, such as the ad type and the refresh rate. On the main screen, the AdMob loadAd() method is invoked to fork a series of AdWorker threads that process the ad in the background. Finally, the image ad is displayed on the screen. When the game starts, the operation of the AdMob library is similar to the main screen operation, except for a continuous call of the onGlobalLayout() method. This function is a callback method used to invoke Builder.build()

AdView.loadAd()

internal.util.weaklisteners.b .onGlobalLayout()

kpointer.sudoku AdWorker(s) pool-7-thread1

… pool-7-threadN App Launching

Fig. 12. Ad traces by app activity.

Main Menu

Game Play

App Closed

400

Mean Power (mW)

Mean Power (mW)

Pervasive and Mobile Computing

CPU NET

300 200 100 0

) ad) ad) ad) (ad er( ku( non ead ork udo ku( -thr s W . o 7 d r d l A inte r.su poo kpo inte

kpo

Threads

(a) Main menu

400

CPU NET

300 200 100 0

d) d) d) ad) na d(a u(a er( (no rea dok ork u h u t k s W r. do l-7 Ad inte r.su poo kpo nte poi

k

Threads

(b) Game play

Fig. 13. Thread-level power analysis. OnGlobalLayoutListener() to resize the image ad whenever the screen layout changes. The onGlobalLayout() method is called whenever the screen layout changes. However, due to the bugs in Sudoku, OnGlobalLayout() is continuously called as the game plays. We believe the application developers did not unregister OnGlobalLayoutListener. Fig. 13 shows a detailed analysis of Sudoku’s power consumption. The power consumed by the application’s main thread (i.e., kpointer.sudoku) is divided into non-ad and ad because the main thread handles general workloads and ad workloads. In the main menu (Fig. 13(a)), the power is mainly consumed by the AdWorker thread to continuously update the image ad in the background. However, when the game is played, the kpointer.sudoku thread consumes a considerable amount of power due to the continuous method calls. This way, the application developers are now able to optimize the ad’s energy consumption by detecting bugs and fixing them.

6. Related work Several studies have attempted to analyze the hidden cost of mobile ads. Ruiz et al. [1] observed that ads bother mobile users with push notifications or pop-up windows, interrupting application usage. The authors claimed that an application’s rating is affected by ads because ads degrade a user’s QoS. Gui et al. [3] analyzed various aspects of a mobile ad’s hidden costs. The authors found that ads increase CPU utilization, memory utilization, and network traffic, ultimately consuming more energy. Moreover, the authors found that ads decrease an application’s rating, and the maintenance costs are high. Gill et al. [17] analyzed the relationship between user privacy and ad revenue. They regarded user privacy as another cost of ads. All of these works observed the hidden cost of mobile ads experimentally, but they did not explicitly estimate the energy consumption of mobile ads.

Pervasive and Mobile Computing

Few studies have focused on ad network traffic regarding an application’s energy cost. Vallina-Rodriguez et al. [18] analyzed network traffic to acquire hints for optimizing energy consumption. They found that caching an ad’s content reduced the network traffic, decreasing the energy consumption. Mohan et al. [6] predicted the ads that would be shown in the near future. Based on the prediction, a prefetching system was proposed to eliminate redundant tail energy. Khan et al. [4,19] observed a close relationship between ad content and user context, such as location. The ads are then prefetched based on user context, thus reducing network energy. Although these approaches reduced the ad’s energy consumption, none of these previous works estimated ads’ energy consumption by considering the CPU and GPU or provided energy data for users and developers. In contrast, the proposed system disaggregates the CPU, GPU, and WiFi energy to an individual mobile ad, thus providing fine-grained information. Many previous studies proposed energy estimation techniques for mobile devices. Yoon et al. [8] and Flinn and Satyanaraynan [20] estimated the hardware-level energy consumption of individual processes. The authors monitored the hardware utilization of individual processes and calculated the energy consumption using a utilization-based power model. Mittal et al. [21] modified Java Virtual Machine to calculate the energy consumption of each method. Hao et al. [12] analyzed the instructions to estimate the energy consumption of applications. To estimate ads’ energy consumption, a real-time method and thread tracing are required but were not possible with previous works. Vallina-Rodriguez et al. [18] and Gui et al. [5] proposed methods for estimating the energy consumption of mobile ads for application developers. However, these methods cannot operate in real user environments as the systems require application modifications for energy measurements. Our system estimates mobile ads’ energy in real use scenarios and provides high-quality AEI to the players in the mobile ad ecosystem.

7. Discussion We discuss several issues related to the real-world deployment and applicability of the proposed system. First, the package list of ad libraries should be provided because AdMonitorService distinguishes the ad library’s method by the package name to which the method belongs. This means that whenever a new ad library is released, the ad library list must be updated. However, we consider the cost negligible because the number of ad libraries is limited.

Pervasive and Mobile Computing

In the present work, we exploited AppScope [14] for estimating an application’s energy consumption. AppScope is a utilization-based energy estimation tool; thus, it requires an accurate power model for the underlying device’s hardware, making deployment difficult. Fortunately, Google forces device manufacturers to build power models that provide energy information in Android [22]. Therefore, the proposed system can be deployed on most Android devices. If a power model is not available for some reason, BatteryStats, the default energy estimator in Android, can be employed as the second option. To estimate the energy consumption of the AMOLED display, the RGB of each pixel should be monitored because the AMOLED display consumes different amounts of power depending on the screen content [23]. Inspecting every pixel leads to considerable overhead. In addition, the ground truth of a mobile ad’s display energy is hard to calculate because it depends on the application’s original content. For example, when a dark mobile ad is shown in an application whose overall color is white, the display energy of the area showing the mobile ad will be less than the original application because the display consumes more energy in white. In this case, the ground truth of the display energy is calculated as a negative value. For the case of the LCD display used by Nexus 4 or Nexus 5X in our experiments, the display power consumption depends only on the brightness. In the present work, we simplified the power issue related to the display by using LCD-based mobile devices. Although energy consumption changes according to the device type or network conditions, we did not consider these factors in the evaluation because the energy variance due to the device type and network conditions can be mitigated by adopting a more accurate energy model. The development of an accurate energy model is beyond the scope of the present work, and in this paper, we focused on validating how the proposed system disaggregates each hardware component’s energy to an individual mobile ad. Finally, the overhead of the proposed system is trivial but is not completely nil. Especially, as described in Section 4.2, there is noticeable overhead for the video ad of a specific library. The device manufacturer may not deploy the proposed system due to the potential QoS degradation. One way to resolve this issue is to provide an on/off option for the proposed system as the developer’s option. This enables users to switch off the system immediately when QoS degradation is experienced.

Pervasive and Mobile Computing

We consider that there are two ways to reduce ad energy consumption using the proposed APIs. The first option is to introduce ad platform support to cap the maximum amount of energy used by ads. Ads that try to use more than the threshold simply would cease to run. This could potentially be coupled with user control of the threshold depending on the user’s sensitivity to energy use. The second option is to shame apps that use a considerable amount of energy for ads. By providing a public dashboard or similar document to call out the worst cases, developers may try to improve the energy efficiency of their application.

8. Conclusion In this paper, we defined the AEI for each player of the mobile ad ecosystem, that is, users, application developers, and ad providers, and we implemented APIs to provide AEI that considers the various requirements of the underlying ecosystem. The usefulness of the proposed APIs was validated with case studies. The main contribution of the present work is the development of a run-time energy estimation system focused on mobile ads, and to the best of our knowledge, this is the first approach in the related area. We believe that the proposed APIs and AEI will be of great help to users, application developers, ad providers, and even advertisers. With this tool, the nature of mobile ads and their energy management can be better understood. We expect that additional techniques will be developed, based on our work, to reduce mobile ads’ energy consumption. Acknowledgments This work was supported by the Samsung Research Funding Center of Samsung Electronics under project number SRFCTB1503-02 and the National Research Foundation of Korea (NRF) grant funded by the South Korean government, Ministry of Education, Science and Technology under Grant NRF-2017M3C4A7083677. References [1] [2] [3]

I.J.M. Ruiz, M. Nagappan, B. Adams, T. Berger, S. Dienst, A.E. Hassan, Impact of ad libraries on ratings of Android mobile apps, IEEE Software. 31 (6) (2014) 86–92. What makes people buy from a brand they follow on social media?, https://retail.emarketer.com/article/whatmakes-people-buy-brand-they-follow-on-social-media/58b5a6f7ebd4000a60315eca J. Gui, S. Mcilroy, M. Nagappan, W.G. Halfond, Truth in advertising: The hidden cost of mobile ads for software developers, in Proceedings of the 37th International Conference on Software Engineering (ICSE), 2015, pp. 100– 110.

Pervasive and Mobile Computing

[4]

[5] [6] [7]

[8]

[9] [10] [11]

[12] [13] [14]

[15] [16] [17]

[18]

[19]

[20]

[21] [22] [23]

A.J. Khan, V. Subbaraju, A. Misra, S. Seshan, Mitigating the true cost of advertisement-supported free mobile applications, in Proceedings of the Twelfth Workshop on Mobile Computing Systems & Applications (HotMobile), 2012, p. 6. J. Gui, D. Li, M. Wan, W.G. Halfond, Lightweight measurement and estimation of mobile ad energy consumption, in Proceedings of the 5th International Workshop on Green and Sustainable Software, 2016, pp. 1–7. P. Mohan, S. Nath, O. Riva, Prefetching mobile ads: Can advertising systems afford it?, in Proceedings of the 8th ACM European Conference on Computer Systems (EuroSys), 2013, pp. 267–280. A. Pathak, Y.C. Hu, M. Zhang, Where is the energy spent inside my app?: Fine-grained energy accounting on smartphones with eprof, in Proceedings of the 8th ACM European Conference on Computer Systems (EuroSys), 2012, pp. 29–42. C. Yoon, D. Kim, W. Jung, C. Kang, H. Cha, AppScope: Application energy metering framework for Android smartphone using kernel activity monitoring, in Proceedings of the 2012 USENIX conference on Annual Technical Conference (USENIX ATC), 2012, pp. 1–14. J. Bloch, How to design a good API and why it matters, in Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications (OOPSLA), 2006, pp. 506–507. J. Bloch, Effective Java, third ed., Addison-Wesley Professional, Boston, 2018. S. Hao, D. Li, W.G. Halfond, R. Govindan, Estimating Android applications' CPU energy usage via bytecode profiling, in Proceedings of the first international workshop on green and sustainable software (GREENS), 2012, pp. 1–7. S. Hao, D. Li, W.G. Halfond, R. Govindan, Estimating mobile application energy consumption using program analysis, in Proceedings of the 2013 International Conference on Software Engineering (ICSE), 2013, pp. 92–101. T. McDonnell, B. Ray, M. Kim, An empirical study of API stability and adoption in the Android ecosystem, in Proceedings of IEEE International Conference on Software Maintenance (ICSM), 2013, pp. 70–79. C. Xian, Y.-H. Lu, Z. Li, A programming environment with runtime energy characterization for energy-aware applications, in Proceedings of ACM/IEEE International Symposium on Low Power Electronics and Design (ISLPED), 2007, pp. 141–146. R.J. Hyndman, A.B. Koehler, Another look at measures of forecast accuracy, International Journal of Forecasting. 22 (4) (2006) 679–688. Lucky patcher, https://www.luckypatchers.com/ P. Gill, V. Erramilli, A. Chaintreau, B. Krishnamurthy, K. Papagiannaki, P. Rodriguez, Follow the money: Understanding economics of online aggregation and advertising, in Proceedings of the Conference on Internet measurement conference (IMC), 2013, pp. 141–148. N. Vallina-Rodriguez, J. Shah, A. Finamore, Y. Grunenberger, K. Papagiannaki, H. Haddadi, J. Crowcroft, Breaking for commercials: Characterizing mobile advertising,” in Proceedings of the Conference on Internet measurement conference (IMC), 2012, pp. 343–356. A.J. Khan, K. Jayarajah, D. Han, A. Misra, R. Balan, S. Seshan, CAMEO: A middleware for mobile advertisement delivery, in Proceeding of the 11th Annual International Conference on Mobile systems, applications, and services (MobiSys), 2013, pp. 125–138. J. Flinn, M. Satyanarayanan, Powerscope: A tool for profiling the energy usage of mobile applications, in Proceedings of the Second IEEE Workshop on Mobile Computer Systems and Applications (WMCSA), 1999, pp. 2–10. R. Mittal, A. Kansal, R. Chandra, Empowering developers to estimate app energy consumption, in Proceedings of the 18th annual international conference on Mobile computing and networking (Mobicom), 2012, pp. 317–328. Power profiles for Android, https://source.android.com/devices/tech/power/ D. Kim, W. Jung, H. Cha, Runtime power estimation of mobile AMOLED displays, in Proceedings of Design, Automation & Test in Europe Conference & Exhibition (DATE), 2013, pp. 61–64.

Pervasive and Mobile Computing

Seokjun Lee received his Ph.D. degree in Computer Science from Yonsei University, Seoul, Korea, in 2018. His research interests include energy-aware mobile systems, energy-related tools for mobile developers, and battery management systems.

Minyoung Go received his B.S. and M.S. degrees in Computer Engineering from Yonsei University, Seoul, Korea, in 2016 and 2018, respectively. He is currently a researcher at LG Electronics, Korea. His research interests include low-power display and energy-aware operating systems.

Rhan Ha received the B.Sc. and M.Sc. degrees in computer engineering from Seoul National University, Seoul, Korea, in 1987 and 1989, respectively, and the Ph.D. degree in computer science from the University of Illinois at Urbana–Champaign, Urbana, USA, in 1995. She is currently a Professor of computer engineering at Hong-Ik University, Korea. Her research interests include real-time embedded systems and mobile systems.

Hojung Cha received the B.S. and M.S. degrees in computer engineering from Seoul National University, Seoul, Korea, in 1985 and 1987, respectively. He received the Ph.D. degree in computer science from the University of Manchester, Manchester, U.K., in 1991. He is currently a Professor at the Department of Computer Science, Yonsei University, Korea. His research interests include energy-aware mobile systems, embedded operating systems, and energy-efficient IoT systems.