My application is targeted for API 8 (Froyo) minimum, however I'm getting a message in the Android Market that says "This report was sent in by a pre-Froyo client, which did not include a stack trace."
When does Android check that the Min-sdk is greater than or equal to the API version on the phone. Is it at runtime or market download time?
Your app's minSdkVersion is filtered by the Market and the phone, however there are a few ROMs out there that disable this filtering at the phone-level. If you're seeing a report from a phone that is below your minSdkVersion it usually means the user installed the app directly, not from the market, and their phone tried to run it even though the SDK version wasn't usable by the device. This would result in a bug report being posted to the Market, but the Market app doesn't ask the device how it got the app in the first place.
You'll see this once in a really long while--it's nothing to be alarmed about.
I believe it filters in the market. Perhaps somebody got ahold of your APK and distributed it to a pre-Froyo phone? Just a guess.
edit - taken from the ref http://developer.android.com/guide/topics/manifest/uses-sdk-element.html: An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.
Perhaps you have confused minSdkVersion and targetSdkVersion?
Related
On publishing the codename one app via the google play console I get the warning messages and the Start To roll Out To Production is then disabled.
the first warning message is:
Target API level requirements from August 2019
Warning:
Your app currently targets API level 27 and must target at least API level 28 to ensure it is built on the latest APIs optimized for security and performance.
From August 2019, new apps must target at least Android 9.0 (API level 28).
From November 2019, app updates must target Android 9.0 (API level 28).
and the second warning message is:
Unoptimized APK
Warning:
This APK results in unused code and resources being sent to users. Your app could be smaller if you used the Android App Bundle. By not optimizing your app for device configurations, your app is larger to download and install on users' devices than it needs to be. Larger apps see lower install success rates and take up storage on users' devices.
Resolution:
Use the Android App Bundle to automatically optimize for device configurations, or manage it yourself with multiple APKs.
please see screen shot
is there anyway to fix this?
TLDR: You're posting this because you have a problem submitting which has nothing to do with that warning as #Zeromus mentioned. It's just a warning and googles awful UX hides the actual problem (probably you didn't do the child safety interview or some other nonsense).
About those warning's they are Google's BS.
Google has an option to split APK resources which we don't leverage and don't really need to. In fact for Codename One Build it estimates using it can save 6% of the download size. That's more than nothing but it's a small number.
This is required for apps built in Android Studio because they are so damn wasteful in terms of resources. We get that exact same warning for Codename One build but the funny part is the report. Where they show we are 66% smaller than the median app even without those redundant "optimizations":
I've been trying to simulate a scenario where I want to check how my Android app behaves after an OS update. But I don't have access to physical device at the moment where I can run an actual OS update scenario, so I have to resort to trying it out on android emulator (AVD).
Is there a way I can update the OS on AVD as if it were a real phone, and be able to see how my app would behave?
What I essentially want to test out is this:
Let's say that I have android with API level 21 installed on a device. I install an app with maxSdkVersion 21 on it. Now my device upgrades to API level 22. What will happen to my app?
Will the OS silently get my app uninstalled and keep it that way?
Will the OS check with play store to see if a build of my app with a supported SDK level is available and download and install that instead?
Will the OS at least give me a visual warning or prompt that this particular app is not compatible on the device anymore and tell me what I could do next?
The Android Developer Docs recommends that using maxSdkVersion is not a good idea since in some cases uninstalls would happen.
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 normally. 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.
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.
What I also want to figure out is what happens next. And what does "in some cases" essentially mean?
I have created 2 demo apps to check your questions using the emulator. I have updated emulator's API level and restart it because every device gets restart after the system update. Please see this video what happening :)
Will the OS silently get my app uninstalled and keep it that way?
yes app get uninstlled
Will the OS at least give me a visual warning or prompt that this
particular app is not compatible on the device anymore and tell me
what I could do next?
app getting uninstalled without any message or warning
Will the OS check with play store to see if a build of my app with a
supported SDK level is available and download and install that
instead?
I think this can be check if the app is available on the play store. So I'm unable to test this. If anyone knows the answer to this question, please comment
I developed an application and I put it on Google Play, but the thing is that sometimes, some people fail to install it and i don't know the reason.
However, i'm not sure if the reason is because my minSdkVersion is set to "8".
I'm using Android 2.2 API.
Is it ok to set the minSdkVersion = "1" ? and what are the disadvantages of putting it as "1" instead of "8". How should I choose it? That makes me confused because in the same time I want everyone to install my app.
There is very little benefit from using API 1 as the minimum SDK. Check out Android's Dashboard of active devices. It shows that 3.1% of users still have API 7 or below, 0.4% for API 6 below.
You will also find great difficulty, if it is even possible, to recreate many of the modern features in API 1... even the Support Library only works on API 4+.
In short, it is unlikely that your minimum SDK version is the culprit.
Only set the minSdkVersion to the lowest you have tested on. If you use features that are specific to API level 8 (or higher), and don't specifically check for their existence, then your users on lower versions won't be able to run anyway.
Running lint can also smoke out bugs from lower versions.
This number will only filter out users on the market. They will get a message saying the app isn't compatibile with their version. It sounds to me like the problems you are having are that users are failing to install. I don't believe changing the minSdkVersion will help you there. This is most likely to do with bugs in the Android Market version they are using.
I'm wondering, if I have an APK that supports for example Android 2.3.7 and below and another that supports 3.0 and above what will happen if a user with a device with 2.3.7 updates it's OS to 4.0 ?
For example, a Samsung Galaxy S II update from 2.3.X to 4.0 ?
Will the app be auto-magically replaced? Will it crash?
I think it depends on your version numbering scheme. If the app version that supports 3.0+ has a higher version number than the one that doesn't, the market will likely show an upgrade available. It should update like any other app (but it may not be immediate): if the user has auto-updating on for the app, it will update itself after a while, but if not, it will appear to the user as having an update available and will wait on them to download it. Unless the permissions are different between the versions.
Whether it crashes or not will be determined by the app itself: what happens if you yourself install the 2.3.7 APK on a 4.0 device (which may or may not require a quick change to the manifest file)?
I'm pretty sure it won't be replaced. The documentation says, that you publish multiple APKs under one Google Play (Market) entry. So if user has a specific APK which has a max-sdk parameter set in Manifest, then it won't work on newer system. But if you don't have max-sdk specified and there are no conflicts, it will.
EDIT: But as Jon O said, it should be possible for the user to update the app, because it's still the same Google Play entry.
Our app supports android 2.2 up. The app works on android 3.0 emulator. However we received report from honey comb device users that they do not see the app showing up in Market on their device. When they use Market website on PC and select their device to install, they got message of "App not compatible with your device".
Anyone, please advise what we need to do to make the app show in the Market for 3.0 devices. Is it something we need to add in manifest file or something we need to config during the publishing.
June Jorgensen
Have you set android:xlargeScreens="true" in the supports-screen section of the AndroidManifest.xml?
Have you tried setting the targetSdkVersion in the AndroidManifest.xml to 11 or 12?
Use "aapt dump badging" on your .apk to see the kinds of things in it that are used for filtering.
There is nothing in Honeycomb per-se that would prevent apps from being installed. However, there are characteristics of current Honeycomb devices that are of interest. For example, none of them are phones. Make sure you are not requiring telephony, either explicitly with a tag, or implicitly by requesting a telephony related permission (again aapt dump badging will tell you about this).