Develop Reference

What happens in Android if you run code that requires a permission but fail to have it?

I am talking about the quality issue (bug) that an Android app needs a permission that is declared in the Manifest, but fails to request it from the user at the appropriate time and executes the code without the necessary permission. This was not possible in older Android versions (user accepts all permissions in bulk), but seems to be possible when using newer versions that copy Apple in most regards.
At least during testing one can start background services and use bluetooth without any alert by Google popping up. Is that different for apps in production?
Does the app crash with an Exception?
Does the code get executed?
Does the app get rejected in review? (Always?)
Does the app get delisted from the store?
Does it depend on Android's Version?
I deal with an age old app that has bluetooth discovery code to find and connect to dedicated hardware, that is rarely used via a cordova plugin triggered by content. There is old altbeacon code potentially activated that may even need access background location (https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions). It will take some time to get this dead code up to quality. Definitely more time than the week we have.

Does the app crash with an Exception?
yes if you try to have operations depends on returned date witch is null
Does the code get executed?
code will execute with exceptions because data access denied you can check if permission granted or not and add scenario for each state
Does the app get rejected in review? (Always?) not sure but with crashes there is high potential to get rejected
Does the app get delisted from the store?
depends on why and how you are using data
Does it depend on Android's Version?
yes access data and permissions changing point is android oreo

My tests with Bluetooth permissions revealed the following: Required permissions are BLUETOOTH_ADMIN, BLUETOOTH and for VERSION_CODES.Q additionally Manifest.permission.ACCESS_BACKGROUND_LOCATION (see: https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions).
BLUETOOTH_ADMIN, BLUETOOTH do not show any system alert-dialogue to the user. In Android Q+ if you fail to check for the required ACCESS_BACKGROUND_LOCATION permission, nothing happens and your code executes without exception (mine did execute an UART command on hardware with Samsung tablet). The app passed review although the check is missing (of course I will fix that ASAP).
Note: the doc is ambiguous and states: "Services running on Android 10 and higher cannot discover Bluetooth devices unless they have the ACCESS_BACKGROUND_LOCATION permission." Probably general scanning while the app is active could be allowed. In that case missing exception would be explained.

Detect application is being uninstalled in lollipop devices

