If you are here, probably you know my other series of blog posts called Modern Security for Android Developers — While that series has an incredible story and is still very usable to use, there are some changes in the API and Security layers in the last couple years inside the ecosystem that make it a little bit outdated, so here it is, the remastered version

Here is the list of the parts in this series:

• Part 1 — Encryption
• Part 2 — Credential Manager API
• Part 3—Passkeys
• Part 4 — Android Keystore Deep Dive and Secure Key Management
• Part 5 — Integrity and Network security

Part 1 — Encryption

Encryption is one of the most crucial parts of any software, and inside Android this is not an exception

Android has a wide array of algorithms for protecting data using cryptography. In software there are multiple algorithms (or a esult of algorithms) that are constantly used for security and confidentiality. Usually, this depends of the Cryptographic Architecture that this languages and OS have available
For Android this falls on the land of Java Cryptography Architecture (JCA) that is designed to offer an extensible mechanism for cryptographic services, including Hash, mathematical schemes and cryptographic keys, and others

Some of these task are terms that are allocated inside the cryptographyc architecture— Cipher, MessageDigest, MAC, and Signature — and refer to fundamental concepts and tools inside the JCA, each serving a different security goals

Cipher

An algorithm used for encryption and decryption. Its main purpose is to ensure confidentiality by transforming plain text into an unreadable form also known as ciphertext, and uses a mathematical algorithm and a secret key to scramble the data.

Ciphers fall into two main categories based on key usage:
Symmetric Ciphers: Use a single secret key for both encryption and decryption, they are usually faster

Asymmetric Ciphers (or Public-Key Ciphers): Use a pair of keys (a public key for encryption and a private key for decryption) they are used for secure key exchange and digital signatures

One of the most important parts is that it uses a pair of keys — a public key for encryption and a private key for decryption and they have different types of algorithms

The algorithms can be: Advanced Encryption Standard (AES) or Rivest–Shamir–Adleman (RSA)

• AES a cipher by blocks (symmetric)
  In Android development, AES is the workhorse for bulk data encryption (e.g., local files, databases) due to its speed
• RSA a cipher with a public Key (non symmetric)
  RSA is primarily used for smaller tasks like securely wrapping an AES key (key exchange) or for digital signatures, but is much slower for encrypting large amounts of data

The mode is: how the algorithm process the data in cipher chunks for example AES need this, the cipher mode is critical for security. A common and recommended mode is GCM (Galois/Counter Mode), which not only dictates how the data is chunked but also provides authenticated encryption. This means it ensures both confidentiality (encryption) and data integrity (it hasn’t been tampered with).

