1 Introduction

Recently, new content circulation environment is being developed in accordance with the spread of cloud, mobile web hard, bit torrent environment and mobile environment. As the copyright infringement cases of mobile devices, platforms, and services increase, the development of copyright protection technology in mobile environment and the need for new standards are emerged [1].

There are mobile applications which used to prevent copyright infringement of mobile contents. It has a function of inserting and extracting digital watermarks. However, when the application is executed in the mobile device as it is, there is a problem that the battery usage rapidly increases, and there is no related API to which the low power technology is applied to solve the problem. Due to the nature of mobile devices with limited battery capacity, it is very important to minimize the power consumption of the app in the process of developing a mobile watermarking application so that it can be serviced for a longer period of time.

In this paper, we describe digital watermarking, battery historian, and energy refactoring, and propose two scenarios for accurately measuring the power consumption of mobile watermarking applications using battery historian. The existing watermarking application is implemented through energy refactoring the improvement in power consumption is confirmed through the results of power consumption measurement through the battery history. This will be used as a reference for the development of low-power applications and API modules with copyright technology in the future.

2 Preliminaries

2.1 Digital Watermarking

Digital watermarking is a technique for copyright protection, which means that a copyright holder or a seller inserts a specific code or pattern so as to identify copyright information in various digital contents such as photographs and moving pictures [2, 3]. In this case, the inserted data is called a watermark, and is used as a legal basis for proofing the owner by extracting the watermark information again from the pirated digital contents distributed by inserting the watermark (Fig. 1).

Fig. 1.
figure 1

Watermark system structure

Full size image

2.2 Battery Historian

The battery historian is a battery consumption measurement tool made by Google [4]. We can measure how much power a mobile device with an Android operating system consumes, and the operating system version should be 5.0 or higher. Android app developers visualize the energy consumption of their Android apps through the battery historian, so we can see when features are used and get bug reports to get quantitative data on power consumption. Measures the overall power consumption from the battery full condition to the generation of the bug report with high accuracy (Fig. 2).

Fig. 2.
figure 2

Execution screen of battery historian

Full size image

2.3 Energy Code Smells and Energy Refactoring

Code refactoring is the process of identifying the root cause of performance degradation while ensuring the functional behavior of the software system in order to resolve it when software internal structure is not improved, And to improve the performance of the software [5]. On the other hand, the code pattern that causes waste of energy in terms of energy efficiency, not the maintenance aspect, is called Energy Code Smell, and improvement of it is called energy refactoring [6, 7].

Loop Bug.

This is the behavior of a program that does not get the desired results from the application and it repeats the same thing over and over, and can be caused by an external event such as a server failure. In addition, an application may repeatedly attempt to connect to an unresponsive server while continuously consuming energy for connection to the server and data, or may result in an infinite loop or recursive call due to a program error. To detect loop bugs, we need to identify the loops that will always return to the same initial system state, using components that consume energy in the process. Exception handling in a loop can indicate a loop bug. One way to handle loop bugs is to introduce a maximum number of iterations.

Dead Code.

This means code that is not used but is loaded into memory and eventually consumes energy, and certain forms of dead code can be detected and removed through the compiler’s optimization process. During the deformation of a dead code, some code may be called, but the result is ignored. Thus, the greater the number of different forms of dead code, the easier to detect at the source code level.

In-line Method.

This means replacing the method call with the actually called part. This saves energy by avoiding energy consumption due to the overhead of method invocation, but it should be handled with caution considering energy efficiency because it can reduce maintainability and readability of code. One way to find method calls that inline can have a significant impact on energy efficiency is to use dynamic analysis. Profiles running applications and records how often each method invocation occurs. This information can be used to select refactor targets by setting a threshold for the number of calls. The candidate method call is replaced by the body of the invoked method, and the process’s parameters are appropriately changed by the process.

Moving too Much Data.

It means unnecessary movement between processor and memory. In general, since much of the energy consumed by the CPU is less than the energy consumed by the storage device, the movement of a large amount of data causes a waste of energy. Methods loading data which have been saved previously by querying for corresponding read and write methods have to be detected. To reduce data movement, methods reading data need to be replaced by the method calculating the data that was to be retrieved.

Immortality Bug.

It means an application that is constantly revived despite the explicit kill of the user. This problem can be detected in a similar way to loop bugs. If the source code of all related applications is available for collaborative analysis, it is possible to detect applications that are restarted in other processes. System-level dynamic analysis can also indicate applications that start and end repeatedly.

Redundant Storage of Data.

This means that different methods of the application store each without sharing the data. Avoiding redundant storage of data reduces energy consumption because different methods of the application do not each access the data. To detect redundant storage of data, we need to identify ways to store data and find ways to compare and store the same data. We can combine ways to reduce unnecessary data access and store the same data. To do this, we need to know the behavior of the program.

Using Expensive Resources.

This means replacing energy-intensive resources with less energy-consuming resources. However, this should be carefully considered because it can affect the quality of the service.

3 Proposed Scheme

We apply energy refactoring to previously used watermarking application [8] and optimize them, and apply the energy measurement techniques proposed in Sect. 3.2. This compares power consumption measurements of improved watermarking apps with non-improved watermarking apps with energy refactoring, and confirms that improving existing watermarking apps with energy refactoring reduces power consumption.

3.1 Watermarking Application

Because our watermarking application uses MP3 files, we use similar way of particular audio watermarking techniques for MP3 files [9]. In the case of audio watermarking, there is a method of inserting into a spatial domain, a frequency domain, and a compressed domain, and an insertion method is determined according to characteristics of an application field. The watermark embedding method in the spatial domain is widely used because of its relatively simple operation. However, since most music content files exist in a compressed format such as mp3, there is an overhead that requires compression for decoding and re-compression for insertion and extraction Occurs. In addition, the watermarking method in the frequency domain is complicated in insertion and extraction operations. Therefore, when watermarking is to be applied on a limited resource such as a mobile device, a watermarking method in a compressed region is preferred.

When an original mp3 file is input, a portion (8 bytes) of the file is decoded, the watermark value is masked using a scale factor value, and the frame is re-encoded to generate an mp3 file having a watermark embedded therein. When we want to extract the watermark, a portion (8 bytes) of the watermark embedded content is decoded, and the watermark value masked by the scale factor value is extracted. Finally, CRC verification is performed on the detected watermark (Figs. 3, 4 and 5).

Fig. 3.
figure 3

Flow chart of watermarking application’s function

Full size image
Fig. 4.
figure 4

Detail design of watermark insertion function

Full size image
Fig. 5.
figure 5

Detail design of watermark extraction function

Full size image

3.2 Energy Refactoring Technique

Source Parsing.

It analyzes the original code using existing tools.

Energy Profiling.

Energy profiles are made using tools that measure energy. Identify source files that contain energetic classes and methods.

Refactoring.

We detect energy-intensive hot spots in source files from energy profiling. By choosing and applying one of your energy refactoring strategies, you can create optimal code that considers energy efficiency (Fig. 6).

Fig. 6.
figure 6

Energy refactoring framework

Full size image

3.3 Power Measurement Technique

The battery historian only measures the overall power consumption of the application and has the problem that mobile watermarking applications can not accurately determine the actual amount of power consumed when inserting or extracting watermarks into digital content. Therefore, we propose the following two scenarios to be implemented on the user interface to compensate and accurately measure the power consumption. Scenario 1 is a technique for measuring power consumption when a watermarking application is executed and watermarking insertion or extraction is performed once. Scenario 2 is a technique for performing a watermarking app for an arbitrary time, and performing a watermarking insertion or extraction function several times arbitrarily, and measuring the total amount of power consumed during a certain time (Figs. 7 and 8).

Fig. 7.
figure 7

Scenario 1 (single-run scenario)

Full size image
Fig. 8.
figure 8

Scenario 2 (repeat-run scenario)

Full size image

3.4 Power Consumption Measurement and Analysis

We measured the power consumption of the mobile watermarking application on the CPU through Google’s battery historian and analyzed the report on the result (Fig. 9).

Fig. 9.
figure 9

Battery historian execution graph

Full size image

In energy refactored watermarking apps, power consumption was reduced by about 4.7% in Scenario 1 and by about 5% in Scenario 2, compared to when energy refactoring was not applied. In the watermark extraction application with energy refactoring, power consumption was reduced by about 4.2% in Scenario 1 and about 4.78% in Scenario 2, compared to when energy refactoring was not applied (Tables 1 and 2).

Table 1. CPU power consumption measurement table of non-energy refactored watermarking app.
Full size table
Table 2. CPU power consumption measurement table of non-energy refactored watermarking app.
Full size table

4 Conclusion

In this paper, we measured the power consumption according to the two proposed scenarios to accurately measure the power consumption of the mobile watermarking app using the battery historian. The result shows that the existing watermarking app is improved through energy refactoring, Power consumption was reduced. This will be used as a reference for the development of low-power applications and API modules with copyright technology in the future.