Publishing an Android App (Part 2)
This is the second part of “Publishing an Android App” blog. In the last part, we saw what are the basic app components used in this app and how they are interconnected. This part of the blog, focuses on design concepts, app optimisations, branding and publishing the app in app stores.
App UI design Flow:
Initially I was not focussed with the app design and later on as I kept adding features. It was essential that UI design places a major role in app branding, user experience, and even for users to download the app in first place. So I started changing app layouts, making the colors in sync with the app logo and slowly adapted the app to material design. I even used the material design components in the latest version of the app which offered some add-ons like focus listeners, edit text animations, error listeners, that you can extend and add your own implementation on top of it. So I extended them to add error messages whenever user input exceeded the phone number length.
For more on material design you can check here and here and how to use it from here.
Android allows developers to customize literally every attribute of each app component. So I added a vibration effect to the notification which again can be composed like a music composition allowing to adjust the amplitudes and delays between each vibration effect. I can emphasize a lot on this customization capability in android like the below app notification item(shown in left) the (colors, circular image views, background) in First time Installation Screen and the dialog customization(shown in right).
Debugging is indeed an Art:
After the final prototype was ready, I started testing the app with the help of my friend, who over this app development, helped me in identifying the potential bugs by testing it in multiple phones. One such bug was the crash seen in some old android devices like pre Oreo era and in some xiaomi phones, where the app fails to even launch. So going through the debug logs, I noticed that these phones’ software limits the app from using more than 157MB RAM memory during the app startup. I started using the android studio profilers like memory profiler, which neatly tabulates how the app consumes ram memory in real time as we use it.
So the problem was this app was consuming more than 220MB RAM memory during the app startup only when the FTI screens are scrolled by the user. So the reason behind the strange behavior was the images used in the circular view of the FTI screen. They were like pretty large in size compared to the circular view, like one such image was 4000*4000. So what happened was such large bitmaps were placed in ram memory (with each pixel consuming 32bit) adding more memory pressure during app launch and eventually the underlying phone memory management system killed the app as a result of it. So luckily this issue is one of the common memory issues seen in android and there was a ready made solution for it. The solution was to identify the size of image that is about to be drawn before inflating it and reduce its resolution by downsampling it by a factor of 2 until the downsampled resolution image approximately matches circular view size. And after that use the computed downsampled size to inflate the original image in the memory.
Along with this in some devices, the rendering was made to be done in GPU / VRAM memory which again further reduced the RAM memory footprint. Finally like an icing on a cake, reduced the bit representation of each pixel to 8bit instead of 32bit, which brought further more memory savings. Finally I was able to reduce the launch memory usage and prevented the crash by bringing the memory consumption to 112MB during app start period.
You can find this change here and more about memory consumption during image inflation here
Learnings:
To be frank, I learnt a lot while developing this one particular android app. I want it to be like a full fledged app so I learnt how to do OnBoarding screens from watching tutorials, and adding my own changes on it.
Took inputs from others, reduced the unwanted permissions such as read contacts permission which is needed to get the contacts in drop down as user types the contact and read external storage permission to read the user configured ringtone which serves as notification. Since it has a lot to do with user privacy, I replaced that contact permission by using intents to launch the contact app and let the user pick from them instead.
And for ringtone, I bundled a custom ringtone inside the app and played that as notification.
My app size was considerably huge, so I made use of Proguard and resource shrinking tools which considerably reduced the app size to small. You can go through this medium blog for more info.
During the course of this, I learnt about threading frameworks in android, how to use github effectively and create a perfect github project readme, integrating VCS with android studio, documenting & managing an android app from scratch, efficient use of diff tools like meld software.
But one thing I learnt for sure, going by android API documentation and creating an android app just by reading that only, makes one’s life really difficult. The documentation has a lot of details, you can easily be lost. The best way is to learn by seeing some tutorials, incorporating own ideas to them, using documentation only for reference, making use of available development tools will bootstrap your app ideas to reality. To solidify the app concepts, one can also take these free android courses. The android basics course will surely help.
And I also learnt a little bit about how SMS technology works, how the cellular network sends these packets, how GSM technology manages internet connections as they have a separate stack to that of IP network, why each SMS packet is limited only to 160 characters, how the carrier performs SMS packets merging, how android exposes these SMS packets to app developers (like which API to use)and so on.
Publishing the app:
After putting a lot of effort into this app, I didn’t want this app to stay as POC, instead I wanted to publish in PlayStore and get real feedback from the end users. Publishing an app in Google Play involved getting a PlayConsole account. I checked some youtube videos like how to use the play console to publish apps. One of the steps involved in creating a feature graphic / promotion banner for play store listing. I could have used adobe XD but I resorted to a simpler solution, using Canva service for designing these banners (like the one shown below).
Then, I used this tutorial for app signing, yes android developers need to sign their apps such that no one except the original app developer can publish an update to the same app. We have an app signing key, which is the key used to sign the app. So that in google console, we can upload our app signing keys, & it will securely sign our apps in the cloud, instead of managing the keys locally. This prevents developers from the headache of losing app signing keys. More on this you can refer here and here
Apart from managing app signing, google play allows different test tracks (testing channel closed to a specific group of users, or open to all users, or to release it as a beta version before performing production rollout). After rollout, they have various statistics on our app performed on various devices, how many app crashes that user encountered, app’s rendering performance, how many users installed and uninstalled your app and so on.
So before configuring the test tracks and performing rollout, users need to complete the permission declaration step, if they are using any dangerous permissions like our app uses READ_INCOMING_SMS(for triggering notification) and there is a privacy policy to be filled out concerning that the user data only used for legitimate and fair purposes(like to support core app functionality), not for sharing any details to ad agencies.
So I too filled out the permission declaration form, but unfortunately my app’s functionality didn’t fall under the exception list categorized by google for read incoming sms permission. So I added it to a closer category(Device Automation) that models my app functionality in that list. And I also published a step-by-step how to use app video demonstrating the app’s use and why it needs to be published. In Spite of doing all these, my app got rejected, so I raised a permission appeal, such that it will be looked by a specialist in google play team. But the answer was still no, their concern was my app didn’t fit well in the device automation category and moreover they weren’t ready to help me out.
So I resorted to other app stores like amazon app store and published my app within 2 days. It is completely free and though it doesn’t offer much features(app signing, pre launch reports) like google play console. They atleast test the app in a few of their kindle and android devices, and acknowledge individual developers’ contribution. Though it’s not a great alternative to google play, it still serves as a place to test and deploy for multiple android devices. You can download this app from here.
And in the process of searching for an alternative store, I stumbled upon F-droid (Free and open source app store) where they build the app from the direct source repository itself. The cool thing that the F-droid store listing is populated from the github repo itself, just metadata needs to be created. I had published this app already in F-droid.
So publishing an app taught me lot of things about release cycles, open source and what is free software, how different app stores work, how the build happens, why the app signing is performed, how android studio performs code reloads / app reloading faster during development, various developer tools that each app store provides like play delivery, app bundles and so on.
Many times, during this app development or publishing this app, on seeing a failure, I felt like giving up. But if I had given up, I would not have been writing this blog. So to me, anyone can learn anything, but the catch is they need to be provided with the right resources. App development is not my forte, but doing this made me understand how software development in the app industry works in general. And most importantly, it requires a lot of patience, trials and errors and multiple releases to make a smooth, perfect app.
I hope the links in this blog and the references mentioned in https://github.com/saiga006/message-finder will motivate some of you to pursue app development.
As Captain Sinbad says, To those who never give up on failures easily, keen on improving themselves better and better by practicing daily rather than thinking about the end goals, to us I say “Greatness is coming”.
Cheers and Happy 2021 😄!
— Sai Mukkundan