The Padding is: the part of the encryption required for cipher that work in blocks, when you are working with blocks then the size of said block needs a exact size (ex. 128 bits para AES), the padding act as padding that add additional bytes at the end of the original message if the message doesn’t fulfill the size. For instance, if you are encrypting a 130-bit message with AES-128 (which uses 128-bit blocks), the padding scheme (like PKCS#7) will add 126 bits of padding to create a complete second 128-bit block, ensuring the entire message can be correctly processed by the block cipher

You can see all the algorithms supported by Android and Android Versions here

Message Digest

A cryptographic hash function, that takes an input of the message without mattering the size and produces a fixed-size, unique-looking output called a hash value or digest.
Usually they are used for verification to make sure that data hasn’t been changed and it is computationally and mathematically impossible to reverse the process to find the original message or to find two different messages that produce the same digest (collision resistance). It does not use a key.
For Android: SHA-256 is the most common

Message Authentication Code (MAC)

A fixed-size tag generated from a message using a cryptographic algorithm and a secret key. Commonly used for data integrity and to match origin authentication
It is appended to the message both, the client and the receiver share the same symmetric key and the receiver uses it to calculate the MAC on the message and compares it
For Android: HMACSHA256 (Hash-based MAC) is the most common

Digital Signature (Signature)

A mathematical scheme for verifying the authenticity and integrity of a message. It is created using a private key and is verified using the corresponding public key, this is usually what we think when we discuss public and private keys in software security

This algorithms can be used for many encryption processes, however, if your app requires a higher degree of key security, you should use the Android Keystore system, this allows you to store cryptographic keys in a container, making them significantly harder to extract from the device, once keys are in the Keystore, the key material remains non-exportable

We are gonna talk about Keystore in the following parts, as a proper substitution for the now deprecated security-crypto Jetpack library that used to provide a wrapper like EncryptedSharedPreferences and EncryptedFile to simplify encryption for local data storage. This library is deprecated (as of v1.1.0-alpha07 in April 2025 and stable release 1.1.0 in July 2025) in favor of existing platform APIs and direct use of Android Keystore. For developers looking to replace EncryptedSharedPreferences, the modern platform solution is using DataStore combined with keys managed by Android Keystore to encrypt the underlying file — we are gonna discuss how to implemented it in the last part of this serie, that meets all the security requierements that are usually need it

This is all for this part of the posts, If you need help:

I’m always happy to help, you can find me here:

BlueSky: https://bsky.app/profile/ddinorahtovar.bsky.social
X: https://x.com/DDinorahtovar
Medium: https://medium.com/@dinorahto
StackOverflow: https://stackoverflow.com/users/4613259/dinorah-tovar

Happy Coding! 👩🏻‍💻

Master Class on Security (part 1) was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog post is quite different from everything I have ever published, this is an open letter for all the developers and all the people in Product, that are building consumer-facing features, including non-only UI experiences, but also the ones that are creating APIs, security, and Architectural layers. This is gonna be a couple of opinionated comments and visions of how we should address some ideas, feedback, and mostly dilemmas around our profession.

I have been a mobile engineer for many years, around my time as a professional I had the pleasure to grow in many different positions, from platform, architecture, and product — all these different areas, are involved with the users, some have a closer interaction than the others and today I’m gonna tell you a story about some lessons that were learned in a hard way over multiple years.

The feature is not only a problem to solve

I used to think of features as a problem we need to address, we made rationals about architecture, task, and actions to tackle, we go over ideas from using X over Y and how long it would us to build that new functionality, everything ends up revolving around Jira tickets and sprints.

In my first years I learned that asking “why” was as important as asking “how”, ‘cause engineering is about being resourceful to our counterparts in different areas, we need to create a retroactive chain of creativity with multiple stages that makes us aware of solutions, proposals, and process; that’s why I believe that a good product engineer should be strongly tied to the proposals from UX/UI, research, and growth.

As engineers sometimes we ended up thinking that we don’t need to be involved in this chain at all, hiding us behind the excuse that if we are not experts other than our areas, we should stay behind — A couple of months ago one developer told me that he was not involved in this kind of process and prefers to non-being a point of intervention, he believes that having this kind of affairs were tiresome and must of the times boring — Probably many engineers think of Product or Growth areas in the same way, but the factual reason of thinking this way is that we don’t have a culture revolving around the product (which is one of hardest to cultivate); whatsoever zero-intervention will create mediocre developers, but also mediocre products. One may wonder, why? the answer is quite simple, imagine this a chessboard knowing where all the pieces are placed give you the capacity of planning your next step, so having the understanding of decisions give you improvements on future areas of your codebase and operations, maintainability, and opportunities for growth, you became a player and not an observer.

Asking the correct questions

Creating a good relationship of Product with Tech is a maze, but everybody can solve it even when is not for everyone; a good starting point is asking the correct questions to the right people, also is start seeing us [engineers] as more than executors.
I’ve been thinking very deeply and profoundly about where do we stand as engineers if what we are gonna build in with tons of lines of code is gonna be in the hands of tons of users, are we a huge broadcast? where do we stand today inside the process? Are we executors or are we part of the procedure? I think I don’t have an answer, I believe we need to be in the middle of the whole process.
In the light of being resourceful, we need to deliver criticism and be honest about processes that may not be correct, secure, or straightforward for our users, we need to be really heart-spoken and opinionated when we get to deliver feedback with our users in mind — A year ago, I was building a new chart for our users, I didn’t understand what I was doing, the logic was tricky in the good light and horrible in the bad one, it was a failure in production — I forgot the user that day, that feature was not good enough, it was noisy and the UX/UI just make it worse.
I should have asked the correct question to get my concerns addressed, but I was playing the “only a developer” role that day, I remember hearing “this was a normal mistake” and thinking, “No, it’s not, we spend weeks building a feature that was poorly checked that could be way simpler”, there are always ways to simplify the noise around features and is our job to make it simpler.
There’s a design law for simplicity and limitations called Tesler’s law:

Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.

Every feature we build should land in the limits of Tesler’s law, we need to safeguard our users and our teams from experiences that are nonventilated to the law, we may not be a group of experts, but we can ask tons of questions to help our teams and our products to grow. Asking the correct question will eventually lead us to start a dialogue, a dialogue will start a feedback session and this is where we can stop being only executors to be part of this constructive chain.

Ideas, Thoughts, and Comments

Asking this amount of questions will definitely lead us to something I call — a space of creativity — which is where we can grow a culture of dialogue and product.
As an engineer, we need to work on our communications skills to deliver dialogues that are beneficial for creativity and invention, without adding the common “tech fog” in the process that will lead us to go too technical, especially because this creates a dome that pushes the conversation to the boundaries of "tech square" and creates a mental box for solving a problem; so we end up with a halfway solution proposed by tech that only addresses half the problem, having good communication skills and trying to improve them is key to go to the next step; In the last couple of months, I have been trying to walk out of the woods and the fog and one of the things that have helped me the most is understanding what an idea, a thought, and a comment are.

An idea and thought are two words that are often confused when it comes to their meanings and connotations. The idea refers to a plan or a process that occurs in the mind in relation to the completion of work or duty, on the other hand, a thought is a mental process that keeps on going in the mind unabated. A comment is an adjacent and overview part to a principal concept, the first one can not live without the second one but the second one can live without the first one.

Having this concept clear will helps us to talk about any topic, from delivering feedback to developing a strategy, and making decisions, it also opens the door to complex and difficult problems.

Some teams especially in Growth and Product will choose practices and theoretical processes that can hurt more than the benefit that brings to the users, as Developers we are the last straw to stop a dangerous process, when it may work for the other teams it may compromise the integrity of the product we are building, for example, privacy.

Complex topic and moral dilemmas

After being able to handle communications and thoughts, we can talk about dilemmas that may not be the easiest topics to address without having some kind of confrontation with the team that is using some tool or method. Privacy has always been a moral dilemma, especially inside technology companies — It shouldn’t be — as engineers we end up planning how we address this dilemma, is our responsibility to keep our users safe and keep it away from prying eyes we take hard considerations about stored data in phones and databases, we think of methods of encryption from ciphers to certificates, going from Keystore to Keychain, but we may forget that this also includes Product, from analytics to multiple tools to do user research.
Almost a year ago I published this tweet asking about the implications of Session Replay software (a tool that recreates the clicks and views of a User)[No boundaries: Exfiltration of personal data by session-replay scripts] and crossing the boundaries of privacy and personal data.

Dinorah Tovar on Twitter: "Asking the right questions here:What do you think about session replay software, on websites/mobile apps/progressive apps? Share your thoughts and opinions below. / Twitter"

Asking the right questions here:What do you think about session replay software, on websites/mobile apps/progressive apps? Share your thoughts and opinions below.

The “Neutral” option is not a position we can take, the implications and normativity of these tools should be taken into consideration by developers — that are putting the SDK on the user phones — and by the Product persons — that are consuming this data — building team integrity will create integrity for the products.
At the end of the day, we are responsible for the decisions we take and make, we have a voice that needs to be heard around all the areas we can reach, make ourselves opinionated, and ask questions, especially this one, not only makes us better professionals but also better human beings.

Black boxes are like half-empty glasses

I use to think that Tech and Product were areas full of black boxes, I don’t let myself think as an executor in a black box fulfilling the wishes of other boxes, thinking this way gives us only half of the solution and probably the poorest one, it puts us inside a block that only knows half the answers to half of the questions. A good product solves a problem in the finest possible way, and this involves security, architecture, UX/UI, and performance. Thinking in a holistic way will bring us stronger ideas and solutions, but especially a culture that can be a harvest for years to come.

So, if you are at the end of this post, the only advice I can securely give you is that being a passive Software Engineer will lead you to become an executor, you won’t be creating products, you will only produce code; and friend, that’s two completely different things, so remember that, you are here to build products, not only code.

Disclaimer

I am not in the product area, these are opinions of how I conduct myself every day. I hate the word user, I think it cuts down the person that is consuming your app to a number, we tend to minimize this and we end up caring less about some parts. And finally, I’m always open for comments on my Twitter account or here.

If you need help, I’m always happy to help, you can find me here:
Medium as Dinorah Tovar
Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar

Happy Coding! 👩🏻‍💻

Product visions: From an engineering perspective was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

Easy data layer for every Application, here is the list of the blogs in this series:

• Part 1 — Performance for queries
• Part 2 — Threading and Concurrency
• Part 3 — DataStore and SharedPreferences

This is the second part of the series “Wild Storage for Android developers” today we are gonna discuss Data Store and Shared preferences, specifically why they are an alternative to the normal Database

So in the past part, we talk about how Room can help us to handle threading and concurrency, this is something that was missing inside SharedPreferences which is one of the most primitive ways to save data inside Android! Let’s talk about Shared preferences and Data Store

Shared Preferences and Data Store

I have been getting this question around for a while, DataStore is the same as Shared Preferences? Well, the short answer is no!

The main reason is that SharedPreferences has the next qualities that make it one of the most simple approaches, also pretty much follows the pattern of a file that stores a Key-Value in an XML file, that you can found in a debug app if you search for it, whatsoever is private for other apps and even trying we can not reach for it, a couple of years ago you can create a SharedPreference file with some public modes like MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE that have been deprecated and if you wanna use something like this, your app will crash with a SecurityException.

• Synchronous updates — All the process run in the main thread
• Primitive Values — The only values available are Boolean, Int, String, or even a Set<T> where T is a primitive value
• They can also be encrypted — SharedPreferences are the main instrument inside the incredible library androidx.security:security-cryptothat can encrypt data using a KeyStore approach, but it also follows the same restrictions and approaches that normal SharedPreferences, so, you can only encrypt primitive values, that is more than enough for multiple tasks that requires encryption.
  If you wanna know how to encrypt data, you can review my past serial “Modern Security for Android Developers” on Google Developer Expert Blog

For DataStore is focus on handling the overwork some teams were putting on SharedPreferences, especially with a focus on the threading integration.

• Asynchronous updates — All the process of editing and fetching data from the schema of DataStore are addressed over a flow that represents the stream of values that are being asynchronously computed
• Objects — You can have an object inside DataStore with the use of ProtoBuffers that will make this approach type safe, without this, you will be able to store only Key-Value primitives without type safety
• Encryption — There’s non available encryption for the moment for DataStore, but you can Encrypt a full data base using Room or Realm

One of the most important parts of DataStore in a simple way:

Using the first way, you will create a simpler DataStore<Preferences> object and with the secon, you will create a migration from the SharedPreferences you were using in the past.

DataStore use Flow to extract data from your Preferences object, that provides efficient, cached access to the latest persisted state, then flow will take one of this two actions: Emit a value or throw an exception

You can safe data and get the values using this approach

For Protobuffers, we need to create an new object that extends Serializer with all override all the objects need it to a sucessful serialization.

This is all for this serial! Feel free to ask any question here or at my Twitter account that you can found below!

If you need help, I’m always happy to help, you can find me here:
Medium as Dinorah Tovar
Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar

Happy Coding! 👩🏻‍💻

Wild Storage | Part 3— DataStore and SharedPreferences was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

For Android developers

Easy data layer for every Application, here is the list of the blogs in this series:

• Part 1 — Performance for queries
• Part 2 — Threading and Concurrency
• Part 3 — DataStore and SharedPreferences

This is the second part of the series “Wild Storage for Android developers” today we are gonna discuss Threading and Concurrency specifically for how coroutines work for Room

Putting some details about the last part, usually, we end up with something like this in Mobile applications, we may have a suspendable function that goes to an API, and once this answers the expected result we may want to put some data inside a database.

We don’t want funky performance, our users will notice if we have some trouble loading our views, usually, about 60 frames per second our users can perceive the change of frames as smooth if our tasks are taking more than 16 milliseconds (not only fetch from the database but also network calls, maybe loading a view or even startup time) this can cause us trouble on a big scale especially cause all our users will notice, so we may use some threading to handle this part in a successful way like I say in the first part of this serial you can use Coroutines to create a suspend function inside Room, but we need to talk about multiprocessing and threading first!

Threads

Multiprocessing is the use of CPUs inside a computer, is the ability inside the hardware to support more than one processor and allocate tasks between them, all smartphones have processors.

Depending on the hardware, the operating system, and the software design we are building we have may have some considerations to determine the symmetry of the multiprocessing system, some may be equal, others may be reserved. For example, we may decide that we only going to have one particular CPU respond to all actions, which will make this multiprocessing app easier to make, but it will make the app less efficient than others in which all CPUs are utilized with multiple processors allocated, the reason is quite simple, cause if we have the ability to set up all the process we will be able to create more that one thread of execution within a process, giving space to something called multi-threading.

Whatsoever between process, we may have multiple threads, then Thread #1 start his execution, we may have to create another Thread #2 to execute a secondary task, you can’t execute more than one thread at the exact same time, there’s a reason for this!

Everything that may happen in multiprocess architecture need at least this three parts: Scheduler, Processor, and Dispatcher, the first one is in charge of priorities like his name says is the method that will be assigned to resources that complete the work, and makes sure that all the threads get to run and get to finish, the Processor is the process of allocation of the task, and the Dispatcher make sure that set up all the threads in the specific allocation context we need to be executed, for Android in specific, we may have some operations that need to run in the user interface context and another outside of this one, the first one, is a thread that is full user-facing is called UI thread, runs inside the On Resume and Foreground of our apps and can dispatch other threads that may run in the background. All our apps need a basic thread to start and this will change, only if we explicitly switch threads inside the code, for example, the use of the keyword suspend will switch the thread, this also applies for callbacks in RxJava or any Thread, Run, or Handler function, this applies for databases, network calls and mostly everything that we want to do to have a good performance in terms of user experience if we block UI Thread for too long this can cause the app to get blocked completely, this action is known as an ANR’s problems.

ANR problems can be tracked inside the Google Play Console in the Android Vitals part, and as quoted in the documentation

Android vitals considers ANRs excessive when an app:

Exhibits at least one ANR in at least 0.47% of its daily sessions.
Exhibits 2 or more ANRs in at least 0.24% of its daily sessions.

We are not gonna talk about ANR right now, but I will write a new serial in a couple of weeks called “Spikes of Performance” when we are going to revisit all the problems we may have not only in threading but also in loading views and writing files.

Handling threading and concurrency of confined threads in the database is a primordial key part for a good performance, which some database like Realm already have callbacks that can be used to execute transactions in a kind way, for Room we need to use Coroutines

Coroutines

Not only Coroutines are the recommended solution for Kotlin development they are also really simple to approach cause basically a coroutine is thin threads and can be used in Room, whatsoever this is not obligatory, cause Room has the possibility to use Synchronous and Asynchronous methods with only using the key world suspend

These two functions look exactly the same, but let’s review the code.

Synchronous vs Asynchronous
We know that Room autogenerates code to helps us with the integration processes and to take the boilerplate that was implied when we use to do SQLite on Android, one of the most important parts of this, cause these two images are the autogenerated code from Room for a non-suspend function and a suspend function

The first one and second one are pretty much similar in these specific parts that represent the generated code of an Insert to a table, this does not change even in asynchronous or synchronous code:

• beginTransaction — Begins a transaction in EXCLUSIVE mode, this mode is pretty similar to IMMEDIATE modes in SQLite, in that a write transaction is started at the moment that is called, except that this mode prevents other database connections from reading the database while the transaction is underway.
• insert — That will insert the object inside the required table
• setTransactionSuccessful — Marks the current transaction as successful
• endTransaction — End a transaction that was created at the beginning with the first method

As an Asynchronous function, we can appreciate that the code executed is happening in the UI thread, there’s no callback at all and for this specific Insert we may think this will not cause any ARN or any notorious performance bug, you may be correct, whatsoever, other patterns can cause this to create a problem that we can easily correct using a coroutine, for example, in the second image, the generated code has a callback with a new type called — Continuation that pretty much creates an interface representing a continuation after a suspension point that returns a value of type T as an instance with the given context (a dispatcher for the coroutine) and implementation of resumeWith method, and just like that, the Insert will happen outside the UI Thread and we will not allocate any retention frames.

We are still missing the other execute knows as CoroutinesRooom is the part in charge of switching to another dispatcher, depending on whether the status of the database, remember we can have an open, in the middle of a transaction or a closed database. If the function we are trying to execute is the first two options, Room will do the Insert right away, for the other status, Room will make sure that everything is happening in a secondary thread using a different dispatcher for the transaction, the generated code looks something like this, you can found this code in the Open Source code of Room

Concurrency

We have been talking about the importance of having a secondary thread to execute our task, especially in databases, cause in Android’s SQLite transactions are thread confined if a coroutine is paused there a possibility that the resumed coroutine will not be executed in the same thread.

Let’s give it a look at this gif, we may have an Update and a Delete from a click and this will be executed in threads, we may want to have all this process in one ☝️ and only thread.
But imagine we end up with another click that will Insert other data, the first Update will execute in Thread #1 but if the Insert happens between the Update and Delete, the Insert will use Thread #1 because is not currently in use, so the Delete will not happen in Tread # 1 will happen in Thread #2 and this is also known as a concurrency problem, cause we may not know if the Delete was successful and this can cause a deadlock

What we need to do to make sure Update and Delete happens in the same thread is running these two methods inside a transaction.

A transaction will make sure to execute and only mark as successful as many methods that are depending on each other and they will be executed in a specific dispatcher that will guarantee that all the methods will be brought in the same thread.

The transaction can also be used as an annotation inside a DAO with abstract functions as mentioned in the documentation

This is all for this part of the post. For the last part, we will discuss Datastore and Shared preferences and I will talk a little about the security behind this!

If you need help, I’m always happy to help, you can find me here:
Medium as Dinorah Tovar
Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar

Happy Coding! 👩🏻‍💻

Wild Storage | Part 2 — Threading and Concurrency was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

For Android developers

Easy data layer for every Application, here is the list of the blogs in this series:

• Part 1 — Performance for queries
• Part 2 — Threading and Concurrency
• Part 3 — DataStore and SharedPreferences

This is the first part of the series “Wild Storage for Android developers” today we are gonna discuss Performance in the queries specifically for how to get better instances and responses, and especially how we should handle the database with an easy approach as a performance-wise solution.

Usually, for mobile, this is a common approach, the user may launch some type of action and we will call an API and this API will return a result that we may be written to a file, shared preferences, or a database, here is the first important part for the data layer of your app, the Network layer, if you are interested in more information about you can check my past serial “Practical Network for Android Developers”

And the second part is the Local Data Layer that is handled by internal storage, for this part we are not gonna talk about files, and we will discuss SharedPreferences in the third part of this serial.

We may have multiple types of cache and some are specifications to Network, but we may have Database caching, some examples are

• CDN — Global network of edge locations to deliver a cached copy of your APIs content
• DNS — Every domain request made on the internet essentially queries DNS cache servers in order to resolve the IP address
• Database caching — Database provides an impactful factor in your app performance.

Many Databases

There are too many databases some are relational and others non-relational, for many years the fixed solution for Android development was SQLite, SQLite is an incredible tool, scales well, and is wildly used in multiples companies, but for Android, there were some problems, for example, runtime crashes, the boilerplate was enormous, and after some consideration, many alternatives were created for example

• SQL Delight — Typesafe alternative for SQL statement, that understands your existing SQL schema.
  • TypeSafe — Typesafe Kotlin APIs from your SQL statements
  • Kotlin first — even for Multiplatform
  • Threading — support for Coroutines, RxJava, and Android Paging
• Room — Google alternative to SQLite that mostly a wrapper of the original SQLite implementation
  • Compile-time — verification of SQL queries
  • Less boilerplate — and follows the DAO pattern
  • Threading — support for Coroutines, flows, and so many other things
• Realm — Non-Relational and recently handled by MongoDB with an alternative for Sync on their own cloud
  • Threading — Executables for transactions -> executeTransactionAsync
  • Listener — OnChangeListener
  • Has a browser — RealmBrowser
  • Easy Encryption — Using KeyChain can happen really easy

Performance

But today, we are gonna talk about Room as one powerful solution with great performance for Android Development, Room works as an abstraction layer for SQLite, many applications use SQLite as a cache of relevant content from an enterprise RDBMS, there are some reasons we need to talk about why is a powerful solution.

• The addressed file in Insert, Update or Deletegenerates a small edition and only overwrites the parts of the file that change, reducing write time and wear on
• All the Insert, Update or Delete can be created based on concise SQL queries instead of procedural routines, causing the least error-prone details
• The database can be updated and migrated making it super flexible to address changes with the idea of preserving backward compatibility, if you are interested in Migrations and how to handle it you can review my past blog post “Select, Insert, Indexes and Foreign Keys on Room Migrations”
• We can address performance problems, using Index, Foreign keys, and multiple other tools of integrity, avoiding redesign and revamping efforts

Let’s talk about how to manage a better query performance using Room, there are some basic rules that we may need to address:

Take what you need
This is one of the most basics performance-wise actions we can take about extracting data from our database. Let’s imagine that we have a Product table that contains multiple data like name, price, type, promotions, offers, and many other things, It may be really simple for us to take all the information from the table indiscriminately, what so ever, by using, SELECT * you can return useless data that will be only using space in Runtime memory.

Accessing databases and fetching data from them has an IO cost on the performance of our applications and if we are not careful we may end up with tons of wasteful IO cycles on the DB, also take into consideration that a SELECT * can make your query slower.

Foreign keys, Primary keys, and Relations
Foreign keys are more focused on the integrity of the database, but with Indexes, they boost performance, inside Room adding a Foreign key will not force you to add an Index key, but you should create indexes on all Foreign key fields to improve look-up times.

Relation in Room gives us the opportunity to have “embed” some Entity inside a Data Class, @Relation which works as an annotation, when the info is returned from a query, all of its relations are also fetched automatically.

Transaction
Transactions are annotations that can be used in functions to execute the non-abstract method of an abstract Dao class, the derived implementation of the method will execute the super method in a database transaction.

Transactions help us to handle a block of code that needs to be fully successful to be marked as that, the transaction will be marked as successful unless an exception is thrown in the method body. We will talk a little deeper about how Transactions work under the hood in the second part!

Coroutines ✨
Sounds like a pretty straight forward process to run all our queries in a secondary thread, to not block the main thread and this can be applied to anything inside Room just adding the keyword suspend

From the insert to the transaction, we need to verify how the threading and the concurrency of the queries and functions are handled, but that will be addressed in the second part of this serial!

If you have a question about handle Foreign keys, migrations, and insertions on Room, you can review my past blog post about this topic “Select, Insert, Indexes and Foreign Keys on Room Migrations”

If you need help, I’m always happy to help, you can find me here:
Medium as Dinorah Tovar
Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar

Happy Coding! 👩🏻‍💻

Wild Storage | Part 1 — Performance for queries was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is related to my lastest talk about “Modern Security for Android Developers”.

Here is the list of the blogs in this series:

• Part 1 — Encryption Vol 1
• Part 2 — Encryption Vol 2
• Part 3 — Encryption Vol 3
• Part 4 — Biometric as Local Auth
• Part 5 — Native Code Modules
• Part 6 — SSL, TLS, Secure Data layer

This is the final part of the serial and probably the opening part of my second serial “Practical Network for Android Developers” that is gonna be available after this article.
In the Mobile world is common knowledge that you may need a couple of network services to make your app work, we usually assume that our services are gonna be okay if our connection is an https, but in reality, this is not completely true, putting some tools can make your request being available and sniffable from a Charles or a Wireshark.

Transport Layer Security (TLS) is the successor protocol to SSL. TLS is an improved version of SSL. It works in much the same way as the SSL, using encryption to protect the transfer of data and information. The two terms are often used interchangeably in the industry although SSL is still widely used. To keep your app secure you need an SSL certificate, usually, your server needs to have a private key and a public key, your app, and your server will do a handshake, the server using a private key of a certificate that has been signed by public-key cryptography.

Whatsoever, a handshake does not prove anything, anyone can create one for any website, that’s why you need a Certificate Authority!

A Certificate Authority is an org or company that validates as an identity, if you work for FakeCompany, you can create one identify you as a website, email, or even person, this digital certificate is a cryptographic key, it gives us a way to authenticate us by using some credentials to validate us, and encrypts our data of communication over insecure networks, this helps us to make sure that nothing can be altered by any sniffer when transferring data, the certificate will create the two keys we need, a private and public, but will add a CSR, which is a file that includes information about the authority. We can have two types of CSR, one is CER and PFX

When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another parties, or validate documents that were signed with this authority.

CER: Commonly used by SSL to identify web servers
PFX: This contains cryptographic data of the authority, certificates chains, and private keys.

Both are cryptographically protected with passwords to keep private keys private and preserve the integrity of the certificates. Just ask your DevOps engineers for the certificate (if you don’t have this kind of team, just ask the person that make the server configuration)

You can add the certificate to your HttpClient call in a very simple way, let’s do it:

1. You can keep your certificate in the Raw folder, if and only if, the password is not stored as plain text in your code.
2. Once you do this you can create an instance of the Keystore, remember we want to have this secure, so this certificate should happen in a trusted execution environment, depending on the type of your certificate you need to create a default type instance or a PKCS12,
   PKCS12 defines a file that is storing many cryptography objects as a single file AKA PFX.
3. We also need a KeyManagerFactory integration for X509
   X.509 is a standard defining the format of public keys it contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a Certificate Authority or self-signed.
4. Once we have this KeyManagerFactory and our Keystore with the certificate, we can create an instance of SSL with TLS

Depending on what you are using, you can add this SSL integration to your HttpClient, for this example, is OkHttpClient, adding the SSL socket factory line

Using this, you made sure that your handshake will be secure and inaccessible for third parties and your data transfer will be secure!

This is all for this serial, thank you so much for keeping an eye on this, the serial was divided into multiple talks but you can found the final one on this website
In English at Droidcon EMEA
In Spanish at DevFestLatam
Slides are available at my Speaker Deck

If you need help:

I’m always happy to help, you can find me here:
Medium: https://medium.com/@dinorahto
StackOverflow: https://stackoverflow.com/users/4613259/dinorah-tovar

Happy Coding! 👩🏻‍💻

Modern Security in Android (part 6) was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is related to my lastest talk about “Modern Security for Android Developers”.

Here is the list of the blogs in this series:

• Part 1 — Encryption Vol 1
• Part 2 — Encryption Vol 2
• Part 3 — Encryption Vol 3
• Part 4 — Biometric as Local Auth
• Part 5 — Native Code Modules
• Part 6 — SSL, TLS, Secure Data layer

One of the things I usually say about Android that surprise people is that you can write code in C and C++ and usually they think is cool stuff cause Java and Kotlin code can be decompiled easily, (if a mobile application has obfuscation, probably the task will be a little harder) but C and C++ not, at least not in the same way that java, C code can’t be decompiled but can be disassembled

In Android, we have a special thing that manages runtime called ART (Android Runtime) is the predecessor of Dalvik, ART uses an executable format of Dalvik and Dex bytecode, this supports the JNI (Java Native Interface) that is the magic part that let Java code operate and interact with code written in C/C++, let’s remember that Android is a Linux based OS native code is packaged (compiled) into ELF dynamic libraries (*.so), which the Android app loads at runtime via the System.load

In the next example:

init {
    try {
        System.loadLibrary("someKeyWeWantSafe")
    } catch (e: UnsatisfiedLinkError) {
        Log.e(TAG, "Error loading library " + e.toString());
    }
}

This load happens using System.loadLibrary that is a library written in C/C++ if you navigate inside the code of loadLibrary, you will see a Security Exception, thrown by the security manager to indicate a security violation, whatsoever the violation is not called when dissembling the code.

You can create a module, and add your private secure key here, inside the C Module, using something like this:

#include <jni.h>


JNIEXPORT jstring JNICALL
Java_com_secure_project_keymodule_NdkKeys_getKey(JNIEnv *env, jobject instance) {
    return (*env)->NewStringUTF(env, "someCoolKey");
}

When reversing an Android application containing native code, we need to understand a couple of data structures related to the JNI bridge between Java and native code. From the reversing perspective, we need to be aware of two key data structures: JavaVM and JNIEnv. Both of them are pointers to pointers to function tables:

• JavaVM provides an interface to invoke functions for creating and destroying a JavaVM. Android allows only one JavaVM per process and is not really relevant for our reversing purposes
• JNIEnv provides access to most of the JNI functions which are accessible at a fixed offset through the JNIEnv pointer. This JNIEnv a pointer is the first parameter passed to every JNI function. Is also used for thread-local storage. For this reason, you cannot share a JNIEnv between threads. If a piece of code has no other way to get its JNIEnv, you should share the JavaVM, and use GetEnv it to discover the thread's JNIEnv.

It is worth highlighting that it’s never a good idea to leave your API keys lying around your codebase in a way that’s easily decodable, analyzing disassembled C/C++ code is much more difficult than disassembled Java code.

While it is possible to get any key stored with the NDK, it makes it harder for beginners to get the information they are looking for inside your app, whatsoever, is easier for Internal Leaks to get what they want doing some basic research, is not a secure option for important keys, but it will make the trick for something simpler.

This is all for this part of the post, If you need help:

I’m always happy to help, you can find me here:
Medium: https://medium.com/@dinorahto
StackOverflow: https://stackoverflow.com/users/4613259/dinorah-tovar

Happy Coding! 👩🏻‍💻

I’m really happy to join Droidcon, Android Summit, and DevFest in the next couple of weeks for delivering this talk (especially the last part of this serial), I will show code, and I will try to answer all your questions!
Thank you so much for your support!

DroidconEMEA: Get your #dcEMEA ticket for as much as you want to pay until Oct. 2nd https://online.droidcon.com/emea2020 (please remember this is going to be at Central Time)

AndroidSummit: I have a special discount of 35% off https://eventbrite.com/e/android-summit-2020-tickets-116528595165?discount=AndroidSummitSpeakerDiscount2020…

DevFest Latam (this is only for Spanish speakers): https://www.meetup.com/es/gdg-costarica/events/272473635/

Modern Security in Android (part 5) was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is related to my lastest talk about “Modern Security for Android Developers”.

Here is the list of the blogs in this series:

• Part 1 — Encryption Vol 1
• Part 2 — Encryption Vol 2
• Part 3 — Encryption Vol 3
• Part 4 — Biometric as Local Auth
• Part 5 — Native Code Modules
• Part 6 — SSL, TLS, Secure Data layer

We finish the overview of the Encryption in Android and is time to speak about how biometrics works and how to use it to your advantage.

In Android 6.0 privacy became one of the priorities for the mobile teams, in this version, Google introduced a standardized API for providers, focusing on fingerprints adding a standard for them.
In the first volume of this serial, we speak about Trusted Execution Environments (TEE), these spaces are part of every modern smartphone, this means that the biometric information is encrypted and stored in a separate part of the phone, completely inaccessible to the regular operating system. Making the biometric data unexportable, we can ask the TEE to authenticate the identity of our users, but the biometric data is not accessible, or injectable, making the biometrics a local authentication form.

Phones have evolved and now Android includes face and fingerprint biometric authentication. Android can be customized to support other forms of biometric authentication, for example, iris. Inside the code, Android has a class to handle the biometric authentication called BiometricPrompt that includes Fingerprint and Face, Google has to validate that biometric implementation meets a couple of security specifications to join this class, principality it needs to have a secure architecture this means, that the biometric data should travel in a secure channel that guarantees that if the Kernel or the platform is compromised the raw biometric data will not be leaked and that data can not be injected in this secure channel, and secondly has to meet a metric called spoofability that is measured by three other metrics that are described at the Spoof Acceptance Rate Guide (SAR) to measure how resilient a biometric is against a professional attacker, includes:

• False Accept Rate (FAR): Mesures how often a model mistakenly accepts a randomly chosen incorrect input.
• Imposter Accept Rate (IAR): Measures the possibility that a biometric model accepts data that mimics the original data. Imagine an Imitator of an actor or a singer with a similar face or a similar voice.
• Spoof Accept Rate (SAR): Measures the possibility that a biometric model accepts a previously recorded data.

After these tests, a biometric implementation can fall out in one of these three categories:

• Strong: SAR(Spoof Accept Rate): 0–7% FAR (False accept rate): 1/50k FRR (False rejection rate): 10%
• Weak: SAR: 7–20% FAR: 1/50k FRR: 10%
• Convenience: SAR: >20% FAR: 1/50k FRR: 10%

That even contains the fallback (in hours) to the first-ever authentication, the probability of integration with BiometricPrompt class, and the possibility of using KeyStore. There’s a full document about the falling ratio in biometric sensors here, if you want me to go deeper on sensors and calibrations systems, please leave a message at the end of this post.

BiometricPromp in Action

On Android 9 the BiometricPrompt give the developers a new way to handle FingerPrintManager (this class is already deprecated) without the need to add a new UI, BiometricPrompt permits the users to understand simple UX/UI making it a seamless experience.

To start using the BiometricPrompt class you can implement this at your gradle file, is a pretty much straight forward implementation:

dependencies {
    implementation "androidx.biometric:biometric:1.0.1"
}

To add a biometric prompt builder you only have to create this builder

We need to add a new listener to the actions and results of the user, that will give you Success, Failure, and Error if the user fails multiple times to authenticate the Biometric prompt will block the user for a couple of minutes till can try again, this will happen in the Error callback

If you have any problems with the implementation there is a full blog post from Sam Edwards (Sam Edwards) in his blog: https://handstandsam.com/2020/05/07/unlocking-biometric-prompt-fingerprint-face-unlock/

Adding Biometric prompt to your encryption

In the second part of this serial, we talk about the possibility of creating your own KeyPairGenerator, even if you are not using Jetpack Security, you can add the line 7 in the next gist to make sure the users has any type of security:

You can use a secret key that allows you to use the biometric credentials for a specific validity time period, during this time period, your app can perform multiple cryptographic operations without the user needing to re-authenticate, you can do this too when you create your master key for Jetpack Security

This is all for this part of the post, If you need help:

I’m always happy to help, you can find me here:
Medium: https://medium.com/@dinorahto
StackOverflow: https://stackoverflow.com/users/4613259/dinorah-tovar

Happy Coding! 👩🏻‍💻

Modern Security in Android (part 4) was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

Usually, if you work for a company that needs a secondary login, something like a One time Password (OTP) you need to create this kind of UI. Maybe it will not be a circle but it will be an Edit Text with a special UI to match the correct UX.

Today, we will write this UI, in a simple way:

So the first thing you need to know is that we are extending AppCompatEditText and not only EditText, this is because we are using AndroidX in our project, the second thing you need to know is to set the onDraw and the TextPain we want to use.
On the init function, we start our variables with our styles and colors selected by our UI experience, including the size and the stroke width and other multiple qualities of the view.

To use this view you only need to put this in your XML

<com.yourproject.PinEntryEditText
    android:id="@+id/pin_entry_edit"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:cursorVisible="true"
    android:digits="1234567890"
    android:focusable="true"
    android:inputType="number|numberPassword"
    android:maxLength="4"
    android:textColor="@color/colorLightGray"
    android:textIsSelectable="false"
    android:textSize="15sp" />

The max length in your XML property will create the number of spaces you want, so take this in consideration, cause maybe you will end up with an ugly if you are not careful with the padding on the PinEntryEditText.

This is a fast tutorial, If you have any question, feel free to reach me out
Happy Coding 👩🏻‍💻

EditText with every letter as a circle view, for OTP was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.

A practical overview of Migration from SQLite to Room

In the new project, we are working on, we are making a huge migration from SQLite to Room, We usually always use Realm, but we decide to give it a try to Coroutines and Room, to handle this huge migration from our side, but I found that sometimes you need a little more information about how to handle some parts of the code. So let's start with migrations:

Migrations are simpler than in pure SQLite, imagine we have this Data class entity, for our new Room implementation, with a twin but, in SQLite,

Migration and RoomDatabase

All classes that are annotated with Database must extend this class. RoomDatabase provides direct access to the underlying database implementation. Any query apart for the migration should never happen in this layer of the implementation, for that, you can use Dao. You need a migration if there was any kind of database you want to conserve for your users, this is handled with Room, Rooms offers a migration wrapper like the next one:

Migration: SELECT and INSERT

All the entities that your database will need, should be added to the superior part of the abstract class.
We can make a step by step guide for the migration:
1. You need to create a table with your Room entity with a different name
2. Copy all the information, from the SQLite Table to the Room table
3. Drop the table in SQLite
4. Rename the table to have a final entity with the same name that the table on SQLite

Foreign Keys

On the last step, we handle the copy and creation of the table, we use INSERT or REPLACE into the table selected. But this is not good enough yet, for our selected Entity, we need to create the Foreign keys over the UpdatedTableProduct, if we don’t do it, we will face this exception: Foreign key constraint failed, so when we create our table we will add this:

Indexes

The indexes in your table are important for multi-relational tables, for more efficient queries, remember a key to make this really efficient, is not to have many indexes, and this indexes should not change over time, because this will affect the efficiency, to create indexes for our entity:

Add a new column

Imagine your structure of columns change, maybe you add a new column to tell you if the user has viewed the detail of the product, so you need to alter your table first on SQLite:

And this will be our final result, with all these changes, you will have a final migration that is successful, without exceptions, remember if you have more that one table, you probably are going to write the 4 steps to handle the migration a lot.

If you need help, I’m always happy to help, you can find me here:
Medium: https://medium.com/@dinorahto
StackOverflow: https://stackoverflow.com/users/4613259/dinorah-tovar

Happy Coding! 👩🏻‍💻

Select, Insert, Indexes and Foreign Keys on Room Migrations was originally published in Knowing Android on Medium, where people are continuing the conversation by highlighting and responding to this story.