Is it possible to publish an app that will target only handsets or tablets and simultaneosly show itself appropriately in GooglePlay store ?
The thing is that logic that switches functionality between handset and tablet versions starts to be a bit complicated and messed up. For instance, in handset version ViewPager is used while in tablet - TabHost. This forces to apply if-statements and I've only started and don't think that it will look better if I continue.
This logic switching is all about the interface - backbone data operations remain intact on both versions.
What's your experience on this issue and should I consider writing two separate apps ?
Thanks.
http://developer.android.com/guide/google/play/publishing/multiple-apks.html
Develop app for handset and tablet separately with same pkg name.
All APKs you publish for the same application must have the same package name and be signed with the same certificate key.
Each APK must have a different version code, specified by the android:versionCode attribute.
Each APK must not exactly match the configuration support of another APK.
That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).
Usually, you will differentiate your APKs based on a specific characteristic (such as the supported texture compression formats), and thus, each APK will declare support for different devices. However, it's OK to publish multiple APKs that overlap their support slightly. When two APKs do overlap (they support some of the same device configurations), a device that falls within that overlap range will receive the APK with a higher version code (defined by android:versionCode).
Related
I'm having the following error:
Version 102001019 is not served to any device configuration: all
devices all devices that might receive version 102001019 would receive
version 103001019.
The problem appeared after I decided to separate APKs for devices with different screen sizes. I have also already multiple APK configuration, with 4 APKs regarding to the texture compression.
So I've set important setting to those APKs in the following way and it doesn't work:
- versionCode:103001019 screenSize: xlarge,large,normal
- versionCode:102001019 screenSize: large,normal
The numbers 2 and 3 should be the differentiating increasing part of the version code to let Google choose the right version for me.
The docs say:
If you have one APK that's for API level 4 (and above) and small -
large screens, and another APK for API level 8 (and above) and large -
xlarge screens, then the version codes must increase in correlation
with the API levels. In this case, the API level filter is used to
distinguish each APK, but so is the screen size. Because the screen
sizes overlap (both APKs support large screens), the version codes
must still be in order. This ensures that a large screen device that
receives a system update to API level 8 will receive an update for the
second APK.
But as far as I don't need to filter on the API version, and I have overlapping in screen sizes, my variant should be Ok. Right?
Any advice would be very much appreciated!
P.S. I have very slow internet connection and 300+MB single APK+OBB size, so it is a pain to check all possible combinations manually.
I also received that problem when I uploaded the APK at the first time but I noticed that API level 18-17 when viewing APK details. Therefore, I added this code to AndroidManifest.xml to specify the maximum API level
<uses-sdk android:minSdkVersion="18"
android:targetSdkVersion="23"
android:maxSdkVersion="23" />
After doing this, the problem is solved :)
What the Play Store does is always pick the highest version number for each device. So given different screen sizes:
xlarge 103001019 is only available, so pick 103001019
large 103001019 > 102001029 so pick 103001019
normal 103001019 > 102001029 so pick 103001019
As you can see, your 102001019 is not selected for any devices as it only supports a strict subset of devices compared 103001019.
Make sure your multiple APKs are designed to support a unique portion of the devices you wish to support.
In Google play (app market), if an application is not compatible to your device (for some reason, say small screen size, etc). Then it is not even shown in the list.
Now, as an app developer I never want to unintentionally add a limitation in my app that forbids it from a range of devices.
So, while developing how can I make sure that the application will be able to run on atleast the type of devices that I intend.
Also, right now I'm developing an app & testing it in on my phone with version 2.3.5. And every now & then Google changes some method names & flags.
For newer android releases, I CAN test it on emulator, but testing it on phone/tabs/etc. is a different thing.
Please suggest.
how can I make sure that the application will be able to run on atleast the type of devices that I intend.
In manifest file you can mention, which type of device you want to run your app. And for testing you can create emulators for different devices to test your app. Try to make app UI such that it runs on all devices.
Google changes some method names & flags
Whenever Android changes any thing it will always be upward compatible means if you have made app for 2.2 it will run on 2.2 and above (screen size or resolution is other thing)
Regarding UI see my answer here
Layout for 720*1280 devices
By default apps will be available to as wide a range of users as possible.
There are certain limitations you can define in your manifest file, such as not being available on small screen sizes, but they are at your discretion.
The only limitation Google imposes on you is that any user who has a lower Android version than your minimum SDK version cannot see your app. To get around this, you can either design the app for lower SDK versions (I believe building for 2.2 and up gives you access to about 95% of the user base) or maintain multiple versions of the APK.
Read this. It will really help. Next Eclipse will help you a lot, firstly you can define what you wish to support (screen sizes and hardware requirements or even if they're not necessary but may be used) in the manifest. You can run a version check and implement APIs dependent on which version of Android you're running on. That's personally what I do, I check the API level and if it's greater than or equal to the API I wish to run I run it, otherwise I attempt to find compatible code (often using the compatibility library) or alternatively drop support for that feature, for example JellyBean notifications there's not really any work around for expanded notifications but I can use the NotifcationCompat builder.
We're working on a port of an iPhone game to Android. One of the additional hurdles with this is all the different device resolutions Android has. We're having our art team rework the art for each target resolution (we're only picking a few for now with more later.)
My question is, can we (and how best to do it) submit separate packages for each resolution to the Google Market under a single title so that when someone purchases it they get a specific resolution?
UPDATE 7/21/2011
Although we released without it, it was just announced that the Google Android Market now officially supports multiple APKs for a single app.
http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html
You don't have to do extensive job to support every possible screen size, you only need to make resources for several configurations and Android will do the rest. The major concept here is that there are several screen densities you have to support. Once you've made a resource for each density, Android will automatically use an appropriate resource for the specific device. You only upload a single application for all the devices.
You should read an article on supporting multiple screens and also on providing resources.
I have not seen such an option while uploading my own applications to the market. This is a good/official explanation of how to program to various screen resolutions.
If it is impossible for your to package all of your resolution-specific resources into the app, you can download the images from your servers after the initial start-up of the app. At that point, you'll be able to grab the screen resolution details and only download what you need.
what is maximum size of thick/thin client application(to d/w through OTA) in both Android & Samsung Bada platform ?
yokks, you need to have a look # this thread Android - Application (apk) Maximum size for android
If you mean the Android Market by "OTA" which is the most common case since it handles update notifications, etc. - you should know that the apk size limit to upload on the android market is 25 MB. But other than that, I don't know of any limitation, it probably also depends on the device you're targeting.
If you implement your own OTA delivery technique, then of course you don't have this limitation.
Also you should know that on Android you can always/mostly break down one application into multiple smaller ones, if your app elements are very modular, in case you have issues with one single apk size.
I have been developing an Android app and testing with a 1.5 AVD and the manifest setting of
<uses-sdk android:minSdkVersion="3" />
My goal is to make this app available to all phones running 1.5 and greater. I had thought that as long as I develop to 1.5 then that was basically all I had to worry about and any phone running 1.5 or higher would see my app in the market and be able to install it. The following documentation however has me concerned that the app may not in fact be visible to all phones in the market unless I go through the following steps to manage various screen sizes and densities.
My layout is very basic and I do not manage any alternate layouts for high resolution, I just let android manage the scaling. Do I need to follow these guidelines in order to have my app visible to all phones 1.5 and higher? Or is this only necessary in certain circumstances?
From
http://developer.android.com/guide/practices/screens_support.html
Strategies for Legacy Applications
If you have already developed and published an Android application based on Android 1.5 or earlier platform version, you need to consider how you will adapt your application so that it is deployable to
* Existing devices, which may be running Android 1.5 (or lower) platform version, as well as to
* Newer devices that are running Android 1.6 (or higher) and offering various screen sizes and resolutions
To support the newer devices and the different screens they use, you might need to make some changes in your app, but at the same time your app may be very stable and so you want to minimize the changes. There are a variety of ways that you can extend your existing application to support new devices with multiple screens and existing devices running older platform versions. You should be able to make these changes to your application such that you can distribute a single .apk to any and all devices.
The recommended strategy is to develop against the most recent version of the platform you are targeting, and test on the minimum one you want to run on. Here's how to do that:
1. Maintain compatibility with existing devices by leaving your application's android:minSdkVersion attribute as it is. You do not need to increment the value of the attribute to support new devices and multiple screens.
2. Extend compatibility for Android 1.6 (and higher) devices by adding a new attribute — android:targetSdkVersion — to the uses-sdk element. Set the value of the attribute to "4". This allows your application to "inherit" the platform's multiple screens support, even though it is technically using an earlier version of the API.
3. Add an empty <supports-screens> element as a child of <manifest>. If you need to enable size or density attributes later, this is where you will add them.
4. Change your application's build properties, such that it compiles against the Android 1.6 (API Level 4) library, rather than against the Android 1.5 (or earlier) library. You will not be able to compile your application against the older platform because of the new manifest attribute.
5. Set up AVDs for testing your application on Android 1.6 and higher releases. Create AVDs that use the screen sizes and densities that you want to support. When you create the AVDs, make sure to select the Android 1.6 or higher platform as the system image to run. For more information, see How to Test Your Application on Multiple Screens, below.
6. Set up AVDs for testing your application on Android 1.5 (or earlier platform). You need AVDs running the older platforms you are targeting, so that you can test for compatibility and ensure that there are no functional regressions.
7. Compile your application against the Android 1.6 library and run it on the AVDs you created. Observe the way your application looks and runs, and test all of the user interactions.
8. Debug any display or functional issues. For issues that you resolve in your application code, make certain not to use any APIs introduced in API Level 4 or later. If you are in doubt, refer to SDK reference documentation and look for the API Level specifier for the API you want to use. Using an API introduced in API Level 4 or later will mean that your application will no longer be compatible with devices running Android 1.5 or earlier.
9. For resource-related issues, you can try resolving them by:
* Adding a anyDensity="false" attribute to <supports-screens>, to enable density-compatibility scaling.
* Creating any size- or density-specific resources you need and placing them in directories tagged with the correct qualifiers. Qualifiers must be arranged in a proscribed order. See Alternative Resources for more information.
* Note that if you add size- or density-specific resource directories tagged with any of the resource qualifiers listed in this document, you should make sure to also tag those directories with the v<api-level> qualifier (for example, -v4). This ensures that those resources will be ignored when the application is run on Android 1.5 or lower platform versions.
10. If your application does not offer support (such as custom layouts) for large screens and you want the platform to display your application in screen-compatibility mode on larger screens, add a largeScreens="false" attribute to the <supports-screens> element in the manifest. See Screen-Compatibility Examples for illustrations of how the platform displays your application in this case.
11. If your application does not offer support (such as custom layouts) for small screens (such as on a QVGA low-density screen) and you do not want Android Market to offer the application to users of small-screen devices, you must add a smallScreens="false" attribute to the <supports-screens> element.
12. Continue testing and debugging until your application performs as expected on all of the platforms and screen sizes your application will support.
13. Export, zipalign, and sign your application using the same private key you used when publishing the previous version, then publish the application to users as an update.
From this answer:
Save your keystore file.
If you lose it, you will not be able to update your app.
Use <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/> to be compatible with 1.5 and newer devices.
Make your icons based on the Icon Design Guidelines.