I would like to know which users have uninstalled my application so that I can ask them for a feedback to improve the app. Hence, I would like to detect when the user has initiated the uninstallation process on my app.
One of the older solutions on StackOverflow had the following steps:
List< ActivityManager.RunningTaskInfo > taskInfo = am.getRunningTasks(MAX_PRIORITY);
String activityName = taskInfo.get(0).topActivity.getClassName();
if (activityName.equals("com.android.packageinstaller.UninstallerActivity")) {
// do whatever is needed
Since Lollipop, getRunningTasks has been deprecated. So how can com.android.packageinstaller.UninstallerActivity activity be detected without getRunningTask?
Alternatively is there any other method to detect uninstallation process has been started on my app? Using getAppTask probably?

Apparently you wont be able to do this, you will have to rely on something called silent notification.
What we did was we sent notification every 3 days or whatever frequency you want.
On the client side as soon as a notification is received we hit a network call which mark NotificationReceived for the client. Now since notification are not full proof we assumed a threshold of 2/3 missed notification as uninstall event. And for the client we have this counter above decided threshold we contacted them for feedback.
Also no one will be willing to fill your form at the time of uninstallation as user has already decided to uninstall your application.

Read these 2 questions and answers:
native solution
GCM solution
As I know you have to mix the two. Read the limitations of first solution. You have to confirm uninstallation event of the first solution with the second solution for a complete implementation.

Hopefully, this solution will work for you. It helps you understand the reasons for your app uninstalls, reduce the uninstall rate using a powerful predictive engine and also get app Re-installs through a unique actionable channel (Android version 4.0 and above).

Just set a variable named appLastPresent for every user in the server-side and update that variable every day by calling an API using WorkManager's PeriodicWorkRequest. Also set installedDate variable when the user installs the app.
Now set up a chron job on the server side to check if the difference between installedDate and appLastPresent is greater than 7 days. Then send the user an email or message enquiring for issues or feedback, if it is greater.
NB: User can be offline for 7 days. Therefore only send email enquiring like why you are not using the app, if uninstalled please let us know why

Change intent filter android priority of other applications

I have a SMS Blocking Android App. It worked fine until Google introduced SMS feature in Hangouts and so did Samsung in its ChatOn messenger. Both of them have the highest priority for SMS receiver ie 2147483647. I verified this from their manifest.
So is there anyway to decrease their SMS receiver priority using what so ever method including root?
I plan to implement a "click to fix" option after a user opens the app.
The only way I could think of doing this was to edit the manifest file of these applications.But again I am not sure how android processes the Broadcast receiver. Does it use its own internal memory to know which app will process the sms received broadcast, or does it read the manifest file of all the installed applications every time?
If there is a separate memory how can I access it(using root, if required) and if manifest file is read every time, is it possible to edit that file even with root, as I read there are signature related issues.
P.S In root programming i have just experimented with calling standard sudo commands inside an app. Also my main focus is on pre Kit Kat devices.

What will happen if I use the sendTextMessage method and the user has a tablet?(Android)

I want to send an SMS message in my application and I want to ask what will happen if the user has a tablet. Will my app crash?
Will it do something strange?
I am using the following method:
SmsManager.getDefault().sendTextMessage(destinationAddress, scAddress, text, sentIntent, deliveryIntent)

Technically, tablet device won't be able to "find" your application from Google play store, since your app requires telephony features.
However, if tablet user got your application some other way, and install it manually, you can not prevent them. When application running, it might crash if the firmware does not handle the exception correctly. But I don't think it would happen, most of the chance it won't take any effect.

Well, that depends on the tablet, if it has a SMS slot or not, I assume you are interested in the type that doesn't has a slot, in this case the tablet will take a long time and the system will ask for wait or cancel, if wait then it will finally show an error message, the error message depends on the Android version, and your application crashes in this case...

PhoneStateListener onMessageWaitingIndicatorChanged() not being called reliably

I have some code that detects when there is new voicemail. It's based on a PhoneStateListener.onMessageWaitingIndicatorChanged() implementation (so technically it fires only when the MWI indicator changes, not necessarily for every new voicemail).
It has been working perfectly for many months until 4.x.x updates to the devices.
Now, this works when the device is rebooted, otherwise its very unreliable. I can see the voicemail icon appear in the notification bar, but the debug logs in onMWIChanged stay silent.
I know that with 4.x.x there is a voicemail provider API. Thinking that this may have a connection, I added the android.intent.action.NEW_VOICEMAIL and android.intent.action.PROVIDER_CHANGED intents to my receiver, but they don't fire (in my BroadcastReceiver onReceive) either (my app's minSdkVersion is 8).

This is a post from Android Developers about the Android 4.0 APIs.
http://developer.android.com/about/versions/android-4.0.html
If you scroll down there is a section about Voicemail Providers where it explains:
Because the APIs currently do not allow third-party apps to read all the voicemails from the system, the only third-party apps that should use the voicemail APIs are those that have voicemail to deliver to the user.
However, I assume if you are trying to receive voicemails from a third party and not from your service then this still may be possible. Check out this link about VoicemailContracts where I believe it says you need the permission ADD_VOICEMAIL in your manifest to use the actions you are using above.
http://developer.android.com/reference/android/provider/VoicemailContract.html
There are also samples that I did not get a chance to look at called Voicemail Provider Demo in your SDK. I hope this helps.

It does require the READ_PHONE_STATE permission. Although, if it worked before you must of had it set.
See LISTEN_MESSAGE_WAITING_INDICATOR.