Android being a client-side platform, developers deal with many different APIs on a daily basis. Some of these APIs are great, some of them not really, but we can work with anything that a backend sends us.

A while ago, we had an atypical request from our backend developers. They asked us to unescape every string in the app.

This meant that the strings from the backend would contain special characters which we needed to replace. For example, & sign would be &, apostrophe would be ' and so on. It was atypical because it’s not often that developers handle such a case in mobile apps. We make an API call and show the string which came from the backend as is.

Although strange at first, the backend guys had a good reason for this. They were developing a platform which can be used by anyone, not only the Android application.

Other frontend clients could add items to the platform and they didn’t have control over how they would do it. In order to minimize cross-site scripting (XSS) vulnerability, they sanitized strings saved to the backend and they wanted to be sure they don’t send back anything exploitable.

Another reason why you would want to do this is to save the formatting of a string backend sends. If you want to show a multiline string, then you would format the string so it’s shown as expected.

If your backend escapes every string it returns, you need a method to unescape them all in one place. In Android, if you use Moshi, you can do it by defining an application-wide serializer for the String class.

Then add the serializer when defining Moshi.

If you initialize Moshi in one place and use the same instance across the app all your strings will be unescaped and your work is done.

Sometimes, you might need to unescape special characters only for certain strings in the app. If this is your case, you can do this by defining an annotation which will be used only on those strings.

Then, create a serializer and annotate the fromJson method and toJson parameter.

After defining the annotation and serializer you can annotate any escaped string in your models.

Unless you load strings in a WebView, you probably don’t have a problem with XSS in your Android app.

In most cases, mobile apps get a string from an API and show it in a TextView. However, if you really need to escape strings, it’s good to know you can use one of these two approaches.

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.

Keeping all your users updated with your latest features can be tricky business.

At the moment, Google Play’s updates can be unreliable as they depend on the users to update the app independently most of the time. However, recent updates, like Google’s in-app updates, are planning to change that.

This article will explore the benefits and drawbacks of in-app updates and how we are tackling mentioned issues using one of our open-source libraries for handling updates, Prince of Versions.

In an effort to change the current way of handling things, Google revealed a brand new way of handling updates at its I/O event last year. This concept was innovatively named Google’s in-app updates and brought us a lot of requested changes.

So, what are the new changes?

Firstly, as the name suggests, updates are now more interactive. Users will be notified in the application about an available update on the Google Play store (hence the name).

Furthermore, there is now one crucial distinction between updates. An update can be classified as flexible or as immediate, depending on various factors determined by developers or the Google Play store. The major difference between these two is the way the update is going to be handled.

On the one hand, the flexible update, recognizable by its specific UI, allows the user to keep using the application while the update is downloading in the background. Because of this, the flexible update is usually used for smaller updates, like adding a neat feature or some other non-essential bugfix.

In contrast, the immediate update is primarily used for essential app updates. Without these updates, applications probably won’t work the way they are supposed to for some or all users. Because of this, UI on immediate updates will be blocking, meaning that users won’t be able to continue using the application while the update is being downloaded and installed.

All in all, it is noticeable that this update from Google brought us some highly desirable changes that will make the entire updating process easier and more fluid for the user. Also, with Google providing its UI and handling the update, the updating process will be easier for developers, too.

Following that compellingly positive introduction, it’s time to show how to use Google’s in-app updates and what are its disadvantages.

For starters, using this new update mechanism requires the Play Core library. Furthermore, this library requires API level 21 or higher, so devices below that limit won’t be able to use it. The Play Core library offers all the mentioned benefits, meaning that after adding this library as a dependency, you are ready to go!

We must begin by demonstrating how you are going to check if there is an update on the Google Play Store. The code for doing that is simple and it looks like so:

The process begins by creating an instance of AppUpdateManager. This instance will be in charge of handling all of the update information and the flow. Within that instance, there is a method to get AppUpdateInfo task that will supply us with all the necessary information about the update state. One of the typical usages of AppUpdateInfo is checking update availability and whether that kind of update is allowed.

