My Cryptography course professor used to say: “Nothing is 100% secure. Even if you go to the farthest place to hide the key for a safe, there is still a small percentage of probability that somebody will find it”.

Making something more secure actually means making sure that percentage is as low as possible.

The secret in Android projects can be an API key, Keystore, credentials for publishing, credentials for some special access to the 3rd party SDK, etc. If we want to secure a secret in an Android project, we usually ignore it in Git. When somebody new jumps into the project, those ignored files should be added manually.

Usually, secrets, like credentials, are inside the build.gradle file because they are environment-specific. For simplicity, let’s say that we have an environment called preproduction in which we have credentials to log in automatically into the application tapping on the login button multiple times.

This environment acts the same as production plus this log in automatically feature. This is good to have for fast internal testing in the production environment before production release. However, this secret should never be visible in the final production apk. For simplicity, let’s say that we have CREDENTIALS that we use only in the preproduction environment.

We can add it to the build.gradle file:

When we build the project, the credentials strings are located in gradleResValues.xml and we can access them using @string/ in XML files or getString function in Kotlin/Java classes as we do for any other string from resources.

Thebuild.gradle file should not be ignored in the version-control system cause all developers in the team should have the same version. With the current implementation, ‘CREDENTIALS_USERNAME’ and ‘CREDENTIALS_PASSWORD’ as part of the build.gradle file, will be included in git. This is not safe.

We want to make it more secure, so if somebody gets access to the repository that person should not get access to our production credentials.

To avoid that, we can store this key in the local.properties file:

The local.properties file should not be included in the version-control system.

To make keys from local.properties accessible in build.gradle we can add the following function:

Next, we should create a build config field this way:

At Infinum, we switched from CircleCI to Bitrise, so in this blog post, I’ll show you how to do this on Bitrise, but it’s similar to any other CI.

We should copy the key from our local.properties file and add it inside Bitrise Secret ( Project -> Workflow -> Secrets -> Add New). Let’s name it CREDENTIALS_USERNAME.

Next, we should change build config field:

If we run the build on CI, it will get CREDENTIALS_USERNAME from Secrets, if we run it locally it will get API_KEY from local.properties file.

If we want to separate API keys from other properties in the local.properties file, we can create a new credentials.properties file. Moreover, instead of storing key by key in Bitrise Secrets, we can store the whole content of thecredentials.properties file in one Bitrise secret called CREDENTIALS_PROPERTIES.

Then, we can make a special workflow step that will create credentials.properties file and fill it with data stored in Bitrise Secret. That step should be called before any other step.

A script could be made as follows:

In that case, we should have only the following, without fetching the key from the system envs.

You can choose one of the two approaches depending on what works for you.

Adding secrets to the CI is a one-time thing. You add them and you won’t change them ever, but what if you need to share them with your colleagues? It’s possible to use a password manager, but when someone joins the project, they have to add a new file and copy-paste the credentials. If you have a lot of them, this can be tedious.

A better way to share secrets is by using Vault. This tool enables you to have secrets for all your projects in one place. It has a command-line tool, so you can integrate it with your continuous integration script. That way, you do not expose secrets on your CI as they will be fetched only when you need them.

Any colleague who joins the project can have access to the Vault and will be able to fetch all or only one secret.

There are other tools that you can use instead of Vault, but the idea is the same. You have one tool which will help you share those secrets with your team.

If someone wants to, they can still do reverse engineering of the apk file and find keys, so it is really important what you have in a final production apk. If somebody gets access to the repository, credentials that are not included in the final production apk but are used during the development should not be exposed to that person.

Also, it is really important that those apks for preproduction environment will be stored in some internal host.

This was just one example of how we make Android projects more secure. In the end, everything is vulnerable, but we should try to make it harder for the bad guys. By introducing more layers of security, we reduce the vulnerability.

Have you ever supported multiple themes in your application? You made a new theme, added new colors, made a new build and everything looked shiny – except your custom view? Learn how to prepare a custom view that won’t fall apart.

Your custom view should support theming, so that it does not break the theme once you change it. Let’s go over a simple example.

Let’s say you want to make a custom view that will have an icon, title, and a description. Here’s how to create a layout for that custom view:

The next step is to create a class for that custom view:

You shouldn’t set drawable for ImageView nor the text size, line height, and the color for your TextViews directly in the layout of the custom view.

Let’s make the custom view styleable, so that different themes can have different style values. To do that, add the following code in attrs.xml file:

Now, add image and imageTintColor attributes, which will be used to set image drawable and tint color:

You can use those attributes when adding AwesomeCustomView in fragment or activity layout. For example, if you want to add it in fragment_example.xml:

To support those attributes, you should get values for those attributes in AwesomeCustomView class. You can do that from attrs, using obtainStyledAttributes() function:

Once you’re finished with typedArray, you will need to recycle it.

To set tint, do the following:

Unless you specify tint color, it will fall back to white color.
You can do a similar thing for awesomeImage.

Should you set the awesomeImageTintColor and awesomeImage attributes wherever you use AwesomeCustomView with the desired tint color? No.

There is a better way to handle it. In the styles.xml, let’s make a new style :

For example, instead of having android:awesomeImageTintColor you should just have awesomeImageTintColor.

Apply it in activity_acv_example.xml:

At this point, you should only use one line in all the places where you want this style for your view.
If you want to have a different style, you can do it with ease:

To use this in layout, just change one line:

How did you end up with the name Widget.AppTheme.AwesomeCustomView?

Let’s break it down to parts:

Instead of having lines of code for each custom attribute, now you can just use the style attribute.

You should do a similar thing for our TextViews. Instead of making attributes for text size, text line height, text color, font, and other characteristics for each TextView, you should make a custom textAppearance attr.

What is the textAppearance attr? It is the same as style attribute but for the text. Instead of supporting all the attributes, as style does, textAppearance supports only some attributes, like textColor,textSize, typeface, fontFamily etc. However, it does not support ellipsize or background for example.

In the attr.xml file, you should add the new attribute:

To support it, you will need to make the following changes in the AwesomeCustomView class:

If you don’t specify text appearance, it will fallback to AppCompat’s Title TextAppearance.

Now, you can get down to adding the special TextAppearance style for the title in the styles.xml file.

Let’s call that style Header :

Let’s explain the naming for TextAppearance.AppTheme.Header :

You’ll do a similar code for description.
To use them in the Widget.AppTheme.AwesomeCustomView style, add the following:

Let’s say you want to use the same style for your AwesomeCustomView everywhere where the base AppTheme is used. In that case, you should declare AppTheme styleable and add a special attribute in attrs.xml:

Next, you should set value for awesomeCustomViewStyle in your AppTheme :

Now, you should end up with different parameters for obtainStyledAttributes function:

During the initialization of the AwesomeCustomView , Android will get the style of your view from R.attr.awesomeCustomViewStyle. If you use another theme, in which there is no set value for awesomeCustomViewStyle attribute, it will fall back to R.style.Widget_AppTheme_AwesomeCustomView.

That means you don’t have to use this line anymore:

Having done all that, you should now support themes for your custom view. If you want to use it in another theme, you can easily do it:

Once you have a default custom view style per theme, it is really easy to support dark theme for your custom view. Your AppTheme should extend Theme.AppCompat.DayNight in res/values/themes.xml :

And in res/values-night/themes.xml, just define the dark resources:

To conclude, if you want to avoid problems with custom views when you theme your app, your custom views should support custom style attributes for each child view style, and custom textAppearance attributes for each child TextView.

Furthermore, it should have defined styles for each different usage in each theme, as well as a default style for each theme.