Transcription
[Music]
Hey phone, hey! Could you do the, the, the thing that you know? Can you help me out, you know, dude? No, dang! You are a renegade phone. I will never be tamed. Ah, if only I had a way to control you without the need of these, these wretched thumbs, 'cause these broken thumbs... wait a minute! What's that? No, don't look at that. That's nothing. But it looks like it might help. No, it's too complicated. Leave it alone! I control you! I control you! No, phone, I control you!
In this video, we're going to learn lots about the incredibly useful software that lets you use your computer to control your Android phone in a huge variety of brilliant ways. Let's do this!
[Music]
Hi folks, my name is, my name is Ben, and welcome back to the channel. As always, if you enjoy what I do on this channel, don't forget to hit that subscribe button. And of course, if you like this video, don't forget to give that thumbs up icon a little tickle.
So, ADB. It stands for Android Debug Bridge. It's a piece of software that's often installed alongside of the Android SDK. However, one very important note straight away is that you can actually install ADB independently of the SDK and Android Studio. In case you do want to install it on its own, I'll put some links in the description down below to help you do just that.
In the simplest of terms, ADB lets your Android phone and your computer communicate to one another. Said communication can be transferring files, issuing of commands, and even controlling user input. ADB is an entirely underrated piece of software. There is so much that ADB can do to help you as an Android device owner, and it is entirely massive. So, I'm not going to be able to cover all of the commands here, but I'm going to show you a load of them, and hopefully, some really useful ones that you can take away and use for yourself.
So, let's jump over to my screen and let me try and show you as many of these awesome ADB commands as I possibly can. Just to point out, on my screen, of course, I have my terminal here on the left, and on the right, I have an Android phone emulator. Everything that I show you in this video will 100% work on a real physical Android device. I'm just using an emulator to make it easy to present.
To start with, I'm going to assume that you've managed to install ADB either via installing Android Studio or with those links that I posted in the description where you can install it independently. One thing that you might still need to do after you've installed it is make sure your system knows where ADB, the software, lives on your computer. And you can do that by adding the absolute path of ADB to your PATH environment variable. What do I mean? Let me just make it really clear and easy.
If I open up my bash profile, you can see on line 10, I think it is, or here, line 12, I've added this line. I've added to my PATH variable, my PATH environment variable, the absolute location of ADB. So, ADB on my system lives in the Android folder, in the SDK folder, in the platform-tools folder, and inside of there is where the software ADB lives. I've added it to my PATH variable now, so all I need to do to call ADB is simply type `adb` and hit enter, and it knows what I'm on about, where to find it.
If you don't add that PATH variable and it's not working, just try calling ADB with the absolute path. You know, so users, Android SDK, platform-tools, and so on, and see if that works. And if that does work, then change your PATH variable to make it easier for future use. If that has confused the hell out of you, please don't worry. I'll put some links in the description down below to help you understand why changing your PATH variable to include ADB's location is important.
So, let's start using ADB. The very first command is `adb devices`. And this is a command that when run, tells me what devices I have plugged into my machine that ADB is aware of and can deal with. And actually, this conveniently brings me onto a very important point. When using ADB, you can see a list of devices here, emulator, and it's got "offline" written. Offline means that it's not online. I can't do things with it. I can't run ADB commands against it. You can see a device is offline. How do we change that?
This is something where Developer Settings comes into play on the device. We need to be a developer on our Android phone or tablet in order to make this ADB and phone sort of communication work. But it couldn't be simpler. Let me show you how to do it on the device. On the side here, I'm going to pull up my apps. I'm going to go to the Settings app. Okay. I'm going to scroll right to the bottom, and it might be different on your phone depending on what version of the OS you have, but for me, and for everyone, you need to find something called Build Number. And for me, the Build Number exists in this "About emulated device." I scroll down a little bit, and you can see "Build Number."
And this is really weird, but once you've done it, you've done it once, you don't need to do it again. I'm going to mash clicking, tapping that Build Number, and look what happens. I'm going to mash it, and you can see it says, "Oh, you are X steps away from being a developer." I'm just going to keep mashing it until it says, "Now you are a developer." Huzzah!
Now that I'm a developer on this phone, I can tweak certain settings in order to make life as an Android developer simpler, and also enable this sort of Android Debug Bridge communication to work, and let me get the full feature set out of it. And the way that I do that, again, is in the Settings app. But this time, now that I'm already a developer, inside of the System tab, for me, it might be different. Um, you'll see underneath "Advanced," "Developer options." And it might not be in the same place as where mine is on this device. But if you use the search utility in the Settings app, you'll find it. Just look for "Developer options." It's always called "Developer options."
Now, this actually wasn't here before. If I just turn this off, right, and go back, see, it's disappeared. So, before I did that whole Build Number mashing thing, it wasn't available to me. So, if I go back to "About emulated device," scroll down to the bottom, mash, mash, from smash, smash, and again, I'm a developer. And I go back to System, and in the Advanced settings, there it is again.
Now, if I go back to the terminal and just do `adb devices` once again, you can see it's still offline. I haven't triggered the important bit. I still can't do, um, I'll show you this command a little bit later, but I still can't do ADB, um, commands against it properly. There's still one last little bit I need to do in here. Underneath the Developer settings, I need to scroll down to where it says "USB debugging." USB debugging, okay? So, debug mode when I'm connected with USB, okay? It basically just means that I can now start doing things to this device. I can enable this communication. If you tick this, so USB debugging is enabled. Obviously, Android developers, this is absolutely huge. You can actually do, you know, debugging when you're coding your app. But this also allows ADB to work.
Now, the ADB debugging, sorry, USB debugging is on. I'll go back over here. `adb devices`. Hit enter. And now you can see, instead of "offline," it says "device." Now, this means that this is ready to be used by ADB. I can start doing lots of ADB stuff to it. And now we're going to get into the real meat of the video.
Again, that first command was `adb devices`, and it lists all of the devices that are plugged into your phone. And now, now we know the sort of status of their ADB eligibility. If you have more than one device plugged in, you'll see a list here line by line. And you can also do `adb devices -l` for the long version to find out more information about said device.
One incredibly important note is if you have multiple devices plugged into your machine and you see multiple devices in this list, you cannot just fire generic ADB commands to them because the computer won't know which device it was intended for. So, if you do have multiple devices in, you always have to sort of append, sort of, I'll show you what I mean, um, the device ID to the ADB command before you trigger it. Let me show you what I mean. So, normally I would do like `adb shell`. We'll cover that command in a second, and I can shell into that device. But if we had multiple phones attached, it wouldn't know which one it was intended for. So, I need to do is after ADB, and you can take this rule for every ADB command we see, it always starts with ADB. If you have multiple phones, you do `-s` and then the identification, um, string that is in that `adb devices`, um, return. So, I've done `adb -s emulator-5554` and then the command that I want to trigger against it. If I hit that, of course, it works again. But this would work now if I had multiple devices plugged in. I'm telling ADB which device specifically I'm working with.
Next up, if you do `adb shell getprop`, and this command followed by a string that we'll see in a second, will get properties of the phone and display it right back to you. And there is a huge list of properties. In fact, if I don't give it a property and just hit enter with that, it lists me all of the properties about that phone for me to digest or look at. However, if I clear my screen and I want to be more specific, I do `getprop ro.build.version.release`. Let's do this one. This will give me the Android operating system version number. So, this emulator is running, running Android OS 11. Cool. Might be useful.
If I get rid of the release and do `sdk`, this one's saying, "Oh yeah, we're using SDK 30 on this emulator." Nice. Awesome. Again, you can use, you can use just `getprop` without the string to see all of the variables and figure out which ones you're actually interested in.
So, we just saw that you can do `adb shell getprop`. We can actually just do `adb shell` as well. And what on earth has that done? That's given me a shell inside of the phone. So, I'm on my computer here, but I'm actually now, with this shell, I'm inside of the device. Just to the right, so you can see, if I do `whoami`, I am `shell`. And if I just exit this current shell and I do `whoami` back on my normal terminal, I'm `biked`. Okay. So, if I do `adb shell`, I'm inside of the phone here, and I can do a bunch of the usual sort of Unix commands. `ls` to print out, um, some of the files and folders, `cd` to move directories around and move into different locations. And you can see, if you're an Android user, you might recognize some of these folders here. I've just gone into the `sdcard` folder, and you can see I've got, um, the `DCIM` folder, which is for where the phone stores, like, camera photos. Which is incredible. You have a shell to sort of connect to, sort of SSH, if you like to think of it like that. You can SSH into the phone, into your phone on your desk, or in this case, the emulator here on the screen. If you're a terminal user, then I can imagine your eyes widening at this, because this just means that you've got access to all of the power that you usually do. It's just really important to note that if your phone isn't rooted, then a lot of the things will be locked down, like, sort of hidden behind permissions, and you won't be able to do all of the things that you usually would do.
Let me just give you a quick example of some of the power that we have with this shell. If I open up on the device, this, uh, Files, Files and Folders program here, and you can see, um, I'm inside of the fold, the phone's files and folders. Um, if I just print out here, um, the files and folders, you can see they're the same. I'm in the same location here on this device. If I do now `touch temp.txt`, bang! Immediately on the right, you could see a file has just been created called `temp.txt` on the device itself. Again, this works even if it's not an emulator.
Right now, I'm going to just put something into that temp file. And then put "hello." I'm going to put "hello" into that temp file. So, into `temp.txt`. So, I've put the word "hello" into that file. I'm just going to `cat` here `temp.txt` to prove "hello" is in there. And over on the phone, you can see it's now not zero bits of data, there's something in it. If I double-click on this and it opens up the HTML viewer, you can see the word "hello" just in that file. That's cool. That's powerful. I can make files. And that's cool. And I'll let your own imaginations and your own searchings of the internet see what is possible with this ADB shell. But let me move on to the, the next bit.
Let me segue nicely onto this next bit, sort of transferring of files between your computer and your phone. I've actually made a video before about ADB's file transferring abilities that we'll cover right now, just in case you're interested in seeing more about that. So, let me show you how you can put a file onto the phone, super easy. Okay. In this folder, I currently have nothing. I'm going to make a file called `temp_dell.txt`. I'm going to put in another "hello" and save it. And now I have the, uh, file `temp.`, uh, `temp_dell`. I wanna now put it on the phone. It's not on the phone currently. I'm going to push it to the phone. Okay. So, we use the `adb push` command. So, push is to push it onto the phone, pull is to take it from the phone. Okay. `adb push temp_dell` and then where I want it to go. Now, in most cases, you'll do `/sdcard` and just put it in that folder, and that'll be the sort of, the main folder that you can actually, um, add files and delete files from and edit files as well. So, most of the time, you'll put it in there. So, if I do `adb push` and hit enter, you can see on the right, the phone updated. It's got `temp_dell.txt`. If I open that up, another "hello." Lovely.
Now, let's do the opposite way around. Okay. In this folder on my computer, I'm going to delete `temp_dell` the file. So, it's gone. Let me just prove it's not there. And now I'm going to take down from the phone that `temp_dell` file that we just uploaded to it. We're gonna use the pull command. `adb pull` and then I need to know whereabouts it is on the phone, of course. If you don't know where it is, you can use `adb shell` to go into the phone, look around, and then come out of it. And of course, I know where it is. So, `adb pull /sdcard/temp_dell.txt` and the next argument is where I want it to be pulled to. I'm just going to use the dot annotation, which literally means here, in this folder that I'm in right now, called temp. Sorry, there's a lot of temp in this video. So, pull it into this folder. Enter. One file pulled. Hazard. Lovely. Okay. And if I just `ls` here, `tempdel` is back. I'm going to `cat tempdel`, and of course, there is the file with all of its contents.
Next, let's talk about how you can get screenshots of your phone and record the screen as well, all from the terminal. First of all, screenshots. To do this, it's `adb exec-out`. So, this literally means execute the command I'm about to give you and sort of give me the output back. Really useful. The command we're going to use is `screencap`. `screencap`, obviously, screen capture, screenshot, take a screenshot of the phone. We're going to use the `-p` tag, so `-p`, which outputs into the PNG format, really nice for pictures. And then we're going to take all of that, and we're going to force it to be in a file on my computer. So, we're going to use `>` to sort of say, "Hey, take all of that and jam it into this file that I'm about to tell you about." And I'm just going to put it in this folder. So, `./` and I'm going to call it `pic.png`. Terrible name, do better names, but this is fine for an example. Hit enter. It doesn't look like it's done much, but it's taken a screenshot. So, if I open up this folder here, `open .`, you can see there's a file called `pic.png`. If I open that up, you can see, compare it to the, the image on the right, it's taking a perfect screenshot of my phone, in, in, you know, sort of instantly, in seconds. Nice. Really useful.
Next up is screen recording. Actually, sort of recording the interactions and the user flow of the device, which is really powerful. This one's a little bit peculiar. You need to sort of trigger the screen record, and then once it's done, you need to use the pull command to actually take the file from the phone. But let me show you how it's super easy. First of all, let's get the screen record. `adb shell screenrecord` is the command. `screenrecord`, okay? We need to give it an argument of, uh, the file name that it should stick all of this sort of, um, screen recording into. And this is a file on the device. So, it's always my recommendation when you're dealing with files on the device to always put them in the `/sdcard` folder because you've got the most permissions there, you can read and write to, etc. But after that, you can call it whatever you like. So, I'll do `/sdcard/` and we'll call it `vidfile.mp4`. Great. Okay.
So, if I hit enter now, you can see the shell hasn't returned because the command's still working, it's still doing something. So, let me go over to the phone. Let me drag around a bit. Let me, in fact, close out of that. Let me go to, uh, I don't know, so this other, the example app that we'll talk about in a second. Click around with that, um, and done. And when I'm done with the recording on my computer, back here, I'll hit `Ctrl+C`, you know, to sort of kill the command, end the command. Nice. `Ctrl+C` kills the command. What we can first of all do to verify it is just go back to that, um, folder view that we had before, and you can see right at the bottom of the folder view, we have this `vidfile.mp4`. That is our screen recording. So, like we did with the pull command previously, we can just take that file from the phone. `adb pull` the file that I'm interested in, `/sdcard/vidfile.mp4`, and where I want it to go, dot, for this folder, I wanted to go right here. Okay. And bang, pretty rapidly, it's done. One file pulled. Again, if I open this folder to see the contents, you can see `vidfile.mp4`. And if I open that up, and we just gently watch it, a video in a video, uh, has it started playing? It has started playing. You can see, okay, eventually it kicks in, moves around a little bit, closes that app, opens up another app, and there we go. I've made a screen recording from my terminal of the device. Again, doesn't need to be an emulator, it can be a device sat on my desk, as long as it's plugged in.
Okay, the next bit is one of my favorite bits of ADB. You can fake user input. So, if you wanted to sort of recreate screen taps, you can do exactly that. If you wanted to recreate people typing in your, in the, in the app or on the phone, you can do exactly that. Let me quickly give you a rough example so you know what I'm talking about. Here we go. `adb shell input`. Input is our power, power word, our command for the moment. Input, and this is going to say now, we're going to do something where we're inputting to the device. We can do a bunch of things. We can do text, we can do taps. I'll show you a couple more examples in a second. So, we're going to use the `tap` command to recreate a press, a finger press on the screen. And we can give it an X and a Y, the coordinates on the screen that we want to sort of do our pressing. So, I'm going to plug in some coordinates that I've already got, and I'll show you how you can get these coordinates in a second, in a really easy way. But X 538 and Y 1099. And my objective is to click this button in the center of my screen without touching the phone or the emulator. If I hit enter now, you can see the button was pressed and has taken me to my next screen for the example. Nice.
The problem with that is actually, how do we know what the coordinates are on our screen? It's really weird. You could just do like 100, 100 and see if it hit or not, and then try 200, 200. That's rubbish. Let me show you a super-powered way of getting your coordinates for anything on your screen. If you go back to the Developer Settings on your phone, uh, so Settings, the Developer Options that were at before, for me, they're here in Advanced. And you go down to, there's a little section called "Input." And this will, this will be awesome. This saved me so much time. Input. There's two things. There's "Show taps," so I can show literally, you can see there's like a little pointer, which is cool and useful. But I want this other one, "Pointer location." And if I hit "Pointer location," you can see at the top, this like X and Y bar, this tiny little bar's come in. And whenever I press and hold with my finger, technically it draws a little line on the screen. But the most important bit, and it's really hard to see, I'll try and zoom in with the video, is that my current held-down location, the X and Y coordinates are right in the top left. Okay. But this is how we can get coordinates of our UI elements that we want to sort of plug into the tapping thing. So, for example, here, if I click, press my, press and hold my finger down, move the cursor over this, uh, button that I want to press, you can see in the top left the coordinates. Great.
So, if I go in here and I do a tap 525 space 1100. So, now I've sort of found out on the phone where that button is in terms of an X and Y, or where at least I should press on it. And now if I hit enter, you can see I've done the same thing.
We haven't, of course, just got taps. We've got user input like typing text, and we've got user input like hitting sort of phone buttons like the home button or the power button. We can do all that as well. Let me show you. We're going to use `adb shell input` and instead of `tap`, this time we're going to put `text`. To give it a bunch of text, I'm gonna do, um, "Hello" with a capital H. I'm gonna give it the text "type in for me." And I'm gonna hit enter. And look at the phone. It really quickly wrote "Hello," the text I wanted.
And as I said, we can give it certain like button presses on the phone that aren't sort of like accessible to us. In this case, I want to hit the back button to get rid of that keyboard. The soft keyboard. And what I'll do is I'll do `adb shell input keyevent`. And there is a huge, huge list of key events, different key events for you. There's, in fact, each individual letter if you want it to go sort of that low. But there's different key events, for example, 3 is the home button, 4 is the back button. I'll put a link in the description down below for the entire list of key events so you can look for them yourself and find the ones that you want to use. In this case, key event 4, back button, please. Hit enter. And the keyboard drops away because I hit that back button. But I didn't really hit it, I'll let the computer do it for me.
And by using and combining all of these different ADB inputs, the taps, the text, the, the button presses, you can create, uh, automated user input flows. For example, the place I've just started working, our app requires a user to log in. So, what I've done, I've written a script that clicks on the button that says "Login," types in the user, the address, the email address, types in the user password, and then hits on the screen the login button. So, instead of me having to pick up the phone every time that I make a new build and type it all in, boring, boring, boring, I'm too lazy. Instead, I hit a button, I just trigger a text, I trigger a script on my computer that says "Login," and it does it all for me in split seconds.
The final few commands that I want to show you in this video are definitely tailored towards helping Android developers develop. Let's start with something really simple. You can use `adb shell pm`. So, `pm` is Package Manager, the package manager on the device itself. And what we can do is `list packages`. And what this will do, if you haven't already guessed it, is list out all of the packages, all of the apps that are installed on this device. Of course, if you're a terminal user, a scripter, you can `grep` things out and find certain things. So, for example, in this case, I'll pipe it into `grep` and I want to look for this app. This app has the package name `bk.yt.example`. So, if I want to, I want to `grep bk` just to start with. Hit enter. And you can see, oh yes, my package is installed on the device.
Another thing that's a little bit complicated in Android development is finding out what information has your app actually stored on the device locally. But this is really easy using ADB. We can first of all `adb shell` to shell into the device. So, I'm inside the emulator again now. And once I'm inside the device, I'm shelled in, there is a powerful command called `run-as`. Okay? So, this is saying, "Run now as this certain app, this certain package." So, if I do `run-as yt`, sorry, it was `bk.yt.example`. I want to run as this package. Watch what happens. Hit enter. It's changed my folder location, right? It's, it's changed it to `data/user/`. This is now the location on the device where my app stores stuff, databases, shared preferences, all that kind of stuff. I'm in that folder now. Normally, as the shelled, sheldon user, or a normal user on the device, you wouldn't have permission to look in there. But I'm saying, "Run as this app, run as this package, pretend I'm in this package." Having a look around. And if I just clear the screen to make it a little bit easier, `ls`. You can see there's a couple of things. And there's one that I want to point out, which is huge: `shared_prefs`.
For those of you that aren't an Android developer, shared preferences is a way that Android developers can store little tiny nuggets of information on the phone for calling back later, or just saving things like user email address so you don't have to retype that in every time you open the app. It's already there, it's already populated. This is really powerful. I can `cd` into that `shared_prefs` folder. And just as a heads up, this temporary app that I've made has stored something in shared preferences. Let's find out what that was. If I just `ls` the files inside of the `shared_prefs` folder, there's `test.xml`. And this is how Android stores shared preferences. If I just `cat` out the contents of `test.xml`, so I'm going to `cat` it out, you can see the contents of the shared preferences. That is huge for an Android developer. There's no more guessing, there's no more sort of like debugging. You can go straight into the phone and say, "What is the shared preference value?"
And finally, the last awesome command I want to tell you about is the one that I use every single day when I do Android development, and that is `dumpsys`. Let me show you what I'm talking about. Often when we're doing Android development, we want to know, um, maybe the layout hierarchy, or what fragments and activities are involved. You know, we can sort of see them, sure, we can see the layouts, we can see the UI, but we don't really know what's going on behind the scenes. Let me show you `dumpsys`. If we do `adb shell dumpsys`, all one word, um, and what we can do now is append a sort of mode, if you like. `adb shell dumpsys` has a load of different sort of variations that you can do. I'm not going to go into them all here. I'll put a link in the description if you want to look at them in your own time. But the one that I always use is `activity`. So, `activity`. And what this is going to give me is a bunch of information about my application when I, when I'm more specific. So, if I did that right now, it tells me about a whole bunch of stuff. And again, it's not particularly filtered, not easy to read. What I want to do instead is the same command, but I want to append my package name to say, "Tell me, tell me more about my app, what's going on with my application's stack?" Okay? So, I'm going to do my package name again, `bk.yt.example`. Okay? And all I'm going to do now is the same thing. Hit enter. This is again, quite chaotic output. But what I'm going to do is take that and pipe it into `vim` just so we can move around it and enjoy it a little bit easier.
This is a huge amount of output, and a lot of it is really, really useful. It may be a little bit difficult to read and digest, but let's see what we can pick out of it. If I just jump to the bottom, what we can see is "Added fragments: SampleTwoFragment." As the developer, I know that this screen that we're looking at now is called "SampleTwoFragment." Okay? So, um, that's cool. If I just go on the phone, get rid of that, and I'm now not in "SampleTwoFragment." If I just quit this and re-run it again, put it into `vim`, if I jump to the bottom now, we can see, "Oh, added fragment is just SampleFragment now." So, all I'm trying to show you is that you can see what's going on behind the scenes. And one of the really powerful features, other than sort of the fragment stack, there is a lot to read here. I'm going to show you something that'll make it way easier in just a second. You can see "child fragment managers." So, as a fragment got children fragments? Really useful. And what their stack is, and in what state they're in as well. So, you can see this is an active fragment here. You can see on this line, um, "SampleFragment" is the active fragment. That's really useful. And what state it's actually in, is it, is it created, is it paused, is it stopped, etcetera. One of the really powerful things is the view hierarchy here. This, this chaotic mess here, um, shows us that what view components are in there. So, here you can see that I've got a TextView and a Button, and I have on the screen a TextView and a Button. Really, really powerful stuff. This `dumpsys` gives you loads of information.
Now, this is difficult to read. I'm not going to lie, this is chaotic to read. There is a lot, and it is hard to digest. And this is where I sort of plug myself and something that I've done myself a little bit. So, apologies about this, but this tool, hopefully, will help you understand your activity and application and fragment stack really quickly and easily. You could do that, you could understand the activity and fragment stack by running `dumpsys`, okay? But digesting all that information is difficult. I've written a program called Easy Dumpsys. And I'll just drag this onto the screen here. Is the GitHub repo for Easy Dumpsys. So, as it says on the tin, it's `dumpsys`, but it's easy to understand. And it basically, here in this image, it takes all of that output, that chaotic, difficult to read output, and turns it into something beautiful.
If I just show you what Easy Dumpsys looks like, so you can remember the chaotic output of, you know, all of that from just `dumpsys`, the normal `dumpsys`. If I do `easy-dumpsys` and I give it the package name I'm interested in. In fact, let me show you one one better. If I don't give it the package name I'm interested in, it will open up with a fuzzy finder, FZF, and ask you which package are you interested in. And if you have loads of them on the emulator, there's not loads. If you have loads of them, you'll see them all here. Um, I want to check out `bk.yt`. If I hit enter, bang! All of that chaotic input up here now is transported and translated into this. So, we have these, uh, these fragments here, and we have "SampleFragmentOne," "SampleFragmentTwo." If I just hit the back button to get rid of "SampleFragmentTwo," rerun Easy Dumpsys, I want to give it the package that I'm interested in. Um, and actually, you don't need to put in the whole package name, just enough for it to be unique. So, `bk.yt`. And there it is. Bang. Beautiful. The stack, really easy to understand. You know, the activity, and is it the active one? Because there's obviously multiple activities sometimes, and the fragments, and they're sort of, their hierarchy, that order, you know?
So, just to be clear, `dumpsys` is an incredibly powerful tool. I recommend using it. But when the time comes and you need to quickly digest and understand that, in order to understand your fragment stack and your activity stack, try maybe Easy Dumpsys. And again, I'll put a link to the GitHub repo down below, and there's instructions on how you can install that onto your system for yourself.
And that is it. There is so much more, maybe hours more worth of content that we could cover about ADB and some of the more, um, peculiar commands and the lesser-known commands. Hopefully, this gave you a flavor and showed you the absolute power that ADB can give you with your device, with your emulator, with whatever, and lets you fully control it from your computer. And that's it. As usual, thank you so much for watching. Of course, if you haven't already subscribed to the channel, consider subscribing. And maybe hit that bell icon as well to be notified about when I release new videos. Of course, if you have any questions about this video, ADB, or anything else I cover on my channel, please reach out to me at my Twitter handle, @Ben_Cadell. Thank you so much for watching. See you next time.
No, don't just let the door bounce open. Okay, maybe it's good with the hand in it. These broken thumbs. Wow. Something like that. What do I do? Because these are, yeah, that's it. Buy it. It is a piece. It is a piece of software. It is a piece of software that lets your computer. Here's another really useful command. If you do `adb`... it's off my phone. What's next? What's next? What's next? Watching the phone. Hit enter. Wrong coordinates. Is it this one? We're almost there. Come on, keep moving, keep moving. And it sort of dumps us. No, not sort of, we.