Thanks for the feedback guys, Kostya, TreKing, Mark, each insightful ! As you rightly pointed out The multiple apk approach suffers from the fact that the tablet app cannot be positioned as a paid app. I guess if we use inapp billing, this can be made to work, probably even preferable.
I am also exploring the possibility of the library project approach. Seems doable. Also, we got guidance from the google folks, they certainly prefer one market listing, especially since the lines between what is considered a tablet and a phone is thinning by the day. Some phones these days have "tablet" screens and vice versa. One other general issue is the apk size. If all these features are offered as inapp pieces, the "free" app will have to ship with every feature built in, but "locked". This is both a security risk as well as a size impediment, dont want to burden free users with tablet size resources and layouts if we can avoid it. Seems like there is no easy way out here, is there ? Does the multiple apk approach only package resources that apply to the screen sizes supported ? Thanks! On Feb 17, 3:12 pm, Kostya Vasilyev <kmans...@gmail.com> wrote: > To build separate APKs while maintaining a more-or-less common code > base, look into using an Android Library project: > > http://developer.android.com/guide/developing/projects/index.html > > Market lets you upload multiple APKs for the same package name, > targeting distinct API levels or screen sizes. I'd recomment the latter, > given that Android 4.0 supports both phone class and tablet class devices. > > All of those are presented to the user as a single application, so I > don't think you'd be able to charge just for the tablet version - unless > you used in-app billing. > > Alternatively, you could give the tablet version its own package name, > essentially creating a separate paid app. > > -- K > > On 02/17/2012 11:55 PM, androidmediadeveloper wrote: > > > > > > > > > We are trying to come up with a tablet optimized pro product that we > > only want shipped in the market as a paid app. We currently do have a > > free app in the market which is doing fairly well. I understand there > > are package naming restrictions and even if we build multiple apks > > (phone and tablet), we wont be able to host them separately. From a > > tech perspective we want to just maintain one codebase given both > > flavors are going to share a majority of the functionality. > > > That leaves us with some "preprocessor" type step where prior to > > building the tablet apk, we create a new manifest, change the package > > name, change package names on all sources, and then produce separate > > apks. This is undesirable as is obvious. > > > Any ideas here ? Any lessons learnt ? Any advice ? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