Now is the time to discuss the first and only shortcoming we have identified using this new library.

Essentially, at the moment of writing this, the Google Play Store offers limited means of action by which we could manually set what kind of update we are looking for. In other words, Google’s API is currently not entirely user-friendly, as it doesn’t allow publishers to easily specify update type per application version in the release track. This system could result in a possibly painful adjustment because, for the time being, Google doesn’t offer a better way of handling this matter.

After checking, depending on update availability, we can continue with the invocation of the update. To invoke the update flow, we use the following code:

As we can see from the code snippet above, the AppUpdateManager invokes the update flow. To invoke it, we need to pass a couple of parameters.

Firstly, we are passing appUpdateInfo, which is Google’s object that we got from the update check itself. Moreover, we are sending some application-related parameters like the current activity and the request code to monitor the update process later. Lastly, there is AppUpdateType.

With this parameter, we are ultimately deciding on what kind of update we will invoke on users’ phones. That means that just by knowing what kind of an update we have on Google Play Store, we can “ask” Google for it through this parameter.

Currently, Google only allows for priority change per release, whereas naturally, developers would welcome the ability to change priority per version. For this inconvenience, we can use this mentioned parameter to our advantage.

Our solution was to find a way of knowing what kind of update we are putting on the Google Play Store. If we know what kind of update we are putting there, we can “ask” Google for it.

In other words, we will know exactly what update is there on Google Play Store, and by knowing it, we are going to invoke that kind of update through the AppUpdateManager instance.

Now how exactly are we going to do that? With Prince of Versions.

Prince of Versions is an open-source library for practical and easy update handling. It was created a few years ago, with the desire for an improved way to classify updates.

As mentioned, Google’s past way of handling updates was not satisfying because it relied too much on the user. As a partial solution to this, Google presented its new in-app way of handling updates. Nevertheless, as we saw, it still has a few significant issues.

In our pursuit of an ideal combination of Google’s fancy UI and Prince of Versions’ reliable update handling, we have decided to merge these two into the latest Prince of Versions sibling: Queen of Versions.

So, how will Queen of Versions solve Google’s issues?

Firstly, we need to understand how the Prince of Versions operates. It works by fetching the JSON file and then parsing it to retrieve all the necessary details about the current update. The details comprise of information like the latest application version, minimum required version, and any additional data that we would need.

Example of the JSON file:

Afterward, Prince starts the update classification process. It begins by making several comparisons between extracted JSON values, and it finishes with one of three classification outcomes – required (immediate), new (flexible), or no update. The code for starting that process is nicely explained here.

There, we can notice a similarity with new Google’s in-app updates. Their main feature is the latest update classification. However, this is also Google’s most significant shortcoming. To reiterate, Google currently doesn’t offer an easy way of specifying update type per application version in the release track.

To begin with, we have to push our latest update on Google Play. In the meantime, all the update information should be accessible through the JSON file somewhere on the internet. This step usually consists of just writing some new numbers in the JSON and uploading it somewhere on the internet ( e.g. your server/API/any public domain ). This last step ends our job outside of the application.

Inside the application, we begin by utilizing Prince’s ability to acquire update information from a JSON file. Thus, with Prince’s help, we have all the essential information about an update which is also on the Google Play Store at that same moment.

In other words, we know precisely whether the update is required or optional. With that knowledge, we can “ask” Google for precisely what we want. Finally, we proceed by requesting the desired type of update with Google’s Play Core API.

In a nutshell, that is it – we have successfully bypassed Google’s complicated API and created a simplistic way of specifying the right kind of an update.

Naturally, there is a lot more to this story. We have created a rich library with a user-friendly API that offers a bundle of update handling customization and runs on top of this latest Google’s in-app update.

Overall, Google’s in-app updates are the right step toward the desired way of handling updates on Android. Certainly, there is still a lot of room for improvement, as there are some drawbacks to the current practice of handling things.

If you favor the simplistic update handling and want to try something different, feel free to try out our Queen of Versions and let us know your feedback. Whether you love it or if there is something else you would like to see in our next update, please let us know.

