If you're an Android developer, diving into Wear OS development is a breeze! Just like Android development, you'll find many similarities—whether it's designing UI using Compose, creating activities, managing notifications, and much more.

There are two types of wear os application one is Standalone and Non Standalone App.

1. Standalone
   These apps operate independently on your Wear OS device, requiring no constant connection or syncing with a companion app on your smartphone. They offer full functionality directly from your smartwatch:

   • Google Fit: Tracks your activity and health metrics solely on your smartwatch, syncing data with your Google account when connected to the internet.

   • Spotify: Enables you to stream music or podcasts directly from your smartwatch without needing your phone nearby. It operates over Wi-Fi or cellular data independently.

2. Non Standalone
   These apps rely on a connection with a companion app on your smartphone to fully function. They offer limited functionality or require constant syncing with your smartphone.

   • Google Maps: While you can receive directions on your smartwatch, real-time navigation updates depend on a constant connection to your smartphone.

   • WhatsApp: While you can receive and read messages on your Wear OS device, sending messages or media requires the smartphone app for full functionality and syncing.

When developing a Wear OS app using Compose for UI development, syncing data between the watch app and the Android app is crucial.

1. Data Client: The Data Client provides a streamlined approach to share data between the Wear OS app and the Android app. It enables seamless communication and synchronization of data across both platforms. With the Data Client, developers can efficiently send and receive data, ensuring consistency and real-time updates between the watch and the smartphone app.

2. Message Client: The Message Client allows bidirectional communication between the Wear OS app and the Android app through message passing. Developers can use this method to send messages containing data payloads, enabling real-time updates and interactions between the watch and the smartphone.

3. Channel Client: The Channel Client facilitates communication between the Wear OS app and the Android app through data channels. It provides a reliable and efficient way to transfer large amounts of data, such as files or images, between the two platforms. Developers can establish channels to transmit data seamlessly, enhancing the user experience across devices.

Sample code Resources for each client:
https://github.com/android/wear-os-samples/tree/main/DataLayer

If you have any questions, comments, or suggestions, please don't hesitate to reach out. Your feedback is invaluable as I continue to explore and share information on topics that matter.

Please subscribe to my blog for more Android development tips and tricks.

However, with the rising number of cyber threats targeting mobile devices, developers must take measures to protect and safeguard our apps.

In this blog, we will learn about the VAPT security guidelines for Android and protecting the Android client ecosystem.

What is VAPT?

Vulnerability Assessment and Penetration Testing (VAPT) for Android is like checking if your Android phone or tablet has any security problems and fixing them.

For better understanding let's take one example

Imagine your Android device is like a house, and VAPT is like checking if all the doors and windows are locked properly and if there are any hidden ways for bad people to get in. If we find any problems, we make sure to fix them so your device stays safe.

VAPT involves looking for things like weak spots in the software, unsafe ways your device talks to the internet, or any other issues that could make it easy for hackers to do bad things. It's all about making your Android device more secure and less vulnerable to cyber threats.

Here are the common VAPT security guidelines for Android

Root Detection

Developers need to ensure that their apps can detect this security vulnerability. Hackers often use root devices or take advantage of devices that have been rooted by the owner to gain access to sensitive user data and other secrets stored in an app's source code

Why is a rooted device potentially dangerous to users/apps?

System security and safeguards cannot be guaranteed after the root. At root, device data is at risk, including gaining access to personal information such as contact lists, emails, and other data, or collecting data like credentials and passwords. With a rooted device, a user or malicious program can elevate their permissions to root and circumvent this protection giving them access to other apps’ private data.

So it is the best way to check in your application whether the device is rooted or not to avoid data theft.

Solutions

Free:

There are several open-source solutions for checking for root, such as RootBeer, AntiMagisk, JailMonkey, and others, but the solutions are not 100% effective since third-party apps, such as Magisk, can bypass the root detection.

Because all of these solutions are client-side implementations, the attacker can bypass the root detection with the Magisk app, which hides the root files of the selected app, and there is a tool called Frida available that brute forces code, such as updating boolean conditions during runtime.

https://gist.github.com/Ashutoshwahane/b0b2eca58d21857e006401d9f58c051a

https://github.com/GantMan/jail-monkey

https://github.com/scottyab/rootbeer

https://stackoverflow.com/questions/18716808/how-to-check-usb-debugging-enabled-programmatically

Paid:

