ToddQ

Enhancing app security with Kotlin inline functions

Tue, 07 Nov 2023 00:00:00 GMT

This is the first post about Kotlin skills, and we will discuss inline functions.

🤔 What are inline functions ?

In case you are familiar with inline functions in Kotlin, feel free to skip this chapter.

Inline functions are not exclusive to Kotlin. Simply put, when using an inline function, the compiler will directly insert the function code into the code of the calling function, rather than creating a separate function object for the parameter and making a call to it.

fun main() {
  check() { println("foo") }
}

inline fun check(action: () -> Unit) {
  println("begin")
  action()
  println("end")
}

Above is a inlined function named check, the compiler could emit the following code:

fun main() {
  println("begin")
  println("foo")
  println("end")
}

The reason for doing these is to improve performance by avoiding the creation of objects by these higher-order functions.

👍 Why can it enhance app security ?

Not inlining functions makes it easier for hackers to analyze their parameters and returns, potentially leading them to make assumptions about their purpose.

By inlining certain sensitive functions, such as a paywall function, the compiler will copy it into each code of the caller, regardless of how many times it is called. This approach offers two advantages:

It makes it more challenging for hackers to identify the paywall function.
It prevents hackers from easily editing the paywall function once to remove all paywalls.

There is no guarantee of achieving 100% security, but it is indeed possible to increase the difficulty of hacking.

🙏

Automatically mirroring images for RTL layouts

Thu, 26 Oct 2023 00:00:00 GMT

A simple but awesome trick from a Reddit comment:

Define an integer resource mirrorScale=1 in values folder, and mirrorScale=-1 in values-ldrtl folder. Then you just set android:scaleX="@integer/mirrorScale" in layout xml files.

The following section is my approach. If you want to learn more, please keep reading.

When Localizing Android for Arabic Language (RTL), you will notice that their reading direction is from right to left. Android provides built-in support for RTL layouts and text direction, which automatically mirrors text and layout elements.

However, images do not undergo automatic mirroring. Achieving image mirroring for RTL languages typically involves two approaches, both requiring additional work:

Manually Create Mirrored Images <br>Place a mirrored image with the same name in the corresponding ldrtl folder within the drawable directory. For instance, put a mirrored image with the same filename in the drawable-ldrtl-xhdpi folder.
Use android:autoMirrored Attribute <br>Do not directly use images, create a drawable resource, for example: @drawable/icon refers to an image that needs to be mirrored
```
 <?xml version="1.0" encoding="utf-8"?>
 <bitmap xmlns:android="http://schemas.android.com/apk/res/android"
     android:src="@drawable/icon"
     android:autoMirrored="true"/>
```
Then use this drawable resource instead.

Achieve by hooking

The 2nd approach mentioned above involves using the android:autoMirrored="true" attribute, which can automatically mirror drawables.

Unfortunately, this attribute cannot be directly used in layout XML files. However, we can utilize Android's layout inflater mechanism to hook into the view tree generation process and modify ImageView's src or View's background.

During the hooking process, we can use drawable.setAutoMirrored(true) to achieve the same effect.

Android provides hook interfaces for this purpose: LayoutInflater.Factory and LayoutInflater.Factory2, with the latter has one additional method. You can directly use Factory2. In Activity onCreate method, inject your custom rtlFactory like this:

val inflater = activity.layoutInflater
inflater.factory2 = rtlFactory

When generates views from XML, it triggers the onCreateView() method within rtlFactory. In this method, we have the ability to replace the generated ImageView objects with our specified custom View objects, such as RtlImageView shown below.

class RtlFactory : LayoutInflater.Factory2 {
    override fun onCreateView(
        parent: View?, name: String, context: Context, attrs: AttributeSet
    ): View? {
        if (name == "ImageView) {
            return RtlImageVIew(context, attrs)
        }
    }
}

Inside the RtlImageView, you can access the image resource defined in the XML attributes, such as android:src="@drawable/ic_logo, and enable automatic mirroring.

// RtlImageView
val drawable = AppCompatResources.getDrawable(view.context, srcResId)
drawable?.isAutoMirrored = true // Enable automatic mirroring
setImageDrawable(drawable)

Of course, you can also add a custom attribute like app:mirrorSrc="true" to RtlImageView to indicate whether automatic mirroring is required. The same principle applies to the View's background.

Use in XML layout

With the aforementioned setup, in your layout XML files, simply add the app:mirrorSrc="true" attribute to the ImageView whose image needs to be automatically mirrored.

<ImageView
    android:layout_width="26dp"
    android:layout_height="26dp"
    app:mirrorSrc="true"
    android:src="@drawable/icon" />

I have created a library contains a variety of Views for hooking all the Android native Views, including as TextView, Button, FrameLayout, and more.

A trap in Android ViewGroup customization

Fri, 20 Oct 2023 00:00:00 GMT

In this post, we won't delve into the process of customizing a ViewGroup since there are many excellent guides available for that purpose. Instead, I'll highlight a trap in a crucial function within ViewGroup that is often overlooked by many developers.

The crucial function in ViewGroup is shouldDelayChildPressedState(). Let's expoler it intended use.

The Function

public boolean shouldDelayChildPressedState() {
    return true;
}

In class ViewGroup, the default implementation return true. As it's named, the pressed state should be delayed for children or descendants of this ViewGroup. It is invoked by isInScrollingContainer() in ViewGroup.

public boolean isInScrollingContainer() {
    ViewParent p = getParent();
    while (p != null && p instanceof ViewGroup) {
      if (((ViewGroup) p).shouldDelayChildPressedState()) {
        return true;
      }
      p = p.getParent();
    }
    return false;
}

This function checks whether its parents are a scrolling container or not. It is invoked in the View's touch event logic.

public boolean onTouchEvent(MotionEvent event) {
    ...
    switch (action) {
        case MotionEvent.ACTION_DOWN:
            if (isInScrollingContainer()) { // <----
                postDelayed(mPendingCheckForTap,
                    ViewConfiguration.getTapTimeout());
            } else {
                setPressed(true, x, y);
            }
        break;
    }
    ...
}

As I mentioned before, when the view that has been touch is inside a scrolling container, it will delay the pressed feedback for a short period.

The short period refers to ViewConfiguration.getTapTimeout(), the value of which is 100ms

The Trap

Regardless of when you touch the view, it will introduce a 100ms delay to verify the pressed state.

OK, 100ms is a short duration for a single view, but it can become a significant factor when you prioritize app performance with a large number of views.

So, we do not need this 100ms delay if the ViewGroup is not scrollable, that means implementation of shouldDelayChildPressedState should return false.

The trap lies in the default implementation, which returns true, and surprisingly, there are no official guides that mention it. It's easy to overlooked this.

The implementations of ViewGroup's non-scrollable subclasses, such as FrameLayout or LinearLayout, return false.

I prefer to use these subclasses for customizing rather than using ViewGroup directly to avoid these unexpected traps.