I'm building an Android application using Xamarin. Visual Studio allows you to specify the target and minimum SDK level for Android, and this seems to work correctly, as decompiling the APK shows these attributes on the manifest tag of AndroidManifest.xml:
platformBuildVersionCode="25" platformBuildVersionName="7.1.1"
Please not that this is not the manifest file in the project, but rather the manifest file bundled in the final application. The latter does not have uses-sdk values.
However, I don't seem to be getting the expected functionality at runtime for targeting this version. Specifically, the app never asks for runtime permissions (introduced in API 23 IIRC), and when you try to revoke a permission on the app, you get this message:
This app was designed for an older version of Android. Denying permission may cause it to no longer function as intended.
This has been noted on several devices running above API 23, including a Pixel, which should be running stock Android and have no issues with detecting SDK version.
How is Android deciding which SDK version I'm targeting if it's not using the manifest values? How can I ensure my app will have access to API 23 features at runtime?
I believe this information is encoded in the signature of the APK, as the minimum SDK version is a parameter given to apksigner:
--min-sdk-version Lowest API Level on which this APK's signatures will be
verified. By default, the value from AndroidManifest.xml
is used. The higher the value, the stronger security
parameters are used when signing.
I'm not 100% sure on this, but it seems like this is the only way Android could know without using the manifest directly, and it would explain why it was possible for the manifest value to not match the value seen at runtime.
Related
I have an Wear OS app on the Play Store. Recently I wanted to upload update but I'm getting error Your app currently targets API level 30 and must target at least API level 31 to ensure that it is built on the latest APIs optimised for security and performance. Change your app's target API level to at least 31.
I would understand this for regular phone app but in Play Console Help Center they clearly state that Wear OS app are excluded (since nothing newer than API 30 exists there anyway) - https://support.google.com/googleplay/android-developer/answer/11926878
This is the error:
I'm not sure how they define (distinguish) between regular app and Wear OS app because when I've created store listing it was basically regular app setup + enabling Wear OS form factor but all the documentation describe it this way. And the distribution was working fine so I consider my app listing Wear OS only.
I also have <uses-feature android:name="android.hardware.type.watch" /> in the manifest as required.
Tldr; is it something I'm missing in my setup to be eligible for this target API exception for Wear OS or is this console error happening to others as well?
Change Your targetSdkVersion to 31
then try to Upload on Play Consol
My ionic app is targeted 24, min 16, no max in android manifest.
When I run in firebase on devices set to 24 or 25 I get fatal crashes.
Does my app need a max to avoid crashes? Or does that limit it being supported on newer API devices?
Also in Android studio when you first try to set a project and pick a target it tells you that __% of people in the play store use that target so 24 is less than 1%. So if my target is 24 does that mean only 1% of the store will be able to use my app?
Here is my API 23 app crash on a 25 device:
API 24 app crash on a 24 device:
I see you are a little bit confused, let's first clear what each of them means to Android.
android:targetSdkVersion
With this you are telling Android which SDK you are targeting. What is important about this is that it tells the system that SDK level matchs this attribute, the system doesn't need to enable any behaviour to maintain compatibility.
Your app is still able to run on older versions (down to minSdkVersion).
android:minSdkVersion
As the attribute name suggests this is the minium SDK version required in order to run the app, if the device which is trying to install the app has a lower sdk version the system will block the process.
What is important to note is that if you raise the minSdkVersion in an update, all the user which have already installed the app and no loger match this attribute will be able no longer to use the app
android:maxSdkVersion
Again, the attribute name says it all. This is the maxium Sdk version a device can have in order to run the app.
Notice this from the docs:
An application declaring maxSdkVersion="5" in its manifest is
published on Google Play. A user whose device is running Android 1.6
(API Level 4) downloads and installs the app. After a few weeks, the
user receives an over-the-air system update to Android 2.0 (API Level
5). After the update is installed, the system checks the application's
maxSdkVersion and successfully re-validates it. The application
functions as normal. However, some time later, the device receives
another system update, this time to Android 2.0.1 (API Level 6). After
the update, the system can no longer re-validate the application
because the system's own API Level (6) is now higher than the maximum
supported by the application (5). The system prevents the application
from being visible to the user, in effect removing it from the device.
That's it. Check also the DOCS here
Also in Android studio when you first try to set a project and pick a
target it tells you that __% of people in the play store use that
target so 24 is less than 1%. So if my target is 24 does that mean
only 1% of the store will be able to use my app?
Actually not, you have to consider the minium and max in order to find how many % of market will be able to use your app. That's just saying how many people (in %) have that SDK Version.
About the crashes
I am quite sure that the problem is not related to the SDKVersion, maybe you should post some log in order to give a more detailed answer to that.
Hope it helped you :)
Preparing application with following configuration:
<uses-sdk
android:maxSdkVersion="18"
android:targetSdkVersion="17"
android:minSdkVersion="8" />
But application installing properly on lollipop devices. Can anyone explain the matter why this is occurred.
android:maxSdkVersion is no longer checked beyond Android 2.0.1 as stated by developer.google.com:
Future versions of Android (beyond Android 2.0.1) will no longer check
or enforce the maxSdkVersion attribute during installation or
re-validation. Google Play will continue to use the attribute as a
filter, however, when presenting users with applications available for
download.
Reference:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#max
Switch To Android Studio
android:maxSdkVersion — Specifies the maximum API Level on which the application is able to run.
Warning: Declaring this attribute is not recommended. First, there is
no need to set the attribute as means of blocking deployment of your
application onto new versions of the Android platform as they are
released. By design, new versions of the platform are fully
backward-compatible. Your application should work properly on new
versions, provided it uses only standard APIs and follows development
best practices. Second, note that in some cases, declaring the
attribute can result in your application being removed from users'
devices after a system update to a higher API Level. Most devices on
which your application is likely to be installed will receive periodic
system updates over the air, so you should consider their effect on
your application before setting this attribute.
Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersion attribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.
Read Official Document
There is a line in the AndroidManifest.xml
android:minSdkVersion="10" android:targetSdkVersion="19"
Does it mean that if I include minimum and maximum SDK version in the AndroidManifest.xml file and build the APK using phonegap/cordova CLI (Command Line Inteface),
than a SINGLE APK file generated can be installed on ALL Android Devices ranging from Android 2.3.4 to Android 4.4
I have read posts that developing using Android SDK(native APP) it enables the APP to work on the range of devices.
Is it true for PhoneGap/Cordova generated APK file as well? (Note: I am not planning to use Google Play services for distributing the APP.)
Do we need to generate APK file for each SDK version?
The implications of these two variables is the same for both native apps and PhoneGap/Cordova apps.
minSdkVersion will set the minimum version of Android required to run your application. If a user is running any version below this, they will not be able to install your application (regardless of whether or not you are distributing via the Play Store).
targetSdkVersion specifies the latest version of Android that you have tested for. It will not change who can install your app, but it will change the behavior of your application. For example, if this is less than 14, you won't have an action bar. If it is less than 19, then users running KitKat and above will not see your content in a Chrome-backed WebView (it will be the older WebView implementation).
Generally you just set targetSdkVersion to the latest available version of Android.
Do we need to generate APK file for each SDK version?
No. You need one APK with mindSdkVersion set to the minimum version you support and targetSdkVersion to the latest version of Android you have tested against.
You can specify a maxSdkVersion, which will actually limit the maximum version you support, but you generally should not do this unless you have a good reason to.
android:minSdkVersion is the minimum API level that device needs for run your app.
android:targetSdkVersion is the latest tested API that works with your app, and you should set there the latest API version.
Following useful data about the number of devices running API versions: https://developer.android.com/about/dashboards/index.html?utm_source=ausdroid.net
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