Develop Reference

Local install of APK in Android 13

Goal: Have an app that can update itself on a custom/rooted ROM in Android 13 by saving the APK locally, then having an app install it without user interaction.
Solution: Use an intention as described in the second answer here.
What no longer works:
Originally this was a question because after a lot of time I only found out-of-date answers. Android keeps on increasing security and deprecating old APIs. Here's a list of rabbit holes to avoid.
Install with exec(), su, and pm install
Granting the app android.permission.ACCESS_SUPERUSER and similar permissions
Forcing ROM into permissive mode at compile to avoid SELINUX blocking access
Approach 1 fails because you will get Caused by: java.io.IOException: error=13, Permission denied. First you need to move the APK into a tmp dir. However when you try to run su you get the exception. You need to be su for pm install -r -d foobar.apk to work. This used to be the most common way that people installed a new apk. Even if there were no issues with it I would recommend using the answer above as its less of a hack.
Approach 2 seems to be just out of date and Android has moved on.
Approach 3 is an attempt to get around the su issue. It's unclear if SELINUX is really what was causing the exception to be thrown and maybe someone can clarify what's going on. SELINUX is what was blamed and a lot of people spent a lot of time trying to create custom rules.
To get something that worked I attempted to force the device into permissive mode. Using compile time flags doesn't work BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive and Google needs to update the instructions. I could write more here, but it's a black hole. Looking at logs there was no indication SELINUX was blocking 'su'.

Crashlytics works on production but doesn't work on test

It's a weird situation. I have a react native app that has a test and production environment. On the production side, my app is correctly integrated with crashlytics. But when I try to integrate on test apk, I see only "App detected and we're waiting for a crash!"
SS
Test and prod use the same application, the only difference is google-service.json files. I've not found anything. Please help.
Some notes:
I've tried on emulator and physical devices.
When I try to see dashboard for prod build, I can see correctly.
I don't think that it is related by package versions(Because it works on prod). So I didn't put those.
I 've seen " Crashlytics automatic data collection DISABLED by API" with adb logcat -s FirebaseCrashlytics command

When running the app, if you see the "App detected and we're waiting for a crash!" message, that means that the SDK was able to connect with the back end. But something could be preventing the SDK from sending crashes.
The first thing to do would be checking if the mapping file contains the parameter firebase_crashlytics_collection_enabled and if it is set to false. Check this document.
If so, you can override this parameter opting in with the code:
Firebase.crashlytics.setCrashlyticsCollectionEnabled(true)

Android Branch IO SDK policy violation

Today my app was removed from Google Play with the following explanation:
"Your app is using the Branch IO SDK, which is uploading users Installed Packages information to https://api.branch.io/v1/applist without a prominent disclosure. Prior to the collection and transmission, it must prominently highlight how the user data will be used, describe the type of data being collected and have the user provide affirmative consent for such use.
Make sure your app is compliant with the User Data policy and all other Developer Program Policies. Additional enforcement could occur if there are further policy violations."
We do not directly use the Branch IO SDK in our app.
We are thinking that maybe a 3rd party library that we have integrated uses it. We looked over the dependencies used by our 3rd party libraries and we did not find any hint to Branch IO SDK.
Since I don’t know what is being sent to branch.io, I have no idea what I should add to the Privacy Policy or how to solve this issue.
Any idea about the root cause would be appreciated. Thank you!

You can run the following command to get a list of every single dependency, and their dependencies in your app:
./gradlew app:dependencies
If your main app module is called something different than "app", then replace that part.
You can also pipe it all into a file, so it'll be easier to look/search through:
./gradlew app:dependencies > ~/dependencies.txt
That should give you an idea of what is using Branch IO.
If it doesn't help, then you can try to drag-and-drop your APK file into Android Studio, which will automatically decompile the app and show it in a nice window. In there you can see through all classes and their package names and see if any of them match Branch IO.

What is Android Test Orchestrator?

Google released Android Testing Support Library 1.0 recently. After reading the overview, I'm a little confused with Android Test Orchestrator.
It said
Typically, AndroidJUnitRunner runs all tests in the same instrumentation process, which can cause a number of problems.
Can you explain which kinds of problems will be caused by using the same instrumentation process?
if one test crashes, it prevents the remainder of the test suite from running
Through my experience, one test crash won't prevent from other test cases from running. Please point out what I misunderstood here?
And from Android Testing Orchestrator developer guide,
For completeness, Android Test Orchestrator runs pm clear after each test.
So Android Test Orchestrator will run pm clear [test_package_name] after each test, right?
Through my test, pm clear [app_package_name] won't be executed after each test. That means the data of application under test will not be cleared. So test cases might still have dependencies on each other. For example:
Test case A stores a SharedPreference key-value
Test case B which runs after test case A can read out the value stored by test case A
Overall, after some trial, I did not find any advantage of Android Test Orchestrator. Can somebody help to address my confusion? Thanks.