Play Integrity is a suite of tools and services that helps developers protect their apps and games from abuse and attacks. It provides a variety of signals and features that can be used to detect and prevent unauthorized access, cheating, fraud, and other malicious activity.

Developers can use Play Integrity in a variety of ways. For example, they can use the Play Integrity API to:

• Check that the app is running on a genuine Android device.

• Check that the app has not been tampered with.

It is the best way to secure the app because of server-side validation.

Official Documentation: https://developer.android.com/google/play/integrity

Code obfuscation

Code obfuscation is a security technique that makes it more difficult for attackers to reverse engineer and understand your code. This can help to protect your app from being hacked or tampered with.

There are several different ways to obfuscate code for Android apps. One popular tool is ProGuard, which is a free and open-source tool that can be used to obfuscate Java code. ProGuard can rename classes, methods, and variables, and it can also remove unused code and resources.

In Simple words, Code Obfuscation is the process of converting the actual source code to unreadable and ununderstandable code.

How to obfuscate the code in app-level build.gradle file

android {
    buildTypes {
        getByName("release") {
            // Enables code shrinking, obfuscation, and optimization for only
            // your project's release build type. Make sure to use a build
            // variant with `isDebuggable=false`.
            isMinifyEnabled = true

            // Enables resource shrinking, which is performed by the
            // Android Gradle plugin.
            isShrinkResources = true

            // Includes the default ProGuard rules files that are packaged with
            // the Android Gradle plugin. To learn more, go to the section about
            // R8 configuration files.
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
    ...
}

For more detail please refer to the official documentation: https://developer.android.com/build/shrink-code

Hardcoded Keys

Never hard code the API keys and other sensitive information that are essential for many Android apps. However, it is important to keep these keys safe, as they can be used to access your app's data or resources. One way to do this is to store the keys in a local.properties file.

The local.properties file is a hidden file that is located in the root directory of your Android project. It is not included in version control systems(It should be added in the git ignore file), so it will not be shared with others when you commit your code.

To store an API key in local.properties, simply add a line with the key name and value. For example:

API_KEY=YOUR_API_KEY

// build.gradle.kts
        val apiKey = gradleLocalProperties(rootDir).getProperty("API_KEY")
        buildConfigField("String", "API_KEY", apiKey)

Clean and Re-Build the project

//access the BuildConfig the API key field anywhere in the module and It gets generated in the compile time
val apiKey = BuildConfig.API_KEY

• Do not hard-code the key value in your code. This would make it easier for someone to steal the key.

• Keep the local.properties file secure. Do not share it with anyone who does not need to have access to it.

To make it more secure, we can fetch the keys from the backend server during runtime.

Encrypted shared preference and Local Storage

DataStore is a new and improved data storage solution aimed at replacing SharedPreferences. Built on Kotlin coroutines and Flow, DataStore provides two different implementations: Proto DataStore, which stores typed objects (backed by protocol buffers), and Preferences DataStore, which stores key-value pairs.

But there is a problem, DataStore creates a .preferences_pb file in the app’s internal storage. As of now, the data is stored in an unsecured manner. Hence, storing sensitive data with DataStore is not recommended.

This can be exposed in the debug APK easily using the Android Studio device explorer. but for signed or released APK we won't be able to see this due to Android security policy and permission.

Only root devices can expose the signed or released APK, so If we are able to achieve 100% root detection It will be resolved or else we can encryption and decryption for dataStore values.

Check out the official documentation to encrypt and decrypt the shared preference or Datastore.
https://developer.android.com/topic/security/data

If you have any questions, comments, or suggestions, please don't hesitate to reach out. Your feedback is invaluable as I continue to explore and share information on topics that matter.

Please subscribe to my blog for more Android development tips and tricks.

The possibilities of GitHub Actions are vast, including building and testing your code, deploying it to production, releasing new versions of your software, managing your infrastructure, and even sending notifications and reports. Plus, it's entirely free for public and open use.

What is CICD?

CI stands for continuous integration, which is an automated process that builds, tests, and integrates code changes. This helps teams identify and fix bugs early on, improve software quality, and release software more quickly and reliably.

CD stands for continuous deployment, which is a delivery process that automatically deploys code changes that pass automated tests to production. This means we are not required to publish the app manually on Play Store and Firebase distribution.

When used together, these processes are called CICD, and there are numerous open-source CICD tools available in the market

Let's continue with GitHub Actions!

GitHub Actions is a powerful tool that can help improve the quality and efficiency of your software development process. It is also user-friendly and easy to get started with, even if you're new to CICD.

Configure the repository with GitHub actions

• Create a GitHub repository for your Android project, if you don't already have one.

• Create a .github folder in the root directory of your repository.

• Inside the .github folder, create a workflows folder.

• Inside the workflows folder, create a new file with the .yml extension. For example, you could name it main.yml.

• In the .yml file, define your workflow steps

Bonus Tip 🤩: You can try the suggested workflow option and this will create a basic workflow to help you get started with Actions

Let's create and run the basic workflow just to understand the actions

This workflow will run on every push to the main branch of your repository. It will first check out the code, and print the Hello, world! string

You can customize the workflow steps to meet your specific needs. For example, you could add steps to sign the APK, deploy the app to a test environment, or send notifications to your team members.

Once you have created the workflow file, push it to your repository. GitHub Actions will automatically start running the workflow for you.

Checkout the official documentation to understand the workflow file and syntax

Let's automate some Android development stuff

Improve your code with lint checks

The lint tool helps find poorly structured code that can impact the reliability and efficiency of your Android apps and make your code harder to maintain. It is strongly recommended that you correct any errors that lint detects before publishing your app. Lint can help you clean up these issues.

YAML code to run the lint job

name: CI
on:
  push:
    branches: [ "dev" ]
  pull_request:
    branches: [ "dev" ]
  workflow_dispatch:
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout the code
        uses: actions/checkout@v2
      - name: Set up Java
        uses: actions/setup-java@v2
        with:
              distribution: "temurin"
              java-version: 17
      - name: Run Lint Test
        run: ./gradlew lintDebug
      - name: Upload html test report
        uses: actions/upload-artifact@v2
        with:
          name: lint.html
          path: app/build/reports/lint-results-debug.html

When we push or merge pull requests to the dev branch. GitHub actions automatically run the workflow.

Build APK and Upload to Artifacts

For immediate app testing and debugging, you can build a debug APK. The debug APK is signed with a debug key provided by the SDK tools.

To build a debug APK, using the command line ./gradlew assembleDebug task:

YAML code to build the APK and upload it to Artifacts

  name: Build APK
on:
  push:
    branches: [ "dev" ]
jobs:
  Build-APK:
    name: Running on latest ubuntu machine
    runs-on: ubuntu-latest
 steps:
      - name: Checkout the latest code
        uses: actions/checkout@v2
      - name: Set up Java
        uses: actions/setup-java@v2
        with:
          distribution: "temurin"
          java-version: 17
      - name: API_KEY
        env:
          API_KEY: ${{secrets.API_KEY}}
        run: echo API_KEY=\"$API_KEY\" > local.properties
      - name: Grant Permission to Execute
        run: chmod +x gradlew
      - name: Build debug APK
        run: bash ./gradlew assembleDebug --stacktrace
      - name: Upload APK to Github Artifacts
        uses: actions/upload-artifact@v3
        with:
          name: app
          path: presentation/build/outputs/apk/debug/presentation-debug.apk

Local Unit Test

A local test runs directly on your workstation, rather than an Android device or emulator. It uses your local Java Virtual Machine (JVM), rather than an Android device, to run tests. Local tests enable you to evaluate your app's logic more quickly

A unit test verifies the behaviour of a small section of code, the unit under test. It does so by executing that code and checking the result.

YAML code to run the local unit test case

name: Unit Test
on:
  push:
    branches: [ "dev" ]
jobs:
  Build-APK:
    name: Running on latest ubuntu machine
    runs-on: ubuntu-latest
    steps:
      - name: Checkout the latest code
        uses: actions/checkout@v2
      - name: Set up Java
        uses: actions/setup-java@v2
        with:
          distribution: "temurin"
          java-version: 17
      - name: API_KEY
        env:
          API_KEY: ${{secrets.API_KEY}}
        run: echo API_KEY=\"$API_KEY\" > local.properties
      - name: Grant Permission to Execute
        run: chmod +x gradlew
      - name: Run unit test case
        run: ./gradlew :domain:testDebugUnitTest --tests "dev.ashutoshwahane.domain.usecase.GetApodImageUseCaseTest"

Code static analysis using MobSF

mobsfscan is a static analysis tool that can find insecure code patterns in your Android and iOS source code. Supports Java, Kotlin, Swift, and Objective C Code. mobsfscan uses MobSF static analysis rules and is powered by semgrep and libsast pattern matcher.

YAML code to run code static analysis

name: Mobsfscan
on:
  push:
    branches: [ "dev" ]
  pull_request:
    branches: [ "dev" ]
jobs:
  mobsfscan:
    runs-on: ubuntu-latest
    name: mobsfscan code scanning
    steps:
      - name: Checkout the code
        uses: actions/checkout@v2
      - name: Set up Java
        uses: actions/setup-java@v2
        with:
          distribution: "temurin"
          java-version: 17
      - name: API_KEY
        env:
          API_KEY: ${{secrets.API_KEY}}
        run: echo API_KEY=\"$API_KEY\" > local.properties
      - name: mobsfscan
        uses: MobSF/mobsfscan@main
        with:
          args: '. --sarif --output results.sarif || true'
      - name: Upload mobsfscan report
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: results.sarif

For more details please check the official documentation

Get the Source Code from here!
Let me know in the comment section if you would like to know about publishing an app on the Play Store using GitHub actions ( CICD)

If you have any questions, comments, or suggestions, please don't hesitate to reach out. Your feedback is invaluable as I continue to explore and share information on topics that matter.

Please subscribe to my blog for more Android development tips and tricks.

Android build variants are a useful tool for developers who want to create multiple versions of their app from a single codebase. This can be helpful for various reasons, such as:

• Making separate app versions for different groups of users (e.g. free or paid)

• Developing different app versions for different stages (e.g. testing or final release)

One of the most common use cases for Android build variants is to build different versions of an app for different environments. For example, you can create a development version of your app with debug symbols enabled, making it easier to debug. Alternatively, you can create a production version of your app with debug symbols disabled for security reasons.

Finally, Android build variants can be utilized to test different features or configurations of the app. For instance, you can create a build variant that incorporates a new feature that is still undergoing testing and then deploy that build variant to a small group of users to receive feedback.

Different Use Cases for Android Build Flavors: A Quick Summary

• Free vs Paid

• Different language builds

• Development vs Production

• Different screen sizes and resolutions

• Different features and configurations

Enough Theory Let's start with a Practical Example (the given example is for the build.gradle.kts which is recommended by google)

1. Open the build.gradle file app level in your Android project.

2. In the buildTypes block, define two build types:release and debug.

   

3. For the release build type, set the following properties:

   • debuggable to false. This prevents you from debugging your app in Android Studio.

   • minifyEnabled to true. This means that your app will be minified, which makes it smaller and faster.

   • proguardFiles to an array of ProGuard files. These files will be used to obfuscate your app and remove unused code.

4. For the debug build type, set the following properties:

   1. debuggable to true. This allows you to debug your app in Android Studio.

   2. minifyEnabled to false. This means that your app will not be minified, which makes it easier to debug.

5. Product Flavors: Product flavors enable you to create different versions of your app for various use cases. For example, you might have flavors for "free" and "premium" versions of your app, each with unique features or branding. Each flavor can have its own resources, assets, and code.

   

• I have created 4 different types of flavor ( for the different use cases )

  1. dev: This is the development build variant, with the application ID com.ashutoshwahane.dev and the version name suffix _dev. It also defines a constant named TEST_DEV_API that stores the API key for the development environment.

  2. production: This is the production build variant, with the application ID com.ashutoshwahane.prod and the version name suffix _prod. It also defines a constant named TEST_PROD_API that stores the API key for the production environment.

  3. free: This is the free build variant, with the application ID com.ashutoshwahane.free and the version name suffix _free.

  4. paid: This is the paid build variant, with the application ID com.ashutoshwahane.paid and the version name suffix _paid.

• 

• On gradle.properties define your API key or any other config data. ( Bonus TIP: Add gradle.properties file to .gitIgnore to secure your API key )

• Once all the steps are done make sure to Re-Build your project.

• Now the keys are accessible anywhere in the app for ex:

  

The code val api = BuildConfig.API_KEY retrieves the API key for the current build variant in Kotlin. The BuildConfig class includes a static field named API_KEY that stores the API key for the current build variant. The valkeyword declares a variable called api, which is initialized to the value of the API_KEY field.

1. Now open your Build Variants on Android Studio and you will see all the different flavors in release and debug variants.

   

No more changing the config manually just select the build variants and run the app

To learn more about build variants in Android Studio, please visit the official documentation: https://developer.android.com/studio/build/build-variants

If you have any questions about build variants, please feel free to leave a comment below. I hope this blog post was helpful. Thank you for reading!

Please subscribe to my blog for more Android development tips and tricks.