Speaker 1: Hey everyone, and welcome back to the Deep Dive. Today,
Speaker 1: we're diving headfirst into the world of Android app security.
Speaker 1: Oo exciting it is, right, We've got these excerpts from
Speaker 1: Testing and Securing Androids Studio Applications, so nice, and we're
Speaker 1: going to break it down figure out how to make
Speaker 1: sure that your Android apps are as secure as fort Knox.
Speaker 1: A mighty task, it is, but I think we can
Speaker 1: do it. You ready to get into it?
Speaker 2: Yeah, let's do it all right.
Speaker 1: So the book actually kicks off by talking about some
Speaker 1: core security concepts kind of like security one oh one. Yeah,
Speaker 1: that apply to all software, not just Android. Yeah, so
Speaker 1: things like access control, encryption, authentication.
Speaker 2: Yeah, the basics, the basics.
Speaker 1: It's interesting they emphasize this before even getting into like
Speaker 1: Android specifics.
Speaker 2: Yeah, it's really important to understand these kind of foundational
Speaker 2: pieces of security before you can even start to think
Speaker 2: about building a secure app. Yeah, because you know, we
Speaker 2: all have passwords, but what does it really mean for
Speaker 2: a password to be secure? What does it actually mean
Speaker 2: to authenticate yourself? How can you prove that you are
Speaker 2: who you say you are?
Speaker 1: Right?
Speaker 2: So those are the building blocks totally, and.
Speaker 1: The book actually quotes this guy, Boris Buyser, who's a
Speaker 1: software testing expert, and he says bugs lurk in corners
Speaker 1: and congregate at boundaries.
Speaker 2: Ooh, that's good.
Speaker 1: I feel like that's setting the stage for a whole
Speaker 1: lot of testing. It is.
Speaker 2: It means we to test everything, yeah, because those bugs
Speaker 2: are going to be hiden.
Speaker 1: Yeah. All right, so we've talked about some of the
Speaker 1: foundational concepts. Now let's actually talk about androids specifically.
Speaker 2: Okay.
Speaker 1: So Android seems to have like a multi layered approach
Speaker 1: to security.
Speaker 2: Yeah, it does.
Speaker 1: The book describes it as like an Onion architecture, oh,
Speaker 1: the Onion, yeah, which I thought was interesting.
Speaker 2: Yeah. It's a good way to think about it, because
Speaker 2: each layer adds an extra level of protection.
Speaker 1: Okay.
Speaker 2: So at the very core, you have the Linux kernel,
Speaker 2: which provides some of the most fundamental security features. Okay,
Speaker 2: and then on top of that you have things like
Speaker 2: app sandboxing, permissions, application signing.
Speaker 1: Okay, So let's break those down a little bit. What
Speaker 1: is sandboxing?
Speaker 2: Okay? So sandboxing basically means that each app lives in
Speaker 2: its own little isolated environment okay, and this prevents apps
Speaker 2: from interfering with each other or accessing data that they
Speaker 2: shouldn't have access to.
Speaker 1: Oh, so it's all about isolation.
Speaker 2: Exactly, It's all about isolation.
Speaker 1: Got it? Okay? What about permissions? Permissions those pop up
Speaker 1: every time I install an app, Yes.
Speaker 2: Every time on my phone. So permissions are how Android
Speaker 2: controls what an app can and can't do.
Speaker 1: Okay.
Speaker 2: So if an app wants to access your camera, it
Speaker 2: has to ask you for permission.
Speaker 1: First, okay. So it's like a check and balance.
Speaker 2: Exactly, It's a checks and balance the system.
Speaker 1: Gotcha, okay? And then what about application signing?
Speaker 2: Oh, application signing is how Android knows that an app
Speaker 2: is legitimate and that it hasn't been campered with. So
Speaker 2: every app that's published to the play Store has to
Speaker 2: be digitally signed, okay. And that's how your phone knows okay,
Speaker 2: I can trust this app.
Speaker 1: So it's basically like a guarantee that it can from,
Speaker 1: like a trusted source, a trust.
Speaker 2: It source, no one's messed with it.
Speaker 1: Right, Okay? Cool. So it seems like Android has a
Speaker 1: lot of built in security features. It does, but the
Speaker 1: book also talks about how smartphones are constantly connected and
Speaker 1: that kind of creates more opportunities for attacks.
Speaker 2: Right. Our phones are basically mini computers in our pockets.
Speaker 2: They're connected to the internet almost all the time. Yeah,
Speaker 2: so that just gives attackers more ways to try to
Speaker 2: get in.
Speaker 1: Okay. So let's say you are a developer, Okay, you're
Speaker 1: building an Android app. What are some of the common
Speaker 1: vulnerabilities that you need to watch out for.
Speaker 2: Well, the book talks about three really big ones. Okay,
Speaker 2: input validation, sequel injection, and intense spoofing. Okay, let's start
Speaker 2: with input validation. So imagine you have an app that
Speaker 2: has a form okay, and it's asking the user for
Speaker 2: their email address. Yeah, you need to make sure that
Speaker 2: the user is actually entering a valid email address. Oh okay,
Speaker 2: and not like trying to sneak in some malicious code
Speaker 2: or something.
Speaker 1: Is it like a pain to actually validate every single
Speaker 1: input it can be that a user could provide.
Speaker 2: But it's really important, okay, because without proper input validation,
Speaker 2: you're essentially leaving the front door to your app wide open.
Speaker 2: An attacker could exploit that to inject some harmful code
Speaker 2: or manipulate data to cast all sorts of problems.
Speaker 1: Okay, So input validation, that's something that developers really need
Speaker 1: to pay attention to absolutely. Okay. What about SQL injection?
Speaker 2: So? SQL injection is a classic attack that exploits vulnerabilities
Speaker 2: in how an app interacts with a database. So let's
Speaker 2: say you have an app that allows users to search
Speaker 2: for products in a database. An attacker could craft a
Speaker 2: malicious search query. Oh that, instead of returning search results,
Speaker 2: ends up deleting data from your database. Oh no, yeah,
Speaker 2: so it's a serious threat. Okay, the developers need to
Speaker 2: be aware.
Speaker 1: Of Okay, but are there ways to prevent it?
Speaker 2: Yes, thankfully there are using things like parameterized queries, which
Speaker 2: essentially separate the user input from the actual SEQL query itself.
Speaker 1: Okay, so it's like creating a barrier.
Speaker 2: Exactly, creating a barrier between the user's input and the
Speaker 2: sensitive part.
Speaker 1: Okay, gotcha, So input validation's sequel injection. Now what about
Speaker 1: intense spoofing.
Speaker 2: Woh, intense poofing sounds scary, it does?
Speaker 1: What is it?
Speaker 2: So? Intense spoofing is all about exploiting the way that
Speaker 2: Android apps can communicate with each other. Okay, So Android
Speaker 2: apps can send messages called intents to request actions or
Speaker 2: share information. An attacker can basically create a fake intent
Speaker 2: to trick an app into doing something it shouldn't.
Speaker 1: So it's like sending like a fake invitation to a party.
Speaker 2: Yes, exactly like that.
Speaker 1: Okay. So how can developers protect their apps against this?
Speaker 2: A couple of key things. One is to always use
Speaker 2: explicit intents whenever possible, okay, which means being very specific
Speaker 2: about which component should receive that intent. And the other
Speaker 2: one is to validate the data that's being received, make
Speaker 2: sure it's what you expect and that it hasn't been
Speaker 2: tampered with.
Speaker 1: Makes sense, all right? So I think we've covered a
Speaker 1: lot of ground here. We've talked about some foundational security concepts,
Speaker 1: how Android approaches security, and some of the most common vulnerabilities,
Speaker 1: the scary stuff. Yeah, but good to know, good to know.
Speaker 1: So I feel like we've built a pretty solid foundation here.
Speaker 2: We have. The walls are up, the doors are locked.
Speaker 1: All right, perfect, Now we need to think about protecting
Speaker 1: the data inside the house.
Speaker 2: Yes, that's next.
Speaker 1: So let's take a quick break and we'll be back
Speaker 1: to dive into the world of data privacy.
Speaker 2: Sounds good. So we've talked about building this secure house, right,
Speaker 2: thank you. Sure the walls are strong and the doors are.
Speaker 1: Locked, right, keeping those intruders out.
Speaker 2: Now, let's step inside and talk about protecting the valuables,
Speaker 2: those precious possessions. Data.
Speaker 1: Data privacy. It's such a hot topic these days, and
Speaker 1: for good reason. Users are trusting these apps with more
Speaker 1: and more of their personal information. Oh yeah, absolutely, So
Speaker 1: we really got to make sure we're treating it with care.
Speaker 2: Yeah, it's like being a bank. You need to make
Speaker 2: sure that you're keeping your customer's money safe.
Speaker 1: Right. So the book talks about all the different storage
Speaker 1: options available and Android. There's shared preferences, internal storage, external
Speaker 1: storage databases, so many ops. It's like a whole storage unit,
Speaker 1: it is, and you.
Speaker 2: Have to check the right storage unit for the right
Speaker 2: thing exactly.
Speaker 1: So let's start with shared preferences. I use this all
Speaker 1: the time for like user settings or app settings. Yeah,
Speaker 1: simple stuff. Are there any security risks with those?
Speaker 2: Well, Shared preferences are really convenient for those small bits
Speaker 2: of data. Yeah, but they're not the best choice for
Speaker 2: sensitive information because by default, the data that's stored and
Speaker 2: shared preferences is unencrypted, ah, which means it's basically visible
Speaker 2: to anyone who has access to the device.
Speaker 1: So, like, if I'm storing a user's password or apike
Speaker 1: shared preferences are out of the question.
Speaker 2: Definitely, you need a more secure storage option for that.
Speaker 1: Okay, So what about internal storage? Is that a step up?
Speaker 2: Internal storage is definitely more secure okay, because the data
Speaker 2: is stored in your app's private data directory Okay, and
Speaker 2: boxed and generally inaccessible to other apps. Gotcha, unless they
Speaker 2: have root access to the device.
Speaker 1: But what happens if an attacker gets root access?
Speaker 2: Well, if an attacker has root access, then it's basically
Speaker 2: game over. Oh no, they can access pretty much anything
Speaker 2: on the device.
Speaker 1: So even with internal storage, it's not a guarantee.
Speaker 2: Right, That's why we need encryption.
Speaker 1: Okay, So encryption is important no matter where we're storing it. Yes,
Speaker 1: what about external storage like an SD card?
Speaker 2: So external storage is typically used for data that's not
Speaker 2: specific to your app okay, so things like media files
Speaker 2: that you want users to be able to share. Yeah,
Speaker 2: but it's also the least secure option.
Speaker 1: Yeah, it seems like it because.
Speaker 2: Anyone can access it. So never store sensitive data on
Speaker 2: external storage makes sense?
Speaker 1: Now, what about databases?
Speaker 2: Databases are great for storing larger amounts of structured data, okay,
Speaker 2: and they offer a really good level of security, especially
Speaker 2: when you combine them with encryption.
Speaker 1: Always got to encrypt. So you keep mentioning encryption, Can
Speaker 1: you explain what it is and why it's so important?
Speaker 2: Yeah. So encryption is basically scrambling data into an unreadable
Speaker 2: format so that anyone who doesn't have the key to
Speaker 2: unscramble it just seems gibberish.
Speaker 1: So even if someone gets the data, it's useless without
Speaker 1: that key.
Speaker 2: Exactly.
Speaker 1: Okay, cool. Now you mentioned before there's like two types
Speaker 1: of encryption, symmetric and asymmetric. Yeah, can you break those down?
Speaker 2: Yeah. So symmetric encryption is like having one key that
Speaker 2: locks and unlocks the treasure chests. Okay, so anyone who
Speaker 2: has that key can access the data, gotcha. Asymmetric encryption
Speaker 2: is like having two keys, a public key and a
Speaker 2: private key.
Speaker 1: Okay.
Speaker 2: You use the public key to encrypt the data and
Speaker 2: the private key to DECRYPTI.
Speaker 1: Gotcha.
Speaker 2: So you can give anyone the public key, but only
Speaker 2: the person with the private key can actually see the data.
Speaker 1: It's like a super secret decoder ring exactly. But even
Speaker 1: with encryption, we still have to make sure those keys
Speaker 1: are safe.
Speaker 2: Right, absolutely. Key management is just as important as encryption itself.
Speaker 1: Okay, so what are some best practices for that.
Speaker 2: Ideally you want to avoid storing encryption keys directly on
Speaker 2: the device, Okay, If possible, you should send them to
Speaker 2: a secure server. So keep them somewhere else, Yeah, separate
Speaker 2: from the data.
Speaker 1: It makes sense. Well, what if, like sending the keys
Speaker 1: to a server isn't possible.
Speaker 2: Well, another option is to generate the key based on
Speaker 2: a password that the user has to enter each time
Speaker 2: they start the app. Okay, So the key is never
Speaker 2: actually stored anywhere permanently. Tatscha, but it's recreated each time.
Speaker 1: Interesting.
Speaker 2: Yeah, it's more secure, but it could be a little
Speaker 2: bit more inconvenient for the user.
Speaker 1: Right. It's always a balancing act, always a balancing act. Okay.
Speaker 1: So we've talked about protecting data at rest, Right now
Speaker 1: we got to think about protecting data when.
Speaker 2: It's moving around, data in transit.
Speaker 1: Yeah, exactly. And I think this is where HGTPS comes in.
Speaker 2: Yes, HGTTPS is our.
Speaker 1: Friend, right. I always see that little pad luck in
Speaker 1: the address bar. Yes, I feel like it makes me safe.
Speaker 2: It does. It means that the communication between your browser
Speaker 2: and the website is encrypted okay, So anyone who's trying
Speaker 2: to easdrop can't see what's being sent.
Speaker 1: So it's like sending a postcard versus sending a sealed letter,
Speaker 1: right exactly. So if I'm building an app that handles
Speaker 1: sensitive data, HTTPS is a must.
Speaker 2: It is absolutely essential.
Speaker 1: So I'm kind of curious, how does HTTPS actually work?
Speaker 1: What's going on behind the scenes.
Speaker 2: Well, HTTPS is actually a combination of the standard HTTP
Speaker 2: protocol okay and something called SSL or TLS.
Speaker 1: Okay, SSL, we talked about that before, right, like when
Speaker 1: we were talking about certificates.
Speaker 2: Yes, you write, SSL stands for Secure Sockets Layer okay,
Speaker 2: and TLS is Transport Layer Security okay, which is basically
Speaker 2: a newer, more secure version of SSL.
Speaker 1: Gotcha.
Speaker 2: But they both do essentially the same thing, which is
Speaker 2: to encrypt the communication between your app and a server.
Speaker 1: So they're like the bodyguards for our data.
Speaker 2: Yes, protecting it from those prying eyes.
Speaker 1: I like that. So when an app establishes an HTTPTS connection,
Speaker 1: what actually happens.
Speaker 2: There's a handshake process okay, where the app and the
Speaker 2: server agree on which encryption algorithms to use and they
Speaker 2: exchange keys.
Speaker 1: Okay, So it's like a secret meeting.
Speaker 2: Yeah, the secret means.
Speaker 1: To make sure they're on the same page, and once
Speaker 1: that connection is established, then all the data.
Speaker 2: Is encrypto exactly. It's like a secret tunnel.
Speaker 1: Okay. Cool. So we talked about certificates before, and I
Speaker 1: remember you mentioned a tool called key Tool. Yes, what
Speaker 1: is that and how does that play into this?
Speaker 2: So digital certificates are like electronic passports that verify the
Speaker 2: identity of a website or a server, and key tool
Speaker 2: is a tool that you can use to create your
Speaker 2: own self signed certificates.
Speaker 1: So like, if I'm a developer just getting started, I
Speaker 1: can create my own certificates to play with.
Speaker 2: Yes, exactly, and the book actually shows you how to
Speaker 2: do that. Awesome bo through the command line and through
Speaker 2: Android studio.
Speaker 1: Okay, handy, But even with HTTPS and certificates, things can
Speaker 1: still go wrong, right unfortunately?
Speaker 2: Yes, okay. Sometimes you might encounter a certificate that's self signed,
Speaker 2: or it was issued by a certificate authority that's not
Speaker 2: recognized by Android.
Speaker 1: So it's like having a passport from a country that
Speaker 1: Android doesn't trust.
Speaker 2: Exactly. Yeah, in those cases, you need to explicitly tell
Speaker 2: your app to trust that certificate. Oh okay, otherwise you'll
Speaker 2: get an error.
Speaker 1: So we have to be careful about which certificate.
Speaker 2: Sweet, it's very careful. Always double check and make sure
Speaker 2: you're handling them correctly.
Speaker 1: Awesome advice. Okay, so we've covered a lot today, data
Speaker 1: at rest, data in transit, lots of security.
Speaker 2: Measures, players upon layers.
Speaker 1: But we can't forget about one of the most important
Speaker 1: aspects of any secure system, which is authentication. Making sure
Speaker 1: we know who's at the door before we let them in.
Speaker 2: Yes, we've built the house, we've protected the valuables. Now
Speaker 2: we need to hire a good bouncer.
Speaker 1: Right, we'll be right back to talk all about authentication.
Speaker 1: Welcome back to the deep dive. We've talked about building
Speaker 1: a secure foundation, protecting data at rest and in transit,
Speaker 1: lots of layers. Now it's time to make sure we've
Speaker 1: got a.
Speaker 2: Strong front door authentication.
Speaker 1: Yes, so let's talk about some of the most common
Speaker 1: authentication methods out there.
Speaker 2: Right.
Speaker 1: The book starts with the classic, the tried and true username.
Speaker 2: And password, the old standby.
Speaker 1: But I feel like everyone knows this is not the
Speaker 1: most secure method.
Speaker 2: Yeah, it's definitely got its weaknesses. Passwords can be stolen,
Speaker 2: they could be guessed they could be cracked.
Speaker 1: People are not great at picking good passwords. So what
Speaker 1: are some alternatives that we can use.
Speaker 2: Well, one that's becoming increasingly popular is multi factor authentication
Speaker 2: or MFA.
Speaker 1: Oh yeah, MFA, I've heard of that.
Speaker 2: It adds an extra layer of security, okay, by requiring
Speaker 2: users to provide more than just their password.
Speaker 1: Okay, So it's like having two locks on the door exactly.
Speaker 2: Okay, So even if someone gets passed the first lock,
Speaker 2: they still need another key to get in.
Speaker 1: Gotcha. So MFA usually combines something the user knows, like
Speaker 1: a password, with something they have like a physical token
Speaker 1: or a code sent to their phone, right, or even
Speaker 1: something they are like a fingerprint or a face scan.
Speaker 2: Biometrics biometrics, Yeah, those again popular.
Speaker 1: Yeah, they're super convenient.
Speaker 2: They are convenient.
Speaker 1: But are there any downsides to using them?
Speaker 2: Yeah? There are some things to consider. For one thing,
Speaker 2: biometric data can be harder to change if it's compromised,
Speaker 2: that's true, And there are also privacy concerns about how
Speaker 2: that data is being collected.
Speaker 1: And stored, right, So always important to think about the
Speaker 1: trade offs. So the book actually walks through how to
Speaker 1: build a basic login system in Android. Okay, what are
Speaker 1: some key things developers should be thinking about when they're
Speaker 1: building something like that.
Speaker 2: Well, first and foremost, security has to be your top priority.
Speaker 1: Okay.
Speaker 2: Always use HTTPS to protect those credentials as they're being
Speaker 2: sent over the network, right, Never ever store passwords in
Speaker 2: plain text. Oh yeah, Always hash them using a strong
Speaker 2: hashing algorithm hashing.
Speaker 1: I remember we talked about that before. That's like a
Speaker 1: one way function, right exactly.
Speaker 2: You can't unscramble a hashed password, okay, So even if
Speaker 2: your database is compromise, the attacker can't actually see the passwords.
Speaker 1: Cool. Okay, And of course we already talked about MFA.
Speaker 1: That's always a good idea.
Speaker 2: Yeah, layers of security.
Speaker 1: Now, the book mentions something called account manager. What is that?
Speaker 2: So? Account manager is a class in Android okay that
Speaker 2: gives you access to the user accounts that are stored
Speaker 2: on the device. Okay, so things like Google accounts or
Speaker 2: accounts for other online services.
Speaker 1: It's like a central hub, gotcha, And you can use
Speaker 1: it to request authentication tokens you can, which is really cool.
Speaker 2: It is because it means the user doesn't have to
Speaker 2: enter their credentials over and over again. It just makes
Speaker 2: it smoother, much smoother.
Speaker 1: Okay. Cool, All right, so we've talked about authentication. Yeah,
Speaker 1: now let's move on to what I think is one
Speaker 1: of the most important parts of building secure software.
Speaker 2: Oh, I know what's coming.
Speaker 1: Testing.
Speaker 2: We have to test.
Speaker 1: We have to it's so important, it is. So the
Speaker 1: book talks about different types of testing unit testing. Yeah,
Speaker 1: let's start with UI testing. Why is that so important
Speaker 1: for security?
Speaker 2: Well? UI testing focuses on how a user interacts with
Speaker 2: the app's interface. Remember we were talking about those input
Speaker 2: validation vulnerabilities. UI testing can help.
Speaker 1: Us catch those, okay, So we can simulate a real
Speaker 1: user trying to break the app exactly and see if
Speaker 1: our input validation is actually working.
Speaker 2: Yes, And Android provides this great framework called UI Automator okay
Speaker 2: for creating automated UI tests.
Speaker 1: Cool, so we don't have to do it manually.
Speaker 2: Well, you can do it manually, but it's much easier
Speaker 2: to automate it. And there's also this cool tool called
Speaker 2: UI Automator Viewer okay, which lets you inspect the hierarchy
Speaker 2: of your.
Speaker 1: App's UI so we can see what's going on.
Speaker 2: Yeah, you can see all the different elements and how
Speaker 2: they're laid out.
Speaker 1: Okay, very cool. Now what about unit testing? How is
Speaker 1: that different?
Speaker 2: So unit testing is about testing individual components of your
Speaker 2: code in isolation. Okay, So you're not testing the whole
Speaker 2: app at once. Okay, you're testing each little piece.
Speaker 1: Gotcha? And Android uses j unit for.
Speaker 2: This, yes, Jane. It is the standard framework for unit
Speaker 2: testing in Java.
Speaker 1: Okay. But does Android have any like special tools or
Speaker 1: classes to help with that.
Speaker 2: It does. It has a bunch of classes and methods
Speaker 2: specifically for testing Android components. Cool, like activities and services.
Speaker 1: Oh, very cool. And you mentioned instrumentation before. What's that
Speaker 1: all about?
Speaker 2: So instrumentation is this really powerful mechanism that lets your
Speaker 2: test code interact with the app's life cycle. Okay, So
Speaker 2: you can start and stop activities, send simulated user inputs.
Speaker 1: So you have a lot of control. You have a
Speaker 1: lot of control, okay, awesome, And then j unit provides
Speaker 1: those assertions yes, to make sure that the app is doing.
Speaker 2: What we expect exactly.
Speaker 1: Now, the book also talks about mock objects. What are those?
Speaker 2: So mock objects are simulated versions of real objects Okay
Speaker 2: that your code might depend on. Okay, So, for example,
Speaker 2: if your code interacts with a database. You can create
Speaker 2: a mock database RCHA so that your tests don't actually
Speaker 2: have to connect to a real database. Makes sense, which
Speaker 2: makes your tests run much faster and more reliably.
Speaker 1: Right, because we don't want our tests to be dependent
Speaker 1: on like the network or something exactly.
Speaker 2: And there are some great libraries for creating mock objects.
Speaker 1: Cool like Machito.
Speaker 2: Machio's a popular one.
Speaker 1: Yeah, I've heard of that one. So we've got all
Speaker 1: these great tools and techniques for testing we do, but
Speaker 1: how do we actually run the tests?
Speaker 2: Well, Android Studio has a built in test runner Okay,
Speaker 2: that makes it super easy to run your tests and
Speaker 2: see the results.
Speaker 1: And it works with jone it.
Speaker 2: Yes, it integrates seamlessly with June It awesome.
Speaker 1: All right, So it seems like androids Studio has everything
Speaker 1: we need.
Speaker 2: It does, And there are also a bunch of external
Speaker 2: tools that you can use if you want.
Speaker 1: Oh yeah, the book mentions like spoon and robo Electric.
Speaker 2: Yeah, those are great for running your tests across multiple
Speaker 2: devices or on your computer without needing an emulator.
Speaker 1: Very cool. And then there's Monkey.
Speaker 2: Oh. Monkey Monkey is so much fun.
Speaker 1: It throws chaos at the app.
Speaker 2: It does It basically just simulates random user interactions seas
Speaker 2: if it breaks and seas if it breaks.
Speaker 1: That's awesome. Wow, this has been quite a deep dive
Speaker 1: has into the world of Android app security. We've talked
Speaker 1: about so much, so much, building a secure foundation, protecting data,
Speaker 1: secure communication, authentication, and of course testing everything. I feel
Speaker 1: like I've learned so much.
Speaker 2: Me too, And the biggest takeaway for me is that
Speaker 2: security is a journey, not a destination.
Speaker 1: That's a good way to put it.
Speaker 2: It's something you have to be thinking about constantly.
Speaker 1: Yeah, and always staying up to date with the latest threats. Awesome. Well,
Speaker 1: if anyone wants to learn more about the stuff we've
Speaker 1: talked about today, yeah, the book we've been using, Testing
Speaker 1: and Securing Android Studio Applications is a great resource.
Speaker 2: It is, and there's also a ton of information online
Speaker 2: and a really active Android developer community.
Speaker 1: So many resources. Awesome. Well, thanks for joining me on
Speaker 1: this deep dive.
Speaker 2: This was fun.
Speaker 1: I had a great time. Until next time, Happy coding everyone,