In today’s mobile ecosystem it’s easy to publish an updated version of your application. Making sure users download it is more difficult. Google and Apple provide notifications via their app stores, but more often than not, users tend to ignore them.

You can argue that it’s the users’ loss if they’re not interested in new features, but what if the new version fixes an important security issue? You need to make sure every user downloads the update. This can be accomplished within the application by disabling usage if it is not updated.

But how will the application know when a new update is available? Easily, with some help from our new open-source library.

An Android and iOS open-source library dubbed Prince of Versions standardizes notifications about application updates. The library does all the hard work: connecting to the server, parsing the configuration file, and comparing the new version with the current one. It doesn’t contain any UI, so developers can choose what to show when an update is available.

To use the library, you need to host a JSON configuration file on a server. The minimum and the current version of the application are defined in that file. When you publish a new update on Google Play, change one or both versions, and the next time the user opens your application, the library will serve a notification informing him about the new update. It is up to you to decide how the update will be shown. You can show a dialog with a button which takes the user to the app store, open a new screen, or perform some other action.

The library has three basic features:

This library is built by developers for developers, so the implementation is straightforward.

The version in your application and in the JSON file has to follow Semantic Versioning. If you are using a built-in JSON parser your configuration file has to look like this:

Android

iOS

run pod install

Android

We have been using the library in production for a while and it made implementing application updates a breeze.

We all know that testing is a vital part of your development process. With the library, you can load a configuration file from the application resources. By doing this, you can test your UI implementation without making an API call.

Everybody hates constraints, so if you don’t like our JSON configuration file, you can define your own and implement a custom parser.

At the moment, these features are only available in the Android library, but they are on the roadmap for iOS and will be available soon.

If you want to contribute or have any questions about the library visit our Android or iOS repositories on GitHub.

For years, Android developers have been struggling with the Android emulator. The emulator was so bad that it was almost impossible to use it. It took ages to start, and even when (or if) it started, it would crash a lot and applications would load forever. That’s why, 2 years ago we switched to Genymontion which is both fast and reliable. We wrote a blog post about it, so if you want you can read it here.

However, Genymotion has a big problem – the lack of support for Google applications. There is no straightforward way to add them to the emulator and you have to do it for every emulator you create.

Luckily, Google listens to developers. As it turns out, their engineers had been working on a brand new Android emulator, that was released to the public a few days ago. I took it for a spin and here’s what it offers:

When you start the emulator, it loads in less than 10 seconds. The first time I started it, I thought I did something wrong. But I didn’t, it actually loads that fast. If you’ve tried out the old Android emulator, then you know that launching it used to take at least several minutes.

The first thing you’ll notice is the new side toolbar which has some default controls. If you click on the three dots, an extended controls window with new features will open.

With the new emulator, you can easily fake users’ movement by importing GPX or KML file. This is a great and easy way to test location-based applications.

Testing different cellular network types has been a real pain until now. Now you can choose between several network types and set the status of voice and data service. If you’ve always wanted to test your application in roaming, on EDGE data connection, now you can do it from the comfort of your chair instead of going to another country.

You probably noticed that the only way so set the battery level on the old emulator was through the command line. Now you can set several options like charge level, charger connection, battery status, and even battery health. And if you are wondering, like I was, what would happen if you disabled charging and set battery level to 0%, I have an answer for you. The phone shuts down and the emulator closes. Mystery solved.

Testing how your app behaves when the user receives a phone call or text is now a lot easier. With new “Phone” options, you can send texts or fake a call from the emulator.

Until now, there has been no way to test fingerprint authentication without a real device. The latest Android emulator allows you to test your app with up to 10 different fingerprints.

The new emulator is available only in Android Studio 2.0 Preview 3b and it won’t work as fast as I mentioned if you emulate an ARM processor. You need to emulate an x86 processor if you want to enjoy the awesome performance.

AS 2.0 Preview 3b can be downloaded from the Canary Channel. The Canary Channel delivers bleeding edge updates for Android Studio on an almost weekly basis. In other words, this is far from a stable version and bugs are expected. After downloading, you will have to open the SDK Manager and install two things:

Just one important note: if you are using Mac and you already have Intel x86 Emulator Accelerator installed, you might get an error like this when starting the emulator:

emulator: ERROR: x86 emulation currently requires hardware acceleration!
Please ensure Intel HAXM is properly installed and usable.

To fix this, you have to manually reinstall the x86 Accelerator. You can do this by navigating to this folder:

”path_to_your_sdk/extras/intel/Hardware_Accelerated_Execution_Manager”

Open the IntelHAXM_6.0.1.dmg file and reinstall the x86 Accelerator.

After that, you just have to create a new x86 virtual device, press the Run button, sit back and your new emulator will be ready in a few seconds.

The new emulator is packed with new features and it works really fast, so the question is, do you still need Genymotion? The answer is yes, at least for a few more months. The new Android emulator is still in beta and there are some bugs which will drive you crazy. For example, sometimes setting the user’s location doesn’t work and faking a call freezes the emulator. Also, when the emulator freezes, you have to force close it because pressing the Quit button doesn’t work.

Despite those bugs, the new emulator shows great promise. It’s cool and usable, so I encourage you to try it out.

This July, at its annual developer conference, Google introduced the full Android Wear SDK and now developers can finally start building awesome smartwatch applications. Want to learn how to make your existing apps work with Android Wear? Then read on!

Unless you’ve spent the last year on a deserted island, you’ve probably heard about Android Wear. It’s an extension of the Android operating system for wearable devices. Although there should be many different wearable devices in the future, the industry is focused on smartwatches at the moment.

Several big players have already launched their devices that support the Wear SDK – for example LG with its G watch or Samsung with Gear 2. Probably the most anticipated smartwatch, the one we use in visual illustrations for this article, is Moto 360 by Motorola Mobility. Luckily for all of us geeks out there, it should be launched in a few weeks.

If you are a developer, Android Wear gives you a chance to improve mobile experience and make your applications more accessible for users. If you want, you can develop Android Wear applications in the same way you develop smartphone applications, but SDK also allows you to extend your current applications. In this blog post, I will show you how to extend your application notifications to Android Wear and add some cool wear actions.

I’ll be modifying one of our existing apps called the Queueing app.

This app was developed for Erste & Steiermärkische Bank and it allows anyone with a smartphone to find the nearest branch office and remotely reserve a spot in the queue. The Queueing app can send a notification when users are next in line so they can head to the bank and grab their spot. If users change their mind, they have an option to delete their ticket and leave the queue. In order to use these features, they need to take out their mobile phones and open the app.

With Android wear, we can give our users the ability to use these features without reaching for their phones. We are going to modify the existing application and users with a smartwatch will get a notification on their wrists with information on how many people are in front of them.

Notifications are a cool addition, but we can do better. We will also add two more custom wear actions:

The main idea behind these actions is to give our users the ability to interact with our application without the need to pull their smartphones out of their pockets. Just bear in mind that users will be able to use these actions only if they are not next in line. If they are, they will only get a notification indicating that there are no more people in front of them.

Here is what you need to do in order to get the most out of Android Wear notifications:

I hope you use Android Studio because the Eclipse is dead.

We are using NotificationCompat.Builder class because, when building with this class, the system takes care of displaying notifications properly, whether they appear on a phone or smartwatch.

This class will receive the clicked wear action and either “snooze” the notification or remove the user from the queue. It will also dismiss notifications on Android Wear.

As you can see, with just a few extra lines of code, we gave our users an option to interact with our application without reaching for their phones. Considering the fact that implementing support for Android Wear is really easy, I believe that every Android dev should be aiming to update their apps as soon as possible.

Maybe now you are thinking; “Heck, why would I do that when the majority of users won’t buy a fancy smartwatch?” That’s a valid concern, especially when we know that the current generation of smartwatches costs between $200 and $300.

But like with any other technology, the price of Android Wear devices will go down and they will become more widespread. Making sure your app supports this innovative technology is a smart investment for the future.