mvglasow
commented
7 years ago Just came across a few instances in some extensions I’m developing for LibreTasks.
As I understand it, minSdkVersion=3 is needed in order to be able to request certain permissions. As soon as I increase minSdkVersion, I get all kinds of warnings about certain permissions being only available to system apps.
Note that the problematic permissions will not be granted to apps running on a higher API version. Android simply will not deliver certain intents and throw an exception if certain calls are made.
I’m currently working on two things: the first is speech output, the other is Bluetooth connect/disconnect events, filtered by device. Speech requires API 4 or higher; Bluetooth connect/disconnect can be captured on API 3, but the information needed to filter by device is not exposed before API 5. Currently there doesn’t seem to be a clean way to deal with this.
My suggestion: tag every event, filter and action with a minimum and maximum SDK version. Display an error message when a user tries to access any of these features with a device which is outside that range (“Sorry, this feature is not available on your version of Android”). On startup, check if an active rule uses a feature that is not supported (which may happen if a user has created a rule which has a maximum API version, then upgrades his OS to a version on which the rule is no longer supported), and disable any such rules and display an error message.
Dear developers,
We have recently developed a state-of-the-art static analysis tool for uncovering API compatibility issues in Android apps. Applying this tool to open source apps on F-droid, we have exposed a few instances of compatibility issues and submitting them to development teams for a fix.
For your app, we have found that this project has accessed the following APIs which are available only on an API level higher than the declared minSdkVersion and which are accessed without proper protection. In other words, if those APIs get called at runtime, it will trigger a NoSuchMethodError and thus result in a crash of the running application.
<android.telephony.SmsMessage: android.telephony.SmsMessage createFromPdu(byte[])>:[4,25] <android.media.AudioManager: void dispatchMediaKeyEvent(android.view.KeyEvent)>:[19,25] <android.bluetooth.BluetoothAdapter: boolean enable()>:[5,25] <android.telephony.SmsManager: android.telephony.SmsManager getDefault()>:[4,25] <android.bluetooth.BluetoothAdapter: boolean disable()>:[5,25] <android.telephony.SmsManager: java.util.ArrayList divideMessage(java.lang.String)>:[4,25] <android.telephony.SmsMessage: java.lang.String getOriginatingAddress()>:[4,25] <android.bluetooth.BluetoothAdapter: android.bluetooth.BluetoothAdapter getDefaultAdapter()>:[5,25] <android.telephony.SmsManager: void sendTextMessage(java.lang.String,java.lang.String,java.lang.String,android.app.PendingIntent,android.app.PendingIntent)>:[4,25] <android.telephony.SmsMessage: java.lang.String getDisplayMessageBody()>:[4,25] <android.bluetooth.BluetoothAdapter: boolean isEnabled()>:[5,25]
Note that, because of the nature of the static analysis, we cannot confirm whether the flagged APIs would actually be called at runtime (e.g., unreachable code). However, we still believe that those APIs, which may cause compatibility issues, should not be accessed or at least be accessed with proper protections.
In addition to the aforementioned APIs (i.e., backward-compatibility), which could cause app crashes if accessed, we have also identified that this project has also accessed some APIs that have been removed from the latest public SDK, making the app possibly suffer from forward-compatibility issues.
<android.app.Notification: void setLatestEventInfo(android.content.Context,java.lang.CharSequence,java.lang.CharSequence,android.app.PendingIntent)>:[1,22]
We would be very much appreciated if you can acknowledge to us that those reported APIs are indeed problematic for the project’s long-term stability. please let us know if you need any more information relating to this issue report.