DEV Community: Vignesh S

GitHub Actions for Android

Vignesh S — Wed, 26 Aug 2020 10:09:13 +0000

In this post, the "Android-InAppBilling" open source android application sample was used that leverages GitHub Actions CI.

The Workflow:

The "Android-InAppBilling" open source android app sample is based on Gradle build system. So, the workflow will run "gradlew" script on its machine to build the app.

To accomplish this, created a new "build.yml" GitHub Actions Workflow file on:

root_repo/.github/workflows/build.yml

In the "build.yml", the name of workflow is given as

name: build

You can define your own workflow name, and you can create multiple workflows on the same project.

The project has to build the code base on:

1) whenever there is a change pushed to repository

2) whenever there is a new Pull Request created for the repository

To accomplish this, added the below changes on the workflow file:

on:
  push:
    branches: [ main ] 
  pull_request:
    branches: [ main ]

After this, we have created a job where all of the work will be running on ubuntu.

jobs:
  build:
    runs-on: ubuntu-latest

This workflow uses predefined actions that will checkout to the main branch and uses JDK 1.8

steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8

Then, we have granted executable permission for the "gradlew" script as "run" command to make a build as follows:

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew

After this, we first try to check the code base with lint tool:

    - name: Check Lint
      run: sudo ./gradlew lintDebug

We used "sudo" here, just wanted to install missing Android SDK and the Build Tools.

If it was successful, then we try to run tests...

    - name: Run tests
      run: sudo ./gradlew test

If all the test cases passed, then we try to build the app by:

    - name: Build with Gradle
      run: sudo ./gradlew build

The complete workflow file and the repository link included here with this post as below...

Yaml File:

Link to Code:

LiteKite / Android-InAppBilling

A sample which uses Google's Play Billing Library and it does InApp Purchases and Subscriptions.

Android-InAppBilling

A sample which uses Google's Play Billing Library and it does InApp Purchases and Subscriptions.

Getting Started

Add Play Billing Library dependency in your Android Studio Project.
Use the Application ID that's been used in your Google Play Developer Console.

Make In-app purchases by starting BillingClient connection, make querying purchases locally or from Google Play Store Cache from BillingClient
In-app product or "Managed Products" can be bought multiple times by consuming purchase before requesting another purchase.
Subscription based products cannot be consumed, It'll be based on some time periods that you choose and will expire after the time ends. These are all handled by Google Play Remote Server.
Add Tester Accounts in Google Play Developer Console -> App Releases for making test purchases and upload the initial version of your project APK including Google Play Billing Library dependency.

Libraries Used

Play Billing Library -> for making Google Play In-app…

View on GitHub

Submission Category:

Phone Friendly

Android-Proguard

Vignesh S — Mon, 10 Aug 2020 15:53:53 +0000

Proguard on android obfuscates code into some random letters and it makes hard to reverse engineer the code from the published apk.

Enabling proguard on a gradle build system is super easy as follows:

build.gradle (App):

android {
    ...
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
    }
    ...
}

Additionaly, enabling shrinkResources will remove the unused code and it drastically reduces the size of the generated apk.

After publishing your apk with proguard enabled and if your app crashes, throws exceptions or does not work properly, you will definitely get logs from third party crash analytics tool or you will try to get the logs directly by reproducing the steps.

With proguard enabled, your stack trace or logs could look like the below one:

06-25 22:19:34.407 14270 14311 E AndroidRuntime: Process: com.litekite.example, PID: 14270
06-25 22:19:34.407 14270 14311 E AndroidRuntime: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:8372)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1444)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.view.View.requestLayout(View.java:25010)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.view.View.requestLayout(View.java:25010)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at androidx.constraintlayout.widget.ConstraintLayout.requestLayout(Unknown Source:0)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.view.View.requestLayout(View.java:25010)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.view.View.requestLayout(View.java:25010)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.widget.ImageView.setImageDrawable(ImageView.java:597)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at androidx.appcompat.widget.AppCompatImageView.setImageDrawable(Unknown Source:0)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at d.b.p.m.c(Unknown Source:26)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at androidx.appcompat.widget.AppCompatImageView.setImageResource(Unknown Source:4)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at com.litekite.example.ui.u(Unknown Source:9)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at e.c.a.f.a.d.b(:4)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at e.c.a.h.a.a(:10)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at e.c.a.h.a$c.onCapabilitiesChanged(:3)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.net.ConnectivityManager$NetworkCallback.onAvailable(ConnectivityManager.java:3261)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at e.c.a.h.a$c.onAvailable(Unknown Source:0)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.net.ConnectivityManager$CallbackHandler.handleMessage(ConnectivityManager.java:3474)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:107)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:214)
06-25 22:19:34.407 14270 14311 E AndroidRuntime:        at android.os.HandlerThread.run(HandlerThread.java:67)

From the above stack trace, it is quite hard to find out the cause of the exception, because the code were obfuscated into some magical letters.

To solve this problem, you really need to deobfuscate the stack trace to find out the cause.

For this deobfuscation, download the Retrace Script which is packaged with Proguard

Download retrace.sh from Guardsquare:

https://www.guardsquare.com/en/products/proguard/manual/retrace

To deobfuscate the stack trace, you need to have two files as an input for this tool to generate the original stack trace.

1) Mapping.txt file - has all the letter mappings of the obfuscated code.

You can get this mapping file from your app build directory:

root_directory/SampleApp/app/build/outputs/mapping/<build-type>/

You can also upload your mapping.txt to Google Play Store or some online crash analytics platform like Firebase that produces deobfuscated stack trace that can be downloaded for quick analysis.

2) Stacktrace.txt file - the obfuscated stack trace.

The last step that is required to get the original stack trace is to run the retrace.sh tool script.

$ retrace.sh -verbose mapping.txt stacktrace.txt > original_stacktrace.txt

The original_stacktrace.txt file would look like this:

2020-06-25 20:11:49.091 5838-5867/com.litekite.example E/AndroidRuntime: FATAL EXCEPTION: ConnectivityThread
    Process: com.litekite.example, PID: 5838
    java.lang.IllegalArgumentException: No enum constant e.c.a.h.a.b.4
        at java.lang.Enum.valueOf(Enum.java:257)
        at com.litekite.example.wifi.WifiController$WifiLevel.valueOf(Unknown Source:2)
        at com.litekite.example.wifi.WifiController.updateWifiState(:4)
        at com.litekite.example.wifi.WifiController$networkCallback$1.com.litekite.example.wifi.WifiController.access$updateWifiState(:3)
                                                                       onCapabilitiesChanged
        at android.net.ConnectivityManager$NetworkCallback.onAvailable(ConnectivityManager.java:3261)
        at com.litekite.example.wifi.WifiController$networkCallback$1.com.litekite.example.wifi.WifiController.access$setSsid$p(Unknown Source:0)
                                                                       onAvailable
                                                                       onAvailable
                                                                       com.litekite.example.wifi.WifiController.access$updateWifiState
                                                                       onAvailable
        at android.net.ConnectivityManager$CallbackHandler.handleMessage(ConnectivityManager.java:3474)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.os.HandlerThread.run(HandlerThread.java:67)

Restoring a stack trace with line numbers will require the below extra options:

-renamesourcefileattribute SourceFile
-keepattributes SourceFile,LineNumberTable