Trimming Mobile Applications for Bandwidth-Challenged Networks in Developing Regions

T rimming Mobile Applications f or Band width-Challeng ed Netw orks in De veloping Regions Qinge Xie * , Qingyuan Gong * , Xinlei He * , Y ang Chen * , Xin W ang * , Haitao Zheng † , and Ben Y. Zhao † * Sc ho ol of Computer Science, F udan Universit y , { qgxie17, gongqingyuan, xlhe17, c heny ang, xin w } @fudan.edu.cn † Departmen t of Computer Science, Universit y of Chicago, { h tzheng, ra ven ben } @cs.uchicago.edu ABSTRA CT Despite continuous efforts to b uild and update network in- frastructure, mobile devices in dev eloping regions continue to be constrained by limited bandwidth. Unfortunately , this coincides with a period of unprecedented gro wth in the size of mobile applications. Thus it is becoming prohibiti vely expensi ve for users in de veloping regions to do wnload and update mobile apps critical to their economic and educa- tional dev elopment. Unchecked, these trends can further contribute to a lar ge and gro wing global digital divide. Our goal is to better understand the source of this rapid growth in mobile app code size, whether it is reflecti ve of new functionality , and identify steps that can be taken to make existing mobile apps more friendly bandwidth con- strained mobile networks. W e hypothesize that much of this growth in mobile apps is due to poor resource/code manage- ment, and do not reflect proportional increases in functional- ity . Our hypothesis is partially validated by mini-programs, apps with extremely small footprints gaining popularity in Chinese mobile networks. Here, we use functionally equiv- alent pairs of mini-programs and Android apps to identify potential sources of “bloat, ” inefficient uses of code or re- sources that contribute to large package sizes. W e analyze a large sample of popular Android apps and quantify instances of code and resource bloat. W e de velop techniques for auto- mated code and resource trimming, and successfully validate them on a large set of Android apps. W e hope our results will lead to continued efforts to streamline mobile apps, making them easier to access and maintain for users in developing regions. 1. INTR ODUCTION F or most users in developing regions today , band- width for mobile devices is still a very limited resource. Most users rely on cellular net w orks dominated b y older infrastructure (2G or 2G+EDGE) [43], often augmented b y satellite or low-bandwidth, long-distance wireless links. The result is o verall po or quality of In ternet access [44], with bandwidth of only hundreds of kbps [22, 32]. De- spite efforts ranging from long-distance wireless links [35, 38, 6], l o calized cellular netw orks [43] to affordable com- mo dit y W iFi hots p ots [26], growth in mobile bandwidth is still slow. Actual bandwidth av ailable to users is of- ten constrained by multiple factors including cost, last mile congestion, and limited access to bac khaul links. Unfortunately for users in dev eloping regions, mobile applications worldwide are growing in size at an un- preceden ted pace, in part due to the growth of cheap or unlimited cellular plans. F or example, bandwidth required to download the top 10 most installed U.S. iPhone apps ( e.g. , F acebo ok, Ub er, Y ouT ube) has gro wn b y an order of magnitude from 164MB in 2013 to ab out 1.9GB in 2017 [4]. In the US, these “gro wing” app sizes mean that softw are up dates now account for a big ch unk of cellular bandwidth across the countr y [31, 34]. Un- surprisingly , studies already show that larger mobile applications lead to stabilit y or usabilit y problems on constrained net works [20, 21, 37]. In concrete terms, this means that users in developing regions will find it difficult or imp ossible to access some of the most popular mobile apps critical to economic and educational developmen t, despite studies that sho w tremendous impact from mobile apps on agriculture, health and education [3, 24, 5]. F or example, Duolingo, the p opular app for learning foreign languages, has an install pack age of size 20MB, and as of May 2018, pro- vides frequen t up dates with bug fixes that require a full do wnload of the app each week. Khan Academy , the p opular online education app, has an install pac k age of 22MB, and updates its softw are roughly once ev ery 2 w eeks. Other p opular applications also hav e surpris- ingly large install pack ages. Co deSpark Academy is at 59MB, F aceb o ok is at 65MB, and Uber takes 61MBs to download. Even simple apps from American Airlines and McDonalds require 83MB and 43MB to download respectively . A t first glance, these trends seem to predict a widen- ing digital divide where developing regions are losing ac- cess to critical parts of the mobile app ecosystem. But is the situation truly as dire as it seems? In tuitively , 1 it seems unlikely that this staggering growth in size of mobile apps is truly driven by gro wth in functionalit y . What factors other than functionalit y are contributing to this growth? P erhaps more imp ortantly , how muc h of this growth is truly necessary for mobile apps, and ho w mu ch can b e traded off in return for app sizes more friendly to bandwidth-constrained net w orks? In this pap er, we describ e our efforts to answer these questions, through a deep er understanding of factors that contribute to the accelerating growth in the size of mobile applications. W e use a v ariet y of empirical to ols and techniques to break do wn mobile applications 1 , and find that for a large num ber of mobile apps across all categories, m uch of the increases in app size can b e at- tributed to the casual inclusion of b oth resource files and link ed softw are libraries, m uc h of which is nev er called b y th e mobile app co de. These findings suggest it is p ossible to produce significantly smaller mobile apps suitable for bandwidth-limited net works b y trimming unreferenced library code and making bandwidth-a w are tradeoffs with resource files. Our hypothesis is partially v alidated by the p opular- it y of mini-programs [10, 42] or mini-apps [40], apps with extremely small fo otprints that run on top of mo- bile platforms in China. While some of them ha ve re- duced functionalit y compared to their mobile app coun- terparts, others retain similar functionality but at a small fraction of the pack age fo otprint to meet the re- source constrain ts imposed by their paren t apps, e.g. , W eChat and Alipay 2 . F or example, W eChat limits its mini-programs to an installation pac k age of 2MB. Tigh t limits on app pack age size allow these platforms to adopt a load-on-demand approac h to app discov ery , where users can discov er and run mini-programs “instant ly” with negligible dela y . In our study , we analyze a large selection of Android apps to understand the different softw are comp onents and their contributions to ov erall app size. In the pro- cess, we identify m ultiple types of “co de bloat” that can b e trimmed from app pac k ages without impact to func- tionalit y , including unreferenced third-part y co de and redundan t resource files. W e also dev elop generalizable tec hniques for trimming co de bloat from existing mobile apps. Our results sho w that combined with compacting images and do cumentation, eliminating co de bloat can significan tly reduce the pack age size of many existing apps, making them m uc h more usable in bandwidth- constrained en vironmen ts such as dev eloping regions. W e summarize our k ey contributions as follows: 1 Giv en the dominance of Android smartphones in dev elop- ing regions [23], we fo cus exclusiv ely on Android apps in this study . 2 W eChat is the dominant mobile messaging and so cial plat- form in China (1B+ users), and AliPa y is the dominant mobile paymen t system in China. • W e perform co de analysis on a selection of p opular Android mobile apps in detail to understand po- ten tial sources of code bloat. T o iden tify p otential b enefits of mini-program platforms lik e W eChat, w e implement a mini-program from scratch with iden tical functionality as an existing Android app, and analyze them to understand sources of app size discrepancy . W e iden tify the size of link ed lib raries as a key contributor. • W e perform detailed analysis of 3200 of the highest rank ed Android apps on Go ogle Play app store, and confirm that link ed libraries are a dominan t factor in their ov erall app size. W e use static anal- ysis to identify unreferenced metho ds and classes, and use automated to ols to remov e unreferenced co de from these apps. W e run a state exploration to ol to estimate usage of resources, and find that significan t pruning is p ossible for both code and resources. • Based on our results, W e introduce the idea of a streamlined mobile app platform for bandwidth- constrained netw orks, and prop ose an automated pro cess to reduce co de bloat in existing Android apps. It packs commonly used APIs in to a single library , allo wing for reuse and minimizing p er-app pac k age size. This platform could b e deploy ed by mobile phone OS developers lik e Go ogle Android or by app (platform) developers like T encent. W e note that Go ogle is already spearheading devel- op er initiatives for more light w eigh t mobile phone de- sign in their “Building for Billions” initiativ e 3 . Our ef- fort is complementary , in that w e fo cus more on the question of bloat for existing Android Apps, and ho w they could b e retrofitted to p erform b etter in constrained net works. W e hop e this w ork leads to conti nued efforts on co de trimming for existing m obile apps, and provide s additional support for light weigh t developmen t efforts lik e Building for Billions. 2. B A CKGROUND AND RELA TED WORK Mini-programs and Ligh tw eigh t Apps. W e b egin b y provi ding some background on the develop- men t of mini-programs by W eChat and Alipay . Mini- programs provide an extreme example of what is p ossi- ble if co de size were prioritized ov er all other concerns. W eChat and Alipay are the tw o largest Internet apps in China, in both users and influence. W eChat is a ubiquitous messaging platform with a p erson-to-p erson mobile paymen t comp onent that has b ecome more ac- cepted in China than cash. Alipa y is a Chin ese financial conglomerate that dominates the mobile paymen t mar- k et. While W eChat migh t b e analogous to a union of 3 https://developer.android.co m/topic/billions/ 2 F aceb o ok and V enmo, Alipay might b e a com bination of Pa yP al and Amazon. W eChat’s goal for its mini-programs is to introduce users to new apps in real time, often scanning a QR co de to instan taneously install and run a mini-program [10]. Th us mini-programs hav e to b e extremely small in size. The current limit is 2MB for the entire installation pack- age, including co de, libraries and resource files. In re- alit y , this dev elopmen t effort elev ates W eChat to an app ecosystem capable of competing against Apple’s AppStore or Go ogle Pla y (whic h is blo ck ed in China), and W eChat encourages its users to bypass traditional app stores entirely . Since launching in January 2017, W eChat no w runs 580,000 mini-programs, compared to 500,000 mobile apps published b y Apple’s AppStore be- t ween 2008 and 2012 [39]. The popularity of W eChat mini-programs led to a comp eting effort from AliPa y , which launched their o wn “mini-app” platform in October 2017 [40]. AliPa y’s plat- form also set 2MB as the limit for install pac k age size, with an internal limit of 10MB for storage. Giv en their similarit y , we fo cus our analysis on W eChat mini-programs, and use mini-programs in the pap er tp refer to W eChat mini-programs. Mini-programs and mini-apps also share prop erties with several other alternative light w eigh t app platforms. Web Applic ations are accessible via the mobile device’s W eb bro wser like Safari or Chrome. The app runs on the server and visual elements are sent to the mobile device. Go ogle announced Andr oid Instant Apps [15] at Go ogle I/O 2016. Users can tap to try an instan t app without installing it first. An instant app only loads p ortions of the app on an on-demand basis. W e note that our goal is to streamline mobile apps that run on the device, whic h differs from these platforms, since they b oth rely on netw ork infrastructure. Redundan t Co de And Library Usage. Co de redundancy is a common phenomenon in soft ware en- gineering. It is often the case that the clien t co de uses an API in an inefficien t wa y [25]. A v ariet y of solutions ha ve b een proposed to help dev elopers detect redundan t co de in their pro ject s during the dev elopment pro cess. Derr et.al [8] show ed that extensiv e use of third-party li- braries can introduce critical bu gs and securit y vulnera- bilities that put users’ priv acy and sensitiv e data at risk. Ka wryko w et.al [25] developed a to ol to automatically detect redundant co de and improv e API usage in Ja v a pro jects. Lammel et.al [29] designed an approach to deal with large-scale API-usage analysis of open-source Ja v a pro jects. This technique helps with designing and defending mapping rules for API migration in terms of relev ance and applicabilit y . W ang et.al [41] proposed t wo qualified metrics for mining API-usage patterns, i.e., succinc tness and co v erage. They further prop osed a no vel approach called Usage P attern Miner (UP-Miner), T able 1: Constraints on Mini-Programs Restricted Item Description Pag e Depth ≤ 5 Pac k age Size ≤ 2M B (8MB if using subpack age) Local Storage ≤ 10M B per user (W eChat) API Usage W eChat offers certain APIs for dev elopment for mining succinct and high-co verage usage patterns of API metho ds from source co de. 3. MINI-PR OGRAMS VS. MOBILE APPS The proliferation of mini-programs in China pro ves that for hundreds of thousands of mobile apps, their core functionality could b e implemented in an extremely compact form. The question is, what are the trade- offs necessary to obtain that compact implementat ion? What accounts for the difference in co de size; is it more efficien t co de, or were there significant losses in func- tionalit y? In this section, w e search for an answer by comparing mini-programs to their Android app coun- terparts, in b oth app conten t/features and co de struc- ture. W e describ e tw o detailed illustrative examples, and then presen t results of empirical analysis of 200 of the most popular mini-programs and their Android app coun terparts. 3.1 Overview Mobile apps face little design constrain ts other than size limit. Go ogle Pla y [11] limits Android apps by 100MB (Android 2.3+) but allows tw o expansion files totalling up to 4GB; iOS allo ws 4GB for an y submis- sion to its App store [2]. A recent measurement study in 2017 shows that the av erage sizes of iOS and Android apps are 38MB and 15MB, resp ectively [4]. Mini-programs must abide b y a num ber of restric- tions, in their page depth (max n um b er of links nec- essary to reach an y page), lo cal storage, installation pac k age size, and API usage, whic h we summarize in T able 1 4 . W eChat 6.6.0+ allows the usage of subpack- ages in mini-programs, but still limits the size of a sin- gle pack age to 2MB and the total sum of all pack ages to 8MB. T o meet these constrain ts, developers often simplify app features and user interface (UI) elemen ts in mini-program versions of their mobile app. F urther- more, mini-programs use Jav aScript rather than Jav a (used by Android apps). W e note that while co de size across these tw o languages can v ary (up to 20% [33]), an y syntactical differences are unlikely to b e meaning- ful. This is b ecause APKs and mini-progr ams are stored under compression, and compression algorithms are likely to b e more efficient on more verbose representations. 4 W e omit Game mini-programs in our table, whic h are gran ted 50MB for lo cal storage. 3 T able 2: Common structure of mini-program installa- tion pac k age. File / F older Name Description Correspondence in Android APK app-service.js Main program logic codes Android Dex files app-config.json Common settings file AndroidManifest.xml page-frame.html The in tegration of lay- out files of all pages Lay out files Pages folder CSS configuration files of every page Lay out files Other folders or files Other resource files Other folders or files Using a common unpack tool [27] to parse mini-programs, w e are able to compare the ov erall co de comp osition of mini-programs and their Android counterpar ts (see T a- ble 2). Implemen ted using Ja v aScript, a mini-program’s main program co de resides in app-servic e.js , which is analogous to the Jav a Byteco de file i n the Andr oid APK ( i.e. , Android Dex file). There is a common setting file ( app-c on.json ), analogous to Andr oidManifest.xml file in the Android APK. Each page app eared in the mini-program is registered in the common setting file, and there is a folder for every page to include its CSS configuration. The main page design code (HTML) is pac k aged in p age-fr ame.html , analogous to Lay out files in Android. 3.2 Code Package Composition Next, we p erform detailed comparisons b etw een tw o mini-programs and their Android coun terparts. One program is a p opular Andr oid app whose developers im- plemen ted their own mini-program, and the other is an Android app for whic h w e implemen ted a mini-program that precisely replicated its functionalit y . Example 1: Y ouDao T ranslation Dictionary . Y ouDao is a v ery p opular m ulti-language (7+ languages) trans- lation dictionary app, whic h has an official mini-program v ersion. As shown in Figure 1, the mini-program in- cludes the app logo and an input b ox for translation, while the full app provides a more sophisticated UI and sev eral extra features (camera translator, h uman trans- lator, audio word search, courses and v ocabulary b o ok). T able 3 lists the p er-comp onent co de comparison b e- t ween the mini-program and the Android app (we dis- cuss these comp onen ts in more detail later in § 4). W e see that the total fo otprint for the mini-program is 0.2MB, compared to 47.2MB for the Android app (219X smaller!). Across eac h analogous comp onen t, the mini-program v ersion is smaller b y at least a factor of 100! This is an example where all aspects of the Android app w ere com- pacted to generate its matc hing mini-program. While the core functionalit y remains, some non-core features w ere cut and the UI was simplified. Tex t a r e a 't o 'i n p u t 't h e '' tex t' to'b e' trans late d (a) Mini Program Cam er a& trans lator Sear ch&f or& words&in&voice Advertise ments Feat u r e&bu t t o ns Recommen ded&co lumn Tex t a r e a &t o &i n p u t &t h e& & tex t& to&b e& trans late d (b) Android App Figure 1: NetEase Y ouDao Dictionary App Choos e& the & area&t o&chec k & the&wea ther Refresh button Cho o se &area & button& The&weather& info r mat ion (a) mini-program Choose & the & area&t o&chec k & the&wea ther Cho o se &area& button& Refresh button The&weather& info rma tio n (b) Android App Figure 2: T o day W eather App Example 2: T o da y W eather App. In an app lik e Y ouDao T ranslation Dictionary , the developer made sp ecific tradeoffs in choosing which areas to trim. W e w anted to find a more con trolled example where full functionalit y w as preserve d in the mini-program, so w e could b etter understand the impact of compressing com- p onen ts unrelated to core features. The only w a y to en- sure a tr ue appl e-to-apple comparison w as to implement a mini-program ourselves, and ensuring that function- alit y of the Android app was preserv ed perfectly . W e found a reasonably sized Android app with no matc hing mini-program, the T o day W eather app, an Android app from the 360 app store, which pro vides cit y-wise weather conditions in China. Figure 2 shows the T o day We ather app and its mini-program ve rsion. T o build a matchi ng mini-program, we first decom- piled the Android app from its Dalvik bytecode in to Ja v a bytecode using the w ell-known to ol dex2jar [36]. Since the app’s program co de, logic and function calls are all accessible, we replicated them completely with one minor exception 5 . W e also made sure that resource files lik e images were also iden tical to their Android coun terparts. W e tested our mini-program thoroughly to confirm that it offers the same interfaces, program logic, resources, and function calls. 5 Due to securit y restrictions on mini-programs (HTTPS requests only), we had to change HTTP requests in the Android app to HTTPS requests in the mini-program. This minor change should hav e zero impact on the outcome of our analysis. 4 T able 3: Pac k age analysis of mini-program and Android app version of Y ouDao Dictionary . Android App Mini Program T otal installation pack age size APK size 47.2MB WXAPKG size 0.215MB F older size 60.6MB F older size 0.232MB Res Resources Images 12.25MB (21.21%) Images 0.161MB (69.40%) L ayout files 2.47MB (4.08%) HTML/C SS 0.049MB (21.12%) Assets Resources Assets 17.43MB (28.76%) - - C++ Library Lib 15.3MB (25.25%) - - Procedure Co de Andr oid Dex file 10.5MB (17.33%) app-servic e.js 0.015MB (6.47%) T able 4: Pac k age analysis of mini-program and Android app version of T o day W eather. Android App Mini Program T otal installation pack age size APK size 527 KB WXAPKG size 82.1 KB F older size 1452.01 KB F older size 81.84 KB Res Resource Images 65.63 KB (4.52%) Images 30.17 KB (36.88%) L ayout file 6.80 KB (0.47%) HTML/CSS 42.82 KB (52.32%) Assets Resource Assets 0 KB (0%) - - C++ Library Lib 0 KB (0%) - - Procedure Co de Andr oid Dex file 1361.92 KB (93.80%) app-servic e.js 8.38 KB (10.23%) Configuration File A ndroi dManifest.xml 2.42 KB (0.17%) app-config.json 0.47 KB (0.57%) T able 4 lists the pack age analysis of the tw o programs. While providi ng the same feature, program logic, re- sources and net w ork requests, the mini-program still ac hieves significant reduction in app size: 82.1KB vs. 527KB (compressed) or 1452KB (uncompressed) for the Android app, mapping to a factor of 6x to 18x. A closer look shows that while the pro cedure co de file in the Android app o ccupies 1.36MB (93.80% of the pac k age after decompressing the APK), the correspond- ing co de file in the mini-program is only 8.38KB, whic h is 160 times smaller! In fact, the pro cedure co de file of the Android app is dominated by the Jav a library file, whic h tak es up 95.59% of the code space. At least in this example, we find that we can significan tly trim an Android app while preserving functionality and con ten t (images and features). The k ey here is streamlining the pro cedure co de, and more specifically , its Jav a library file. Summary of Findings. These tw o examples show that developers can achiev e drastic reductions by shrink- ing all comp onents of mobile apps, including features and conten t (e.g. images). But even while preserving features and con ten t, w e can ac hiev e significant savings b y handling libraries more efficiently . W e revisit this in more detail in Section 4. 3.3 Pair -wise Package Analysis No w that w e hav e a high lev el sense of potential ar eas for trimming mobile apps, w e extend our comparison of Android apps and mini-programs to 200 of the most p opular app pairs. The goal is to get a high level picture of how co de, resources (e.g. images) and functionality compare across p opular mobile apps, and ho w m uc h ro om for trimming eac h category represents. Dataset. W e build a list of p opular mini-programs from the mon thly list of top-100 mini-programs pub- lished by aldwx.com 6 . W e include all mini-programs ev er to app ear on the top-100 list b efore October 2018. F or each mini-programs, we iden tify their correspond- ing Android app counterpart using a com bination of application name, dev elop er, official identification, and man ual confirmation. Our final dataset includes the 200 popular mini-programs and their official Android app coun terparts. F or eac h mini-program and Android app pair, w e an- alyze sev eral key metrics to b etter understand how the t wo differ in con tent, functionality and soft w are pack age size. • Instal lation p ackage size: the installation size for mini- program (WXAPKG size) and the Android app (APK size). • Image size and numb er of images: total size of all image files and total n umber of image files in the re- sp ectiv e pack ages. Applications with rich er features tend to hav e more images. • Page c ount: a measure of num b er of features pro- vided b y the application. Since mini-programs reg- ister individual pages in their common settings file, i.e. app-c onfig.json , we use this to count the pages for eac h mini-program as a measure of features in the program. Android apps register each activity in their Andr oidManifest.xml file, and we use the num- b er of activities as the measure of features for An- 6 https://www.aldwx.com/ is a third-party statistics plat- form for W eChat mini-programs. 5 0 2 5 5 0 7 5 1 0 0 1 2 5 1 5 0 1 7 5 2 0 0 A n d r o i d A p p S i z e R a n k 0 . 1 1 1 0 1 0 0 I n st a l l a t i o n P a c k a g e S i z e ( M B y t e ) A n d r o i d A p p s M i n i P r o g r a m s (a) Installation pack age size 0 2 5 5 0 7 5 1 0 0 1 2 5 1 5 0 1 7 5 2 0 0 A n d r o i d A p p S i z e R a n k 1 0 − 3 1 0 − 2 1 0 − 1 1 0 0 1 0 1 I m a g e S i z e ( M B y t e ) I m a g e S i z e o f A n d r o i d A p p I m a g e S i z e o f M i n i Pr o g r a m 0 2 0 0 0 4 0 0 0 6 0 0 0 8 0 0 0 1 0 0 0 0 I m a g e C o u n t I m a g e C o u n t o f A n d r o i d A p p I m a g e C o u n t o f M i n i Pr o g r a m (b) Image size and image count 0 2 5 5 0 7 5 1 0 0 1 2 5 1 5 0 1 7 5 2 0 0 A n d r o i d A p p S i z e R a n k 0 2 0 0 4 0 0 6 0 0 8 0 0 1 0 0 0 1 2 0 0 P a g e C o u n t A n d r o i d A p p s M i n i P r o g r a m s (c) F eatures (count of pages/activities) 0 2 5 5 0 7 5 1 0 0 1 2 5 1 5 0 1 7 5 2 0 0 A n d r o i d A p p S i z e R a n k 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 P r o p o r t i o n P r o c e d u r e C o d e C + + L i b r a r y I m a g e s O t h e r F i l e s (d) P ack age composition: Android 0 2 5 5 0 7 5 1 0 0 1 2 5 1 5 0 1 7 5 2 0 0 A n d r o i d A p p S i z e R a n k 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 P r o p o r t i o n Pr o c e d u r e C o d e I m a g e s O t h e r F i l e s (e) P ack age composition: Mini-program Figure 3: Detailed comparison betw een 200 pairs of Android app and its mini program version. The pairs are ranked b y the descending size of the Android APK pack age. droid apps. In our exp erience, mini-program pages correlate roughly with Android activities. • Comp osition of instal lation p ackage: the proportion of individual comp onents that make up the installa- tion pack age, including images, procedure co de and support files. W e use the reverse engineering tool Apkto ol [19] to decompile eac h target Android app and conv ert the Dalvik b yteco de to Smali 7 co de for our analysis. Key Observ ations. W e plot key results from these metrics in Figure 3. All graphs are sorted b y descending order of the size of the Android app, ranked 1 (largest) to 200 (smallest). Thus all graphs are consistent on the X-axis. F rom these results, w e make three main observ ations. • Mini-programs and their equiv alen t Android versions differ significan tly in the size of installation pack- age. Mini-programs are 5-50x smaller than their An- droid coun terparts. Surprisingly , there seems to b e little or no correlation b etw een pack age sizes (Fig- ure 3(a); several large Android apps (tens of MBs in size) translated to some of the smallest mini-programs ( < 100KB). • Not surprisingly , Android apps con tain muc h more images, larger images than their mini-program coun- 7 Smali/Baksmali is an assembler/disassem bler for the dex format used b y Android’s Ja v a VM implementation. terparts (Figure 3(b)). Bigger, more feature-ric h An- droid apps lost more features in the translation to their mini-program coun terparts. • F or most Android apps, program co de (procedure co de and C++ library) dominates the installation pac k age, often taking 60-70% of the total footprint. Images only o ccupy 10-20%. Not surprisingly , images often dominate the muc h smaller installation pac k- ages of mini-programs. Considered as a whole, our analysis of p opular pairs of mini-program / Android apps sho ws that curren t An- droid apps hav e used a v ariet y of techn iques to gener- ate compact mini-program coun terparts, and apps v ary widely in ho w m uch p otential code/resources are av ail- able for trimming. 4. LIBRARIES AND BLO A T IN MOBILE APPS Our results in the previous section identified Jav a Li- braries as a p otential culprit for the rapid growth of in- stall pack ages in Android apps. Here, we take a closer lo ok at how resource files, libraries and co de mak e up the comp onents of an Android app, by examining the co de structure of a large range of popular Android apps. Android App Dataset. W e build a large set of p opular Android apps and use it for our co de analysis and co de-trimming experiments. W e start with a rank- ing of top free Android apps from the popular app ana- 6 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 C o n t r i b u t i o n t o A p p si z e 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 C D F A sse t s C + + L i b R e s P r o c e d u r e C o d e Figure 4: Con tribution of C++ Libraries, Pro cedure co de, Resources and Assets to Android App size. lytics platform App Annie 8 . W e choose top 32 Android app categories from Go ogle Play , and do wnload the top rank ed 100 apps in each category , for a total dataset of 3200 apps. Average app size is 22.70 MB. Popular apps in our dataset include Duolingo, Khan Academy , W almart, Ub er and McDonald’s. 4.1 Components of Android Apps As we did earlier in T ables 3 and 4, we divide the comp onen ts of an Android app into four key categories: R esour c e files , Assets , C++ Libr ary files , and Pr o c e- dur e c o de files (including Java Libr aries) . Resource files (files in the r es directory) and Assets (files in the assets directory) b oth include images and supplemen tary con- ten t, but differ in how they are used by the app. Assets tend to co v er documentation, icons, and other m ultime- dia files, while resource files are accessed by the app in memory via resourceIDs. C++ Library files are exter- nal libraries accessed via Jav a Native In terface (JNI), and pro cedure co de files represent both core Jav a co de and Ja v a Libraries. Figure 4 sho ws ho w these four comp onents contribute to the app size, across the 3200 Android apps in our dataset. The exact contribution p er comp onen t v aries across Apps, but the pro cedure co de file is generally the biggest contributor. F ortunately , C++ Library files (whic h are likel y to b e the hardest to mo dify or trim) are reasonably small contributors to co de size on most apps. Instead, it seems there is ample opp ortunity to optimize pro cedure co de files, along with resources in /r es and resources in /assets . 4.2 Impact of Ja va Libraries W e observed earlier that Jav a libraries can add sub- stan tially to the co de size of an Android app. Here, w e study how Jav a library co de (a sub-comp onent of pro cedure code) contributes to ov erall pack age size in Android apps. Ja v a libraries can be further classified as official or third-party libraries. Many Android apps use third-part y libraries, e.g. , adv ertising service libraries to generate reven ue [28]. The official libraries are offered b y Go ogle, and can b e identified by their names, e.g. , 8 h ttps://www.appannie.com/ Android.support.v4. W e detect third-part y libraries us- ing an existing framew ork called LibRadar [30]. Figure 5 quan tifies th e code size of Ja v a libraries from differen t p ersp ectives. Figure 5(a) plots, for each of our 3200 apps sorted by pro cedure co de size, the absolute size of total pro cedure co de (blue dot) and the abso- lute size of Jav a Libraries (red dot). F or both, the co de size is the size of the Smali files obtained after decom- pilation. Our k ey observ ation here is that for the ov er- whelming ma jority (96.7%) of apps, pro cedure co de is dominated by Jav a libraries. This is further confirmed in Figure 5(b), whic h plots the CDF of the ratio b etw een Ja v a library code size and t otal pro cedure code size. F or more than 55% of apps, Jav a library co de accounts for more than 70% of total co de size. Non-Jav a library co de mak es up the ma jority of pro cedural co de in only 17% of apps. Figure 5(c) shows that this dominance by Ja v a libraries is consisten t across app categories. 4.3 Library Management in Android vs. Mini- Programs While pro cedure co de in Android apps is dominated b y Ja v a libraries, co de in mini-programs are not domi- nated by their libraries. This can b e directly attributed to how libraries are managed b y W eChat mini -programs and their Android counterparts. Figure 6 illustrates the tw o library managemen t mechanisms, which we de- scribe next. Android apps. Eac h Android APK includes b oth library code and app-sp ecific co de (codes written by app developers). F or example, A ndr oid.supp ort.v4 is a library pack age and c om.example is a custom code pac k age. When generating an APK, all library codes and custom co des are pack ed in to the same APK. W eChat mini-programs. The library file used b y W eChat mini-programs is the lib appbr andc ommon.so file in the lib dictionary of the W eChat app. When gen- erating a mini-program, only custom co des are pack ed in to the mini-program, and not library files. In other w ords, mini-programs do not include library files in its installation pack age, but uses the library file included in the W eChat app. This k ey difference lik ely arises from the lac k of con- sistency in application libraries across Android devices. Apps packing their own library co de impro v es robust- ness and increases the likeli ho o d of the app running on differen t devices and Android versions. The price for this robustness is redundan t library co de pac k ed in to the APK files of each Android app. In contrast, the con- sistency offered b y W eChat’s o wn mini-program plat- form means mini-programs can make stronger assump- tions ab out library v ersioning, and a single common li- brary can b e shared across all mini- programs. This dra- matically reduces the duplication of library code across apps or mini-programs. 7 0 5 0 0 1 0 0 0 1 5 0 0 2 0 0 0 2 5 0 0 3 0 0 0 A p p s R a n k e d b y T h e P r o c e d u r e C o d e S i z e 0 1 0 0 2 0 0 3 0 0 4 0 0 5 0 0 6 0 0 7 0 0 P r o c e d u r e C o d e S i z e ( M B y t e ) S i z e o f L i b r a r y C o d e S i z e o f T o t a l C o d e (a) Absolute co de size 0 . 0 0 . 2 0 . 4 0 . 5 0 . 6 0 . 7 0 . 8 1 . 0 R a t i o o f J a v a L i b r a r y C o d e S i z e 0 . 0 0 . 1 7 0 0 . 2 0 . 4 0 . 4 4 2 0 . 6 0 . 8 1 . 0 C D F (b) CDF of Jav a Lib size/Pro ce- dure co de size 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 3 0 3 1 3 2 C a t e g o r i e s 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 A v e r a g e L i b r a r y R a t i o (c) Av erage Jav a size ratio across app categories Figure 5: Comparing the Jav a library co de size to the total pro cedure co de size. (a) absolute co de size of the total pro cedure code (blue) and that of the Jav a libraries (red); (b) distribution of (Jav a library size/Pro cedure co de size); (c) a verag e (Jav a Library size/Procedure size) across 32 app categories. . M in i - P r o g r am P ac k ag e WeCh a t Ap p Cu s t om Cod e l i b a p p b r a n d com m on . s o app - se rvi c e .j s Android App Android OS Custom Code android.os Android.support.v4 Com m on L i b r a r y Cod e F o r M i n i - P r o gr ams Library Code com.example (a) Android App Mini - Program Pack age WeChat App Custom Code libappbrandcommon.so app - service.js A n d r o i d A p p An d r o id OS Cu s t om Cod e an dr o i d. o s A n d r oi d . s u p p or t . v 4 Common Library Code For Mini - Programs L i b r a r y Cod e com . e xa m p l e (b) W eChat Mini-Program Figure 6: Library Mec hanism of Mini-Program and Android App 5. TRIMMING CODE AND RESOURCES ON ANDR OID APPS Our early analysis of the W eather mini-program in Section 3 show ed that some apps included large (and lik ely unused) Ja v a libraries in their install pack age. The size of these Jav a libraries could account for signif- ican t co de size discrepancy b etw een Android apps and mini-programs. Our additional h yp othesis is that most Android apps only use a small subset of mo dules in Ja v a libraries, but developers often import the en tire library b ecause manually identifying the co de snipp ets for the target modules is lab or-inte nsive. As a result, signifi- can t portions of the pac k age co de is actually un used by the app, i.e. “code bloat,” and should b e trimmed. In this section, w e prop ose a systematic framew ork to trim Android apps: including iden tifying co de bloat, remo ving it, and then repacking the app. W e can p er- form similar op erations to identify resource bloat ( e.g. un used images) and remov e them from the app. Here, w e describe our prop osed process for trimming program co de ( § 5.1) and resources ( § 5.2), and a pro cess that in- tegrates b oth. Later in § 6, we ev aluate the effectiv eness of our proposed app trimming tec hniques and usability of the trimmed apps. 5.1 T rimming Code Bloat Our trimming framew ork consists of four sequential steps: preprocessing, code decompilation, co de bloat detection, and app repac king and v alidation. It tak es as input an Android installation pack age, and outputs a repac ked app with co de bloat remov ed. More sp ecif- ically , we first prepro cess the input app, then unpack it using the dex2jar tool where Dalvik b yteco de gets transformed to Jav a b yteco de. W e then leverage Pro- guard [16], a Jav a class file shrink er, optimizer and ob- fuscating to ol to identify and trim co de bloat. Finally , w e repac k the app and v alidate that its functionalit y has not b een disrupted b y the trimming pro cess. W e no w describ e these steps in detail. Prepro cessing. The goal of prepro cessing is to iden tify Android apps that cannot b e decompiled and repac ked due to built-in securit y mechanisms (e.g. en- cryption or co de signatures) that preven t co de mo di- fication or decompilation [28] (more discussion in § 7). The preprocessing step tests Android apps by first re- signing the app (as a different developer from the orig- inal) and chec k if it can still run prop erly , and if suc- cessful, then decompiles the app using b yteco de trans- formation, repac ks the app, and then re-signs the app. If the re-signed app passes b oth tests, it is suitable for co de trimming. Note that this limitation only applies b ecause we are an un trusted third part y . Google or an authorized third party could use authen ticated to ols to b ypass an app’s protection mec hanisms and enable co de trimming. Iden tifying and Remo ving Co de Bloat. T o iden tify co de bloat, we first apply the dex2jar to ol to con vert the app’s Dalvik bytecode to Ja v a bytecode. Here the conv ersion supp orts b oth apps with single-dex 8 1 public class MainActivity extends AppCompatActivit y { 2 protected v oid onCreate(Bundle sa v edInstanceState) { 3 super .onCreate(sav edInstanceState); 4 setCon tentView(R. lay out.activit y main); 5 in t a = 1, b = 2, c = 3, d; d = sum(a, b); } 6 in t sum( int num1, int n um2) { return n um1 + num2 ; } 7 in t sub( int num1, int num2) { return n um1 − n um2; } 8 } Listing 1: The original MainActivit y 1 public class MainActivit y extends AppCompatActivity { 2 public MainActivit y() {} 3 protected v oid onCreate(Bundle v ar1) { 4 super .onCreate(v ar1); 5 this . setConten tView(2131296283); 6 in t v ar2 = this .sum(1, 2); } 7 int sum( int v ar1, int v ar2) { return v ar1 + v ar2; } 8 int sub( int num1, int num2) { return n um1 − num2; } 9 } Listing 2: MainActivit y b yteco de after decompilation and multi-dex. F or apps with multi-dex, we merge the Ja v a bytecodes p er DEX file by their file paths and use a map file to record the file path that will later b e used b y the re-pack step. Next we use the ProGuard tool to explore the app execution space, recursiv ely searc hing for any class and class mem b ers that the app will actually use. Those not found by ProGuard are treated as co de bloat and remo ved from the app pac k age. The searc h of the app execution space requires a seed or en try p oint. F or this w e use MainA ctivity , the actual en try p oint of the target Android app, accessible directly from the global con- figuration file ( Andr oidManifest.x ml ). T o b e conserv a- tiv e, w e also do not trim an y subclass of the Appli- cation, Activity , Service, BroadcastReceiver and Con- ten tProvider class, and instead use them as extra en try p oin ts. F urthermore, b ecause ProGuard only targets Ja v a, w e do not trim the En um class, Ja v a Native Inter- face and construction metho ds as well as widgets used b y the xml files. Finally , our curren t search implemen- tation do es not consider Jav a reflection and dynami- cally loaded code instantiated by the Ja v a class loader, b ecause ProGuard do es not recognize them [17]. This means w e could accidentally trim useful co de, but we can iden tify any such mistak es and recov er during the app v alidation step. An Il lustr ative Example. Here is an example on how to identify and remo ve co de bloat from an app. List- 1 public class MainActivit y extends AppCompatActivity { 2 public MainActivit y() {} 3 protected v oid onCreate(Bundle v ar1) { 4 super .onCreate(v ar1); 5 this . setConten tView(2131296283); 6 in t v ar2 = this .sum(1, 2); } 7 int sum( int v ar1, int v ar2) { return v ar1 + v ar2; } 8 } Listing 3: MainActivit y b yteco de after code trim ing 1 sho ws the Ja v a co de of the MainActivi ty c lass in a sample Android app, where “onCreate” sets the la yout file of the main page. Since onCreate is the entrance to the program, the sub function will not b e used after the program is executed, and should b e trimmed. Listing 2 sho ws the MainActivity Ja v a b ytecode after decompila- tion, where v ariable names are replaced by their v alues, and an y unused v ariables ( i.e. c ) are remo v ed. Listing 3 sho ws the result after code trim, wh ere the un used func- tion sub is remov ed. Repac king and Ap p V alidation. After re-packing the trimmed app, w e need to v alidate if it stil l functions correctly . F or this we follow existing works [28, 7] and run for three minutes an automatic UI tra versal script based on the Appium [1] and Monkey [13] scripts. This script will v alidate the functionality of the trimmed app. It is worth noting that another option for app v ali- dation is the PUMA to ol [18]. Unfortunately , PUMA only supports up to Android 4.3, and a significan t p or- tion of apps (roughly one third of apps tested) fail to install on the Android 4.3 em ulator (due to SDK lim- itations). This mak es PUMA unsuitable for our final app v alidation. But for the 538 apps in our dataset that pass the prepro cessing test and can run on An- droid 4.3, v alidation using PUMA sho ws that 486 apps (90.33%) function prop erly after co de trimming, which is consisten t with our results in § 6. 5.2 T rimming Resour ce Bloat W e also seek to detect and remov e unnecessary bloat in resource files, i.e. , b oth Res resources and Assets. F or this we use static co de analysis to iden tify un used resources in the app, from images to XML files. Sp ecif- ically , we first use Apktool to decompile the target An- droid app for static co de analysis, which conv erts the Dalvik bytecode to Smali co de and parses the resource file. P arsing the resource files allows us to iden tify un- used resource files. Iden tifying Bloat in Res Resources. The r es di- rectory con tains different file types like draw able, string, color, etc. W e only identify bloat in draw able resources lik e images and XML files, b ecause trimming other re- 9 source types requires mo difying the XML file, and can p oten tially disrupt the decompilation and repacking pro- cess. First, parsing resource files will pro duce a ( public.xml ) file in the folder r es/values , which records every res resource’s ID, name and type (dra wable, string, attr, color, array , etc). As w e men tioned in § 4, after they are compiled, any res resource is accessed through its resource ID. T o identify all resources used b y the app, w e can just search for them in eac h Smali file 9 . Iden tifying Bloat in Assets. Assets usually store static resources lik e database files and videos, which are neither co de nor configuration files. Thus resources in assets are not compiled when pack ed into an APK. Since asset resources are accessible by their absolute path in the code, w e can iden tify them b y trav ersal searching the absolute path of each asset resource in each Smali file. Resources not identified by this search are trimmed. 5.3 Putting Everything T ogether Finally , w e can integrate the co de trimming pro cess with the resource trimming pro cess to build a fully auto- mated app trimming framework for Android apps. Our co de is av ailable on GitHub (link remov ed to preserve anon ymity). The ov erall framework is sho wn in Fig- ure 7. It trims the assets, the res resources, and finally the pro cedure co de in sequence. 6. EV ALU A TION In this section, w e ev aluate the p erformance of our proposed app trimming framew ork. W e consider t wo k ey metrics: effectiveness as measured by reduction in mobile app size, and correctness in terms of whether the trimmed app still functions properly . Exp erimen tal Configuration. Our ev aluation considers the 3200 top Android apps describ ed in § 4. T o exp erimen t with this wide range of apps [9], we in- stall these 3200 apps on an Android emulator (Samsung Galaxy S7, Android 8.0), and ran the emulator on tw o iden tical Ubuntu 16.04 mac hines with 6-core 3.60GHz CPU and 100GB memory . 76 out of the 3200 apps fail to install on the em ulator, while 204 apps fail to run properly after installation. W e remo v ed them from our exp eriments. In the end, our exp eriments used the remaining 2920 apps to test the effectiv eness and cor- rectness of our trimming framew ork. 6.1 Effectiveness of App T rimming Figure 8 plots the CDF of the absolute app size re- duction, the normalized app size reduction and the p er comp onen t reduction normalized by the app size. F rom Figure 8(a-b), w e see that for 40% of the apps, trimming 9 Here we need to exclude any res resources found in the R class Smali files, since those files include all res resources. the app can reduce the app size by at least 10MB, or at least 52%. Here are some sp ecific examples: Duolingo reduces from 19.87MB to 12.07MB, Khan Academy re- duces from 21.94MB down to 16.48MB, Ub er reduces from 60.64MB to 31MB, and McDonald’s reduces from 42.5MB to 15MB. Figure 8c further sho ws that trim- ming res resources (images) is highly effectiv e, follo w ed b y trimming pro cedure co de (Jav a library files). These results confirm that our design can effectiv ely and significan tly reduce the size of Android apps by trimming co de and resource bloat. Our trimming pro- cess is fully automated, allowing third-parties to easily generate light w eight mobile apps for developing regions without sacrifi cing basic functionality . F or app dev elop- ers, our framework helps to identify p otential co de and resource bloat for p erformance optimization. 6.2 Correctness of App T rimming Of the 3200 Android apps we tested, 2920 apps passed our prepro cessing steps and were deemed suitable for automated trimming. Of these, 2617 apps (89.62%) passed v alidation and op erated correctly after trimming. Most apps observ ed significant drops in their Ja v a code sizes, with reductions ranging from 60-80% of their or ig- inal size. More than 70% of apps saw a drop in redun- dan t co de of more than 5MB, and a small num b er of apps saw a size reduction of more than 20MBs after automated trimming. 7. DISCUSSION Reducing redundancy during app dev elopmen t. Results of our study show that significant code and re- source redundancy are widely present in to day’s mobile apps. Removi ng or limiting them during app dev elop- men t is quite feasible using existing to ols. T o reduce code redundancy , one potential to ol is Pro- guard [16], which has already b een in tegrated into An- droid Studio [12], the official developmen t environmen t for Android. Deve lop ers can easily edit Proguard con- figurations to remov e redundant co de in their pro ject. Ho wev er, it is also p ossible that dev elop ers who w an t to prev ent co de trimming could use tools lik e Proguard to in tentionally obfuscate their co de. F or example, dev el- op ers up dating their apps o ver time might opt to sav e co de b elonging to deprecated features rather than re- mo ving them fully , since co de remov al might in tro duce bugs that require more effort to lo cate and fix. T o ols also exist for remo ving resource redundancy during app developmen t. Android Lint i s a a co de scan- ning tool provided b y Android SDK and integrated into Android Studio. It helps developers iden tify and correct issues lik e un used resources during developmen t. Our observ ations of high lev els of resource redundancy likel y indicates that few deve lop ers are using Lint. In roughly half of Android apps, more than 50% of asset resources 10 R es o ur c e I D Ap k to o l Tr ave r s al A b s ol u t e P at h R ed und a nc y R e m oval R e s re s ou rce s A s se t s re s ou rce s 1( b) : A s s et s R es ou r c e R edu n da n c y P r oc es s D ex 2 j ar B yt ec o d e Tr an s f or m at i on ( Dal vi k t o J ava ) De c om p i l at i on Fo l d e r 1 ( c la s s es . dex ) c o m .a .u t i l , c o m .a .b ,… Fo l d e r 2 ( c la s s es . dex ) c o m. b . map , com . c ,… M e rge M er g ed B y tec o d e F o ld er : c o m .a .u t i l , c o m .a .b , c o m. b . ma p , c o m. c , … C od e Shr i n k S et E nt r y P o i nt Prog u a rd Proce s s S p lit Ma p F i l e R ep a c ked AP K 2: Code R edu n da n c y P r oc es s 1( a ) : R es R es ou r c e R edu n da n c y P r oc es s U s a b ilit y Te s t i n g O r i g i n al A p p B yt ec o d e Tr an s f or m at i on ( J ava t o Dal vi k ) Fo l d e r 1 ( c la s s es . dex ) c o m .a .b , … Fo l d e r 2 ( c la s s es . dex ) c o m. b . ma p , … Figure 7: The ov erall pro cess of our prop osed app trimming framew ork. 0 2 0 4 0 6 0 8 0 1 0 0 A b so l u t e A p p S i z e R e d u c t i o n ( M B y t e ) 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 C D F (a) Absolute app size reduction 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 N o r m a l i z e d A p p S i z e R e d u c t i o n 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 C D F (b) Normalized app size reduction 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 T r i m m e d C o m p o n e n t / T o t a l A p p S i z e 0 . 0 0 . 2 0 . 4 0 . 6 0 . 8 1 . 0 C D F A sse t s P r o c e d u r e C o d e R e s (c) Normalized amount of compo- nen ts trimmed Figure 8: Our automated, app trimming framework can effectively reduce app size. are redundant, and it is even w orse for res resources: in roughly half of Android apps, more than 80% of res re- sources are redundan t. Since removing un used resources is less lik ely to pro duce complex failure mo des, devel- op ers lo oking to trim bloat should start with resources. Ligh t weig ht app platforms (for dev eloping re- gions). W e show that W eChat mini programs ex- hibit significan t size savings w hen compared to Android apps. Part of this comes from mini-programs’ shared library access, as discussed in § 4. This suggests that a platform for ligh t weigh t (mobile) applications migh t b enefit mobile users in developing regions, using W eChat’s platform as a reference. Placing commonly used code in to a shared, consistent app library would greatly re- duce co de redundancy for mobile apps. Limitations. Finally , w e discuss limitations of our study . First, app decompilation and repacking is kno wn to b e fragile [28]. Errors can creep into the system dur- ing the use of rev erse-engineering tools lik e dex2jar, Ap- ktool and enjarify [14]. F or instance, a unknown op c o de exception was rep orted when w e used dex2jar to trans- late Dalvik bytecode to Ja v a bytecode. This is b ecause that most reverse-engineering to ols read bytecode lin- early and the parse pro cess fails when encountering an in v alid bytecode. Thus developers can preven t third- part y co de trimming b y inten tionally or accidentally inserting inv alid bytecodes in to the Android Dex file. Similarly , steps like parsing procedure co des can b e dis- rupted or slo w ed using unexp ected inputs in procedure co de. Finally , developers can alwa ys use encryption or co de signatures to prev en t or detect alterations to their co de. 8. CONCLUSION AND FUTURE WORK In this pap er, w e take an empirical approach to an- alyzing sources of bloat in to day’s mobile applications. Using W echat mini-programs as a basis for comparison, w e w ere able to iden tify a n um ber of p otential causes for the rapid growth in mobile app pack age sizes. This in turn, allo w ed us to identify techniques to significantly reduce size of existing Android applications b y mo dify- ing and trimming unnecessary co de and resources. While our techniques hav e demonstrated significan t success in our tests, we believe they represen t only ini- 11 tial steps by whic h developers can supp ort mobile users in developing regions. F or example, our w ork helps to address the challenge of do wnloading and up dating apps in bandwidth-constrained netw orks. But many mobile apps today mak e strong assumptions about the av ail- abilit y of netw ork bandwidth, and either fail to op erate fully under constrained conditions, or aggressively con- sume bandwidth to the detrimen t (and high costs) of their users. W e hop e our work and others will lead to treatmen t of bandwidth-constrained net wor ks as a first class consideration, al ong with developmen t of tools and platforms that more easily in tegrate support for low- bandwidth netw orks in to a wide-range of mobile appli- cations. 9. REFERENCES [1] Appium , 2018. [2] Apple . iTunes connect, 2018. [3] Bali, K., Sit aram, S., Cuendet, S., and Medhi, I. A hindi sp eech recognizer for an agricultural video search application. In Pr o c. of A CM DEV (2013). [4] Boshell, B. Average app file size: Data for Android and iOS mobile apps. https://sw eetpricing.com/blog/2017/02/a v erage-app-file- size/, 2017. [5] Botha, A., and Herselman, M. ICTs in rural education: Let the game b egin. In Pr o c. of A CM DEV (2015). [6] Chebr olu, K., Raman, B., and Sen, S. Long-distance 802.11b links: Performance measurements and exp erience. In Pr o c. of Mobic om (2006). [7] Chitkara, S., Gothoskar, N., Harish, S., Hong, J. I., and Agar w al, Y. Do es this App Really Need My Location? Context-Aw are Priv acy Management for Smartphones. In Pr o c. of Ubic omp (2017). [8] Derr, E., Bugiel, S., F ahl, S., A car, Y., and Ba ckes, M. Keep me Up dated: an Empirical Study of Third-Part y Library Up datability on Android. In Pr o c. of A CM CCS (2017). [9] F arooq, U., and Zhao, Z. RuntimeDroid: Restarting-F ree Runtime Change Handling for Android Apps. In Pro c. of the 16th International Confer enc e on Mobile Systems, Applic ations, and Servic es (New Y ork, NY, USA, 2018), MobiSys ’18, ACM, pp. 110–122. [10] Fu, R. An essential guide to wec hat mini-program. China Internet W atc h, 2016. [11] Google . Add or test APK expansion files., 2018. [12] Google . Android Studio, 2018. [13] Google . Android UI Automation and Testing To ol, 2018. [14] Google . Enjarify , a tool for translating Dalvik bytecode to equiv alen t Jav a bytecode by Go ogle, 2018. [15] Google . Instant apps. [16] Guardsquare . Proguard, 2018. [17] Ha o, S., Li, D., Halfond, W. G., and Govind an, R. SIF: a selective instrumentation framework for mobile applications. In Pr o c. of MobiSys (2013). [18] Ha o, S., Liu, B., Na th, S., Halfond, W., and Govindan, R. Puma: Programmable ui-automation for large scale dynamic analysis of mobile apps. In Pr o c. of MobiSys (2014). [19] iBotPea ches . Apkto ol, 2018. [20] Ihm, S., P ark, K., and P ai, V. S. T ow ards understanding developin g world traffic. In Pr o c. of A CM Workshop on Networke d Systems for Developing R e gions (2010). [21] Isaa cman, S., and Mar tonosi, M. Low-infrastructure methods to improv e internet access for mobile users in emerging regions. In Pr o c. of WWW (2011). [22] Johnson, D. L., Pejovic, V., Belding, E. M., and v an St am, G. T raffic characterization and internet usage in rural africa. In Pr o c. of WWW (2011). [23] Ka t ariy a, J. Apple vs android - A comparative study 2017. Medium: Mo on T ec hnolabs, March 2017. https://android.jlelse.eu/ apple- vs- android- a- comparative- study- 2017- c5799a0a1683 . [24] Ka tule, N., Rivett, U., and Densmore, M. A family health app: Engaging children to manage wellness of adults. In Pr o c. of A CM DEV (2016). [25] Ka wr yk ow, D., and Robillard, M. Improving api usage through automatic detection of redundant co de. In Pro c. of IEEE/ACM ASE (W ashington, DC, USA, 2009). [26] Kirkp a trick, K. Bringing the internet to the (developing) world. Communicatio ns of the ACM 61 , 7 (July 2018), 20–21. [27] leo9960 . wec hat-app-unpac k, 2018. [28] Liu, B., Liuy, B., Jin, H., and Govindan, R. Efficient Privilege De-Escalation for Ad Libraries in Mobile Apps. In Pr o c. of MobiSys (2015). [29] L ˜ Ad ’mmel, R., Pek2, E., and St arek, J. Large-scale, AST-based API-usage analysis of op en-source Jav a pro jects. In Pr o c. of the 2011 ACM Symp osium on Applie d Computing (2011). [30] Ma, Z., W ang, H., Guo, Y., and Chen, X. Libradar: F ast and accurate detection of third-party libraries in android apps. In Pr o c. of the 38th International Confer enc e on Softwar e Engine ering Comp anion (2016). [31] Madegw a, C. T urn off auto app up dates on android and sav e your mobile data. Dignited, F ebruary 2018. [32] Ma tthee, K. W., Mweemba, G., P ais, A. V., v an St am, G., and Rijken., M. Bringing internet connectivity to rural zambia using a collab orative approach. In Pr o c. of ICTD (W ashington, DC, USA, 2007). [33] McLoone, J. Co de length measured in 14 languages. W olfram Blog, Nov ember 2012. [34] Mcmahon, J. How to av oid using up all of your smartphone data. Wired, August 2017. [35] P a tra, R. K., Nedevschi, S., Surana, S., Sheth, A., Subramanian, L., and Brewer, E. WilDNet: Design and implementa tion of high p erformance WiFi based long distance netw orks. In Pr o c. of NSDI (2007). [36] pxb1988 . dex2jar, 2018. [37] Schmitt, P., Ragha vendra, R., and Belding, E. Internet media upload caching for p o orly-connected regions. In Pr o c. of ACM DEV (2015). [38] Surana, S., P a tra, R. K., Nedevschi, S., Ramos, M., Subramanian, L., Ben-Da vid, Y., and Brewer, E. A. Beyond pilots: Keeping rural wireless netw orks alive. In Pr o c. of NSDI (2008). [39] T an, R. Mini-programs: T encen t and alibabaˆ a ˘ A ´ Zs war for consumers stickiness. Innov ation is Everywhere Blog, December 2017. https://www.innovationiseverywhere.com/ mini- programs- tencent- alibabas- war- consumers- stickiness/ . [40] Team, C. Alipay working on its own mini apps. China Internet W atc h, 2017. [41] W ang, J., and et.al . Mining succinct and high-cov erage api usage patterns from source co de. In Pro c. of Working Confer enc e on Mining Softwar e Rep ositories (2013), IEEE, pp. 204–217. [42] WeCha t . W eChat mini program, 2018. [43] Zhelev a, M., P a ul, A., Johnson, D. L., and Belding, E. Kwiizya: lo cal cellular netw ork services in remote areas. In Pr o c. of MobiSys (2013). [44] Zhelev a, M., Schmitt, P., Vigil, M., and Belding, E. Internet bandwidth upgrade: Implications on p erformance and usage in rural zambia. Information T e chnolo gies & International Development (2015), volume 11, issue 2, pages 1–17. 12