# PerHelper: Helping Developers Make Better Decisions on Permission Uses in Android Apps
## 4 PerHelper Design and Implementation
### Overview  
The goal of PerHelper is to **design a plugin for Android Studio and Intellij IDEA (the base of Android Studio) to help Android app developers make better decisions about permission settings**. In particular, PerHelper has two main functions. The first one is to help the developer to decide the exact permission sets he/she should use, based on the analysis of the permission declared and used in each app. The second task is to detect permission-related bugs such as unprotected API calls and wrong permissions. Thus, PerHelper is designed to be invoked by app developers during the app development phase. For example, developers could perform a permission check to generate the precise permission sets before app release or they could invoke PerHelper to detect permission-related bugs once they have declared a permission set manually.  
In order to help developers understand the best way to declare permissions in the Manifest file, we first introduce two permission set concepts as follows.  
* A _Required Permission Set (RPS)_ contains all the permissions that must be included for the code written by the developers (custom code) to function correctly. Permissions in this set must be declared to guarantee the overall functionality of the app. Actually, \(RPS\) is the same as \(UPS\_dev\) defined earlier, but here, we introduce it from the perspective of developers.
* An _Optional Permission Set (OPS)_ is defined as the set of permissions used _only_ by third-party libraries. Obviously, we have: \[OPS=UPS_{lib}-UPS_{dev}\] As shown earlier, permissions in this set are likely to be ignored by developers. The reason why we regard this permission set as \"optional\" is that previous studies [29; 60] showed that some third-party libraries (i.e., ad libraries) might want to retrieve all the details on a user, including location, contact list, viewing history, etc. Typically, they request many sensitive permissions. Rational developers would decide which permissions should be provided to these libraries, instead of giving the libraries full capability to access all sensitive information of a mobile user. Developers should make their decisions based on the tradeoff between giving library more access and protecting user privacy.  
One might question whether ignoring some permissions used by third-party libraries would cause the app to crash, as discussed in Section 3. To tackle this, we will first use our tool to detect and fix the code to avoid potential crashes caused by those permissions, whose details will be shown later. More good news is that according to [PERSON] et al. [59], third-party libraries are often able to handle the situation gracefully when the permissions they requested are missed. In practice, we also find few cases when removing permissions in \(OPS\) leads to app crashing.  
After performing analysis on permissions based on the app source code, PerHelper calculates the \(RPS\) and \(OPS\) sets and makes suggestions to developers on permission declaration:  
* All permissions in \(RPS\) should be declared; the developer would be warned if any permissions in \(RPS\) was missing in the Manifest file.
* Only permissions in \(RPS\) are required to be declared; the developer would also be warned if any permissions out of \(RPS\) have been declared in the Manifest file.
* All permissions in \(OPS\) can be declared at the developer's discretion, based on his/her understanding of the library functionality and privacy concerns of the potential users of his/her app.