What most other "large" games seem to be doing is a second download of data once the app is launched. So the "core" app you distribute on the market doesn't have any resources, then when the app loads it downloads the resources appropriate for the device.
The advantage is the app on the market will only be a few MB and you can immediately download to SD card. The down-side is the extra infrastructure and code you need to put in place to achieve this. (ie you need a server somewhere that hosts the resource files, and need to build the download ability into the app) You can also filter the apk based on Market Filters (http:// developer.android.com/guide/appendix/market-filters.html) but in my experience these don't always have the desired effect (eg specifying <supports-screens android:largeScreens="false" won't stop it being visible in the market, it will just alter how it is displayed at runtime) The third option is that you just name the apps differently.. so call the hdpi version "HD" or something, then let the users work it out. On Dec 28, 4:40 am, NathanBarger <[email protected]> wrote: > I'm writing a game, and the apk is going to be around 25 mb. We want > to make 3 different versions of the game with each phone type: hdpi, > mdpi, ldpi. the problem being that if I support 3 phone types the > apk file will be 75mb. > I can't use the R resource file, I am wondering if: > 1. Does the android market support inputting multiple apk's based on > phone type. > 2. Can I turn on / off the build of certain resources in my code > without using the R resource file ( I have the names of actual > resource files being dynamically loaded.) > Any help is appreciated. > Thanks, > Nate -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