After researching the issue a bit I can provide the following answers:
Typically, AndroidJUnitRunner runs all tests in the same instrumentation process, which can cause a number of problems.
As mentioned, AndroidJUnitRunner runs on the same instrumentation process so basically your tests are running state-full, this might wreak havoc if your tests have some sort of dependency on the process state. In Android test orchestrator each test is run in its own process so dependencies aren't an issue.
if one test crashes, it prevents the remainder of the test suite from running
The crash in question here is a crash of the process, not the activity/application. You can test this by inserting in one your tests System.exit(0); Typically, this will stop the whole test run while in Android test orchestrator the tests continue as expected.
For completeness, Android Test Orchestrator runs pm clear after each test.
This is an oversight of google and has been retracted from the official documentation as can be observed here.
Basically, The advantages of using Android test orchestrator is all about the separate process for each test which improves stability and ensures full execution of tests.

Android Test Orchestrator is a tool which allows you to run each of your app’s tests within its own invocation of Instrumentation.
This means that each test (method annotated with #Test ) will be run on a separate instance of AndroidJUnitRunner.
What issues does it solve?
When dealing with UI tests we identified 2 major problems which occur from time to time when run on CI or locally:
Occasional crashes which stop the entire test suite.
Test overlap.

Orchestrator can prevent crash to interrupt the whole test, eg. native crash.
But it may slow the tests

How to check if Android Permission is actually being used?

I am maintaining one existing (very-huge, very-sensitive) Android Application.
The other day, I have received an email from my client that, the Application might be declaring the Permissions that are not actively being used.
For example, they wants me to remove "WRITE_EXTERNAL_STORAGE" permission.
I have removed it and compiled it and run the App. There is NO error at all.
But, just because of that, I don't think I can assume that permission is not actively being used at all.
My question is "Is there anyway I can easily and simply check the permission if it is actively being used ?"
Frankly, I don't want to go through every little detail aspect of that application just to fine out the permission is required or not.
I just don't have time.
My goal is check if the permission is actively being used. If not, remove the permission.
Hope there is an less-time consuming way for that.
Regards

In Android Studio 1.3 & Android Support Library v7:22.2.0, you have solution for it.
Steps:
Update Android Studio to V1.3
Update your Android Support Library to v7:22.2.0
Run Android Lint (Analyse -> Inspect Code), In Lint Error see for Type "Android -> Constant & Resource Type MisMatch", Which shows all methods which requires permission.
Explanation
Android has introduced new annotation #requirespermission.
All SDK methods which requires permission are annotated with #requirespermission.
When we call any sdk method which requires permission without properly checking whether we have permission or not, Android studio will through lint error.

There is a group at Berkeley that wrote a paper about Android permissions. They talk about over-permissions and developed a tool called Stowaway that would analyze your APK for unused permissions. The analysis was based on the app's API calls and their own mapping of the permissions needed for each API call (see the paper for details). The tool throws a flag if there is a permission in the manifest that is not mapped to any of the API calls found in the APK.
For a while, a web-based version of the tool was available at http://www.android-permissions.org/, but it is from the Gingerbread era and was never updated. The page now suggests using PScout.
PScout does a better job than Stowaway at generating the permission maps. However, PScout does not include an APK analyzer, so you will have to manually compare the mappings they provide with API calls made by your app. Unfortunately, if you're interested in maps for versions beyond 5.1.1, you'll have to generate them yourself using the provided PScout code and your own Framework source.
You might also check out the various APK analyzers here to see if they include the functionality you are looking for.

I tried the method suggested by Vasanth but it doesn't work for me. In fact, because my project has flavors and Code Inspection doesn't work for the project with flavors. See https://code.google.com/p/android/issues/detail?id=210073.
But Running Lint from console works. So steps are simple:
Remove permissions from your manifest.
Run Lint for flavor as described here https://stackoverflow.com/a/32708435/1170154.
Open Lint result and find section Correctness > Error MissingPermission: Missing Permissions. It will contain all calls that require permissions.

As of Android Studio 3.3, running Analyze → Inspect Code will inform you of missing permissions under Android → Lint → Correctness → Missing Permissions