Using adb (Android Debug Bridge)

Connect your phone to your PC with a USB cable, enable USB debugging on your phone, and install and run adb on your PC. Then you can type commands on your PC and do low-level things to your phone or on your phone.

Installing adb:
Doug Lynch's "How to Install ADB on Windows, macOS, and Linux"

  1. Install ADB on computer.
  2. Enable USB debugging on phone.
  3. Connect via USB cable.
  4. adb devices
    You should see just one device listed.
  5. If "adb -d devices" lists device as unauthorized, unplug USB cable, go to Settings / Developer options / Revoke all authorizations, plug USB cable in, should see "authorize this device ?", click OK, try "adb -d devices" again.

Adb also can connect via Wi-Fi or other TCP/IP, and can connect to an emulator instead of a real phone:
Android Developers' "Android Debug Bridge (adb)"

Using adb:
adb devices
adb -d devices

adb shell uname -a
adb shell ls -R /
adb shell cmd statusbar expand-settings
adb shell service call statusbar 1
adb shell top		# ctrl+C to exit
adb shell dumpsys -l
adb shell netstat -l -p
adb shell settings -h
adb shell settings list global >globalBackup.txt
adb shell			# "exit" to exit

adb bugreport >bugreport.txt

adb shell pm -h
adb shell pm list packages
adb shell pm list packages | grep google
adb shell pm list packages -f

adb shell pm uninstall PACKAGENAME
adb shell am start -a android.intent.action.DELETE -d package:PACKAGENAME

adb shell pm list permissions
adb shell pm list permissions -g -d
adb shell pm revoke PACKAGENAME android.permission.CAMERA

# copy an APK from phone to PC:
adb shell pm path PACKAGENAME		# to get PATHNAME
adb pull PATHNAME

adb logcat | grep "$(adb shell ps | grep PACKAGENAME | awk '{print $2}')"

# run adb and do logcat and color the output
# download and put it somewhere in your PATH, then:
ADB Shell
RMG's "30+ Most Used ADB & FastBoot Commands for Android 2019"
/u/perennialExhaustion's "Taking (almost) full control of your unrooted Android"

Unlocking Carrier

Some phones will be restricted to using only one telecomm company (carrier). To change that, you "jailbreak" (usually on Apple) or "unlock" or "SIM unlock" (usually on Android) the phone.

Wikipedia's "SIM lock"

Unlocking Bootloader


Normally, the user and apps will have restricted access to the filesystem, preventing changes to various system files and settings. To get full, super-user access to the filesytem, you have to "root" the phone (which mainly involves installing the Unix SU program and using it to set everything to run with super-user permission). But if you leave it running in that state, any malware application would have full access to all data and settings. And some applications will refuse to run on a rooted system, especially because it may allow you to subvert payment requirements or region restrictions (this may be called "failing SafetyNet" ?).

Easy way to root the phone, but it installs lots of bloatware: Kingo Android Root

Whitson Gordon's "Everything You Need to Know About Rooting Your Android Phone"
Wikipedia's "Rooting (Android OS)"
Guiding Tech's "7 Tips to Secure Your Rooted Android Device"

After Rooting

Whitson Gordon's "Top 10 Reasons to Root Your Android Phone"
Brendan Hesse's "How to Customize Your Android Device With Magisk and Xposed Framework"
Nick Congleton's "How to Install Android Add-ons From Magisk Manager"

Robert Zak's "How to Install Apps on Android without Google Play Store"
MakeTechEasier's "9 of the Best Android Apps Not on the Google Play Store"

Android Custom ROMs

From /u/trondwin on reddit's /r/LineageOS 8/2018:

Painful Lineage OS installation:

I bought a used LG G3 d855 to install Lineage OS on and use as my (only) phone. The installation instructions (at for the phone seemed (reasonably) straightforward, even for a novice user like myself, so I thought this would be a fun, little project. However I ended up using 20-30 hours (over multiple weeks) in total.

This is not meant as a complaint - on the contrary, I am full of gratitude to all developers creating open source software - You're making the world a better place. Rather, by describing the efforts I went through, I hope others may learn something from them and get an easier time than I had.

Here are the main painpoints and time sinks I encountered. Ultimately, the instructions at the lineage os wiki were not particularly helpful. Specifically, they're somewhat misleading in that they make no provision at all for differences in Android versions. I found no other web site with a complete AND working tutorial, either - I had to research each specific problem as it occurred.

The good news - it DID work out in the end. It was actually doable, and I believe it will be for other phones and android versions as well.

I'd like to end with a thank you to all developers using their time to develop free and open source software. Thank you!


Application components:
Application manifest file AndroidManifest.xml lists these and specifies how they interact. Also specifies things such as themes to apply to whole app or to specific Activities.


The app can send Notifications, which can contain links back to Activities in the app.

The app can use OS / Google Play services such as Location, Alert Dialog, MediaRecorder, AudioManager, Bluetooth, Camera, Clipboard, Maps, more.

Standard base language is Java, but you also could use C++ or Kotlin.

NoviceDock's "Android Development Syllabus"
Romansh Yadav's "Understanding Android OS Architecture"
Tutorials Point's "Android - Architecture"
Do mockup with Balsamiq or Lucidchart or something similar.
Sayak Boral's "The Beginner's Guide to Android Studio"
Tracey Rosenberger's "How to Set Up and Run Android 9 for Development on Your Computer"

"Android Emulators" section of my "VMs and Containers" page
"Flutter / Dart" section of my "Develop an Application" page


It seems any particular app X tends to be in either Google Play Store or in F-Droid, but not in both ?

Some differences among the stores:

Be careful:
Watch out for named-alike apps: malicious app given same or similar name as some legitimate very popular app. Check the "made by" company name.

Watch out for fleeceware apps: subscriptions that say $10/year in big print and then $10/week next to the button where you're paying.

Apps I like to add:
Be careful; there are lots of named-alike apps that may be malicious, or just trying to profit off another app's success. Check the name and vendor name carefully.

"Productivity" apps:
"System" apps:

Some people say the AV apps are lousy, don't use them.

Anti-virus apps: AV-Test's "Here's how well 17 Android Security Apps Provide Protection"

Test apps: Web site that does various tests: AMTSO Security Features Check Tools

If you just put the EICAR files and some non-Android virus files on the phone, say in the Internal Storage / Android / Data folder, they don't get detected.

ashishb / android-malware (live malware; don't install any APKs)

See Smartphones section of my Computer Security and Privacy page.

Remove Apps

How to identify apps:
Vivek's "3 Ways to Find Out Android App Package Name or Android App ID"

Typical apps:

Apps I want to delete:
Sarang's "List of Bloatware you can Remove or Uninstall from your Android device Without Root"

But after deleting GMail and Google Drive, they came right back (maybe upon next reboot, not sure).

Substitute apps to get more privacy:

Brendan Hesse's "Remember to Delete and Unlink Your Accounts Before Deleting an App"

What you can do to each app:

Go to Settings / Applications and click on each app you want to disable or delete. See what options are available.

Potential problems:

How to disable apps:
Adam Conway's "How to disable any pre-installed system app bloatware on Android without root"
Convenient but maybe dangerous: Universal Android Debloater (adb script)

How to delete apps:

Settings / Developer options / Take bug report and "adb bugreport DESTFILE" don't do anything on my phone. If omit DESTFILE, name should be On my Android 6.0 system, "adb bugreport >bugreport.txt", and you get an 11 MB file.
adb shell ls -R /
adb shell

adb shell pm list packages
adb shell pm list packages -f

RMG's "30+ Most Used ADB & FastBoot Commands for Android 2019"
Mohamed Ibrahim's "Android: ADB - List Installed Package Names"

Android Developers' "Capture and read bug reports"
Android Developers' "View on-device files with Device File Explorer"


Whitson Gordon's "How to Speed Up Your Old or Sluggish Android Device"

David Nield's "Here's How to Get Android Apps Running on Your Laptop"

Brendan Hesse's "How to Run Diagnostics Tests on Your Smartphone"

If you accidentally delete lots of photos:
"DiskDigger photo recovery" app

Google's "Help protect against harmful apps with Google Play Protect"
Jason Cipriani's "How to check your Android phone for malicious apps" (Google Play Protect)

From Daniel Micay (lead dev of GrapheneOS, I think) on reddit 4/2019 (here):

Re: OS Security: iOS vs GrapheneOS vs stock Android:

Android is not a single operating system but rather a family of operating systems conforming to the "Compatibility Definition Document". Google builds the OS for their first-party devices from the Android Open Source Project with the addition of a directory with proprietary Google apps and resource overlays replacing the AOSP sample apps. That means the stock OS on Pixels is essentially AOSP, but that isn't the case for other devices. There's a drastic difference between the current version of AOSP with ongoing support and the sketchy forks of the OS on most other devices with tons of added attack surface, rolled-back security features, poorly-written code and a lack of security updates or major upgrades. I will assume that by Android you mean AOSP or the stock OS built from AOSP + Google apps on Pixels, rather than Android as an operating system family. That means my statements do not apply to forks of the OS on other devices.

It's also important to note that lots of privacy and security is tied to firmware and hardware rather than the OS running on it. The Nexus 5X and 6P were the start of addressing lackluster firmware and hardware security, but they didn't move the needle much. Pixels have drastically improved it and each generation has added compelling hardware security features and improved the existing ones. The firmware / hardware security has also been tightened up a lot, despite some regressions like added attack surface in the boot chain.

AOSP has gone through extensive privacy and security improvements over the past few years, and there are huge privacy improvements coming with Android Q that dwarf the progress in past years. A Pixel 3 fares very well on the security front when comparing to a current generation iPhone at the software level. It's catching up at the hardware level too, and matches most of the hardware security features.

The Titan M is definitely competitive with the SEP in terms of functionality and security. On the other hand, other aspects of firmware / hardware security are lackluster compared to the iPhone. I definitely trust Apple more with setting up proper IOMMU configuration, etc. at this point. Their more-specific focus also means less attack surface in the firmware such as the boot chain. Google has a lot of work to do as they take more control over the hardware and are able to properly harden it. Google and Qualcomm generally do a very good job, but things sometimes really fall apart at internal / external organization boundaries especially with peripherals from other companies like Broadcom Wi-Fi. Apple is better at managing the whole stack from top to bottom and avoiding some of the pitfalls that have been issues on Pixels.

I would say that when comparing only security of the OS and hardware on a Pixel 3 to an iPhone with iOS, the Pixel fares well and trades blows with the iPhone. There are areas where it does better, and areas that it does worse. It's a very complex story and it's very difficult to boil it down to a clear answer. I'm not going to go into any depth about it because it's too much. It's not something you can really ask on reddit since a book could be written about it and would constantly need to be updated / rewritten. I can give you my opinions at a high level, but if you want details you'll need to do the research since I can't spend all year writing about it.

iOS definitely does still offer better privacy from apps and their services are generally more privacy-respecting than Play Services. However, a lot of the invasiveness of Play Services is really opt-in or opt-out just like comparable analytics, etc. on iOS. It has privacy issues, but a lot of the claims about it are misinformation and it's possible to set up a Google account and stock device to be fairly privacy-respecting. I prefer devices without Play Services, but there are comparable issues in Windows, macOS, iOS and even Linux distributions, etc. Play and Google apps are particularly bad offenders in terms of nagging you to enable privacy-invasive features, and having some bad defaults. Usually they get you to opt-in to the truly privacy-invasive bits, but the nagging means most people end up doing it, since otherwise you'd need to actually disable some of the notifications which most people probably don't even know how to do.

GrapheneOS starts from AOSP without adding in the proprietary Google apps and services. It's focused on privacy and security-hardening to improve the OS from the baseline. It also preserves all the standard software and hardware security features, unlike other alternative operating systems. In the past, the project has made substantial improvements that definitely change the picture when it comes to OS privacy and security. However, it has only recently been revived and has a long way to go to reach that point again and surpass it by becoming a much broader project with a strong development team. There is a limited scope to what can be done by only a single (more than) full-time developer with some external code review and contributions. The goal is largely advancing mobile security as a whole including landing lots of features upstream and doing a lot of useful research and engineering work advancing the status quo everywhere. The project has been very successful at doing that in the past, while also offering a compelling OS. I would say that once everything is added back, it compared very favourably to iOS, and Pixel hardware is good enough to make it a decent alternative. It's not currently at that point again. I'd definitely say that once it's fully revived and going again, it will be significantly harder to remotely or locally exploit than iOS.

A major caveat to all of the security questions is that people are often not compromised with an exploit. Even a targeted activist / journalist will often be compromised by tricking them into giving up credentials, installing a malicious app and granting it permissions, etc. Android permits users to grant a lot more access / permissions to apps. This has been changing, and Android Q locks things down much more. Still, it offers users more control and freedom than iOS. You can also sideload apps, rather than only installing them from whitelisted sources / signatures, which protects users from themselves but also enables censorship and banning apps. It basically forces it since you put yourself in the position of a moderator, and are pressured by governments and other organizations to ban apps. It also achieves very little in terms of securing the system since so many of those apps have vulnerabilities / trivial arbitrary code execution. It mostly just polices what people are allowed to install, and many malicious apps / updates will still get through review. It's hard to distinguish malice from incompetence too. Competence malice looks like unintended bugs if you even find them which you probably won't. It's a trade-off in the design. ...

Android is not really "Linux". It's a Java run-time on top of the Linux kernel.

Ron Amadeo's "Google outlines plans for mainline Linux kernel support in Android"

Possible next-generation from Google:
Quarkslab's "Playing Around With The Fuchsia Operating System"

From someone on reddit 9/2020:

> Why is it so difficult to put a Linux distro on an Android device ?

First of all, the portable device can not discover its internals like a PC can. It needs data (embedded in bootloader) which describes where everything is: storage, screen, radio, etc. You may think that the data is unique for every model of the device. Wrong: sometimes it is unique for every production batch of a model, if the manufacturer had to change literally anything.

Changing the bootloader is a very risky operation: if anything goes wrong, the device is dead. No second attempts, no factory resets, nothing.

You may use the manufacturer's bootloader, but even if it does not lock you into official firmware only, usually it only supports Android kernels.

Then come the driver problems. Many devices inside a phone do not follow any open protocol and have no open drivers. In some countries it is forbidden for a phone manufacturer to open the drivers for the actual cell module.

This page updated: March 2020