Forem: Lejdi

Handling Android toolbars in Android 15+

Lejdi — Sat, 22 Feb 2025 07:41:49 +0000

In this article I'll present how to handle activities with toolbars on Android 15 and later. I'll cover three scenarios: activity with system toolbar, activity with custom toolbar and compose layout.

Since Android 15, the previously optional possibility to enable Edge2Edge became mandatory, and now it's the default behavior of Android activities. However some people not have time or budget in their project to rewrite all screens to match this requirement. I'll present you three simple workarounds.

Add flag in activity's style

The simplest solution is adding following flag to the style of your activity:
<item name="android:windowOptOutEdgeToEdgeEnforcement">true</item>
This solution must be considered as a temporary one, because as Google recently announced, it won't work on Android 16 and later. I recommend using it only as a quick fix and work on other long term solution.

General mechanism for old-school activities with XML layouts

Google provided other way of handling edge to edge enforcement.

ViewCompat.setOnApplyWindowInsetsListener(view) { v, windowInsets ->
  val insets = windowInsets.getInsets(WindowInsetsCompat.Type.systemBars())
  v.updateLayoutParams<MarginLayoutParams> {
      leftMargin = insets.left
      bottomMargin = insets.bottom
      rightMargin = insets.right
  }
  WindowInsetsCompat.CONSUMED
}

Above code with description is available here.
This listener is designed to add margins for specific views (like floating action button) so they are not overlapped by system bars.
We can reuse it to handle margins for the entire activity.
Let's write some extension function:

fun Activity.addMarginsForEdgeToEdge() {
    val view = this.window.decorView.findViewById<View>(android.R.id.content)
    ViewCompat.setOnApplyWindowInsetsListener(view) { v, windowInsets ->
        val insets = windowInsets.getInsets(
            WindowInsetsCompat.Type.systemBars()
        )
        v.updateLayoutParams<ViewGroup.MarginLayoutParams> {
            leftMargin = insets.left
            bottomMargin = insets.bottom
            rightMargin = insets.right
            topMargin = insets.top
        }
        WindowInsetsCompat.CONSUMED
    }
}

We have used the same funcion, but as a view we have provided activity's decorView.
For activities with system's default toolbar you can simply use this function in onCreate() of your activity.

Handling custom toolbar

If your activity have some custom toolbar written specifically for your application, the code has to be a little bit more complicated. Since a toolbar is a part of your layout it is not considered as part of system bars. If you simply add margins as presented above, the blank, semi-transparent space will be left above activity with clock, battery etc. It would definitely look better if this space remains the same color as your toolbar. To achieve this let's modify the solution:

fun Activity.addMarginsForEdgeToEdge(
    getToolbar: () -> View?,
) {
    var toolbarHeight: Int? = null
    val view = this.window.decorView.findViewById<View>(android.R.id.content)
    ViewCompat.setOnApplyWindowInsetsListener(view) { v, windowInsets ->
        val insets = windowInsets.getInsets(
            WindowInsetsCompat.Type.systemBars()
        )
        val toolbarView = getToolbar()
        if(toolbarView != null) {
            val layoutParams = toolbarView.layoutParams
            if(toolbarHeight == null)
                toolbarHeight = layoutParams.height
            layoutParams.height = toolbarHeight?.plus(insets.top) ?: insets.top
            toolbarView.layoutParams = layoutParams
            toolbarView.updatePadding(
                top = insets.top
            )
        }
        else {
            v.updateLayoutParams<ViewGroup.MarginLayoutParams> {
                topMargin = insets.top
            }
        }
        v.updateLayoutParams<ViewGroup.MarginLayoutParams> {
            leftMargin = insets.left
            bottomMargin = insets.bottom
            rightMargin = insets.right
        }
        WindowInsetsCompat.CONSUMED
    }
}

Our function now can get your custom toolbar's view as a parameter. If you won't provide it, the behavior won't change and the code will handle system toolbar.
If the toolbar provided is not-null, then we are not setting the top insets of activity. Instead we preserve the toolbar's height, and then we increase it by the top insets (which is now height of this semi transparent bar above our toolbar). Additionally we update top padding to make the toolbar's content centered as before.

Handling toolbars in compose

The workaround for compose is the simplest. We simply need to wrap our compose view in some function like that:

protected fun setContent(content: @Composable () -> Unit) {
  Column(
    modifier = Modifier.windowInsetsPadding(WindowInsets.systemBars)
  ) {
      content()
    }
}

And that's all. Enjoy!

Android - Configure Retrofit to use certificate and server's private key

Lejdi — Sun, 29 Aug 2021 10:10:36 +0000

Quick intro to certificates and keys

When developing mobile apps, it is very likely that you communicate with some backend server to send and receive data. If you just send it in clear text, anyone could intercept your traffic and read the data. Obvious solution to this problem is encryption. The most common solution is encrypting HTTP traffic using the TLS (HTTPS).

TLS is using type of cryptography called asymmetric cryptography, which utilizes public certificates and private keys.

Public certificate contains some well-known information, like public key, it's validity and information about authority that issue your certificate.

Public and private key have this characteristic, that if you encrypt data using one of the keys, it can be only decrypted using the other one. Encryption in Android takes advantage of this property. Android device is encrypting the data using server's public key, and then the server can decode it using it's private key.

To make sure your app exchanges data with the correct server, it's certificate must be issued by one of the Certificate Authorities (CA). In the context of Android, there is a list of trusted CA's, so the certificates issued by any CA included in the list can be trusted by the system.

Scenario

There might happen a case where server's security configuration requires you to communicate using public certificate generated specifically for your app, which is not issued by any CA.

Solution

In the solution I'm using HTTP client called Retrofit in version 2.9.0.

In order to succesfully establish connection in such scenario you need the public certificate and server's private key. They can be placed for example in project resources' raw folder in .crt and .pem files. I do not recommend it however because they can be easily obtained using reverse engineering of our app source code. The best practice is generating such secrets at a runtime.

In order to configure your Retrofit client correctly, you have to add one additional dependency:
com.squareup.okhttp3:okhttp-tls:$version
In my case the version is 5.0.0-alpha.2

Now let's add the code that encrypts our retrofit's communication using custom public certificate.
The first thing you need to represent public certificate as InputStream. In case you store it in resources, you can simply write

val pubCertInputStream = context.resources.openRawResource(R.raw.pub_cert)

Then you need to represent the private key itself (without the "BEGIN/END RSA PRIVATE KEY" stuff) as a string.

Then you use the private key string to build PrivateKey object:

private fun loadPrivateKey(): PrivateKey? {
    val encoded: ByteArray = Base64.decode(privateKeyString, Base64.DEFAULT)
    val keySpec = PKCS8EncodedKeySpec(encoded)
    val kf = KeyFactory.getInstance("RSA")
    return kf.generatePrivate(keySpec)
}

Now you have to build OkHttpClient object:

    val cf: CertificateFactory = CertificateFactory.getInstance("X.509")
    val x509Certificate: X509Certificate = cf.generateCertificate(pubCertInputStream) as X509Certificate //1

    val keyPair = KeyPair(x509Certificate.publicKey, loadPrivateKey()) //2

    val handshakeCertificates: HandshakeCertificates = HandshakeCertificates.Builder()
        .addPlatformTrustedCertificates()
        .heldCertificate(HeldCertificate(keyPair, x509Certificate))
        .build() //3

    val client = OkHttpClient
        .Builder()
        .sslSocketFactory(handshakeCertificates.sslSocketFactory(), handshakeCertificates.trustManager)
        .build() //4

Explanation:
1- create CertificateFactory in order to generate X509Certificate object based on InputStream
2- create KeyPair containing both private and public keys
3- build HandshakeCertificates object, which contains all CA's trusted by Android system and your keypair
4- build OkHttpClient with your custom sslSocketFactory and trustManager

Finally you can build your retrofit object with your custom client included:

val retrofit: Retrofit = retrofit.client(client).build()

And that's it, now you can communicate with backend server using retrofit, and it's own certificate.