Re: [android-developers] Total User Installs decreasing
I'm not stressing, I'm just curious :) I don't understand how that number can go down. On Saturday, 12 January 2013 21:16:03 UTC, TreKing wrote: On Sat, Jan 12, 2013 at 2:59 PM, Iain King iain...@gmail.comjavascript: wrote: My total user installs on an app has gone down by 2 over the last couple of weeks. That's it? I've lost about 400. Don't stress about it too much - Google Play stats are notoriously unreliable. It's either a bug or change in the way they report stuff. We'll probably never really know. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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
[android-developers] Total User Installs decreasing
My total user installs on an app has gone down by 2 over the last couple of weeks. I have no cancelled orders or anything like that; anyone know how this is possible? -- 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
[android-developers] Gamepads and uses-feature
Are there plans to add a uses-feature for gamepads? What with a couple of third-parties making pads for android devices, and Nvidia's recently announced android handheld, the prospect of making actual game games for Android (and not just touchscreen friendly ones) seems to be becoming a possibility. However, you'd want to make sure that people without a pad didn't accidentally buy something that required one. -- 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
[android-developers] Re: OOM on Droid 4 / Razr / Razr Maxx (so: Motorola Android phones?)
Alternative solution: I've lowered the memory use of my app in the hopes of getting it to work on these handsets. Anyone with one (Droid 4, Razr, Razr Maxx) want to test my app to see if it runs? It'd be a massive help to me. You can find the installer at: http://www.onelivesleft.com/pigment/pigmentdemo.apk Thanks in advance! Iain On Thursday, 11 October 2012 14:51:50 UTC+1, Iain King wrote: Had a sudden influx of users recently, and from that I've discovered that my app doesn't run on the Droid 4 or the Razr. It seems that it runs out of memory, though the app runs fine on all other handsets (AFAIK), including much older handsets. For example, it runs on the HTC Desire, which has half the RAM of the Razr. I don't have any motorola handsets (or I'd just be debugging with them), and it runs fine in both the Razr and Droid4 emulated AVDs (from Motodev). Does anyone have an idea as to what is going on? Is there something up with Motorola's architecture? The Razr has a whopping 1gb of RAM, yet does this: java.lang.OutOfMemoryError at android.graphics.Bitmap.nativeCreate(Native Method) at android.graphics.Bitmap.createBitmap(Bitmap.java:631) at android.graphics.Bitmap.createBitmap(Bitmap.java:611) at com.onelivesleft.pigmentdemo.GameScreen.init(Unknown Source) at com.onelivesleft.pigmentdemo.LoadingScreen.update(Unknown Source) pause at com.onelivesleft.framework.impl.AndroidFastRenderView.run(Unknown Source) at java.lang.Thread.run(Thread.java:856) When run on a Razr the app will be loading exactly the same apps, creating exactly the same bitmaps (same resolution: 800x480. The only time it scales up for a higher-res display is the final blit to screen)... I just don't get it. Any help/info appreciated! Iain -- 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
[android-developers] OOM on Droid 4 / Razr / Razr Maxx (so: Motorola Android phones?)
Had a sudden influx of users recently, and from that I've discovered that my app doesn't run on the Droid 4 or the Razr. It seems that it runs out of memory, though the app runs fine on all other handsets (AFAIK), including much older handsets. For example, it runs on the HTC Desire, which has half the RAM of the Razr. I don't have any motorola handsets (or I'd just be debugging with them), and it runs fine in both the Razr and Droid4 emulated AVDs (from Motodev). Does anyone have an idea as to what is going on? Is there something up with Motorola's architecture? The Razr has a whopping 1gb of RAM, yet does this: java.lang.OutOfMemoryError at android.graphics.Bitmap.nativeCreate(Native Method) at android.graphics.Bitmap.createBitmap(Bitmap.java:631) at android.graphics.Bitmap.createBitmap(Bitmap.java:611) at com.onelivesleft.pigmentdemo.GameScreen.init(Unknown Source) at com.onelivesleft.pigmentdemo.LoadingScreen.update(Unknown Source) pause at com.onelivesleft.framework.impl.AndroidFastRenderView.run(Unknown Source) at java.lang.Thread.run(Thread.java:856) When run on a Razr the app will be loading exactly the same apps, creating exactly the same bitmaps (same resolution: 800x480. The only time it scales up for a higher-res display is the final blit to screen)... I just don't get it. Any help/info appreciated! Iain -- 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
[android-developers] Re: OOM on Droid 4 / Razr / Razr Maxx (so: Motorola Android phones?)
When run on a Razr the app will be loading exactly the same apps *When run on a Razr the app will be loading exactly the same assets -- 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
[android-developers] Re: reduce size of a screen
On Sunday, 27 May 2012 08:31:01 UTC+1, baturanija1 wrote: Hej people,i am making an application wich screen has a good dimension for my phone-HTC DESIRE .there are othes phones who has smaller or bigger screen...so i am asking is there an option to makk app to automaticly reduce a size of a screen for all size of telefon screen? Thanks for reading :) The HTC Desire is my main dev target for games. What I've done/found (this is very hand-coded): Using a SurfaceView for output. I develop all my art assets for 800x480 (Desire native). When the app starts it works out the aspect ratio of the phone's screen, and then works out what the equivalent Desire res, depending on the orientation I want. For example, if I want Landscape: I take the phone's physical short axis in pixels and work out it's ratio to the desire's 480. I then multiply that by the phone's physical long axis: I now know I'm rendering to something N x 480 pixels. Theoretically I then render to a bitmap that size every loop, then blit that to the screen, scaling to the physical screen size. Here's where it gets tricky: If the screen is larger than the Desire's, you need to blit it with anti-aliasing on in order to make it look good (this isn't hard, you just need to know to do it). If the screen is smaller than the Desire's you're probably gonna run into trouble: the available heap scales on a per phone basis depending on the screen's resolution. If you are storing all your bitmaps at 800x480, but are on a phone that is only 320x240, then you are probably going to run out of memory and crash. Therefor, on startup, you check if the physical screen is smaller than your target render, and if it is you scale down your internal bitmaps, and you scale down all your assets as you load them. So instead of rendering to an N x 480 bitmap then blitting it to the SurfaceView, you render to an N x 240 (in this example) bitmap and blit it. On smaller screens you don't need anti-aliasing: you are down-sampling so it should be fairly good without it. Examples: ARCHOS 101 tablet, 1024x600 resolution: scaling the 600 to 480, this gives 819x480. I load all my assets normally and render to an output that size, then blit that to the screen, scaling up with anti-aliasing turned on. HTC Wildfire, 320x240 resolution: 240 / 480 = 0.5: when I load all my graphics assets I scale them down to half size. I render to a bitmap that's 320x240 in size and blit it to screen without antialiasing. That's the simple approach. On top of that you have to work out how you handle aspect ratio changes: do you just scale and thus skew the output, or do you render more stuff on widescreen and chop the edges off for 4:3. Using this method you only need one set of art assets (as opposed to the normal Android way of including different versions for different pixel-densities). As such, it will basically look less-good the further the screen it's running on is from the target screen (800x480), but in my experience it is well within acceptable bounds, and the pros outweigh the cons (ease of development, unbloated .apk size). Note that this is for game development, using fullscreen and rendering everything by hand. If you were using the Android UI normally I doubt it would be as good a technique. Iain -- 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
[android-developers] Re: Repeat background
On Monday, 28 May 2012 10:38:01 UTC+1, Kristoffer wrote: Hello. Iam using a small image and repeats it as a background in my app, this is how i do it. bgrepeat.png backgroundrepeat.xml i have them in the drawable folder. This is how the .xml look like. bitmap xmlns:android=http://schemas.android.com/apk/res/android; android:src=@drawable/bgrepeat android:tileMode=repeat android:dither=true / And i just call in in xml like this. android:background=@drawable/backgroundrepeat If i run this on my Galaxy S2 then the background repeats and looks good, but if i try on a tablet (galaxy 8.9) then it does not repeat it just zooms the bgrepeat.png file, and same result in emulator on my pc. I need to know that this will work on most devices, and why it doesent work on every device.. bug? Any idees? I'm not sure if this is your issue, but I had a slight glitch on a tablet: the tablet had a user controlled scaling thing to 'help' it better run phone games. My app automatically detected the screen size and scaled itself accordingly, but if the tablet's scaler was turned on then it messed it up. The user report was: --- Had a slight issue with the background image not filling the screen but was easily resolved by changing settings from stretch to fit to zoom to fit --- Same issue? Iain -- 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
[android-developers] Re: removing image data from memory
Bitmaps have a recycle() method. I don't think that will fix the problem, I'm replying with it only because you haven't specifically listed it. I was using it, and like you have said: it helped a bit but did not solve the problem. I'm afraid I'm making sure I don't get an OOM crash by calling System.exit(0) whenever the user switches away from my app - means it takes a couple of seconds for them to get back in, but I rate them not seeing the app crash above instant-access. I realise that doesn't help you - I was crashing on Resume, whereas you are running out of memory during operation. Hope you come up with something! Iain On Monday, 30 April 2012 19:15:02 UTC+1, momo wrote: I have to believe there's a way to clear image data from memory once it's no longer required, but despite exhaustive searching I can't find a solution. Both this list and stack are full of questions regarding OOM errors, specifically bitmap size exceeds VM budget, but I still don't see a clear answer. I understand there are hard memory limits on devices, and I understand it's not realistic to load up and display or cache large amounts of image data, but there should be away to discard data that's no longer required. For example, imagine this very basic hypothetical app, that emulates a lot of the behavior of the native gallery app: 1. An image gallery that allows the user to peruse images from a remote server. 2. There might be any number of images on that server. 3. The app displays 1 image at a time, and allows a user to go back or forward 1 image at a time through button presses or swiping. 4. There'd be a maximum of 3 images rendered at any one time (so the user can see the one immediately to the left or right of the current image when swiping). All other image data should be discarded. 5. Images are loaded using URL.openStream and Drawable.createFromStream or BitmapFactory.decodeStream. Streams are closed appropriately. 6. Images are sized appropriately *on the server* before being fetched. 7. Loading happens in AsyncTasks. Tasks that are no longer needed (due to moving away from an image with an incomplete task) are cancelled. Any references in the AyncTask are WeaklyReferenced. 8. When any image is no longer required, it's cleared via: A) getBackground().setCallback(null) B) Listeners are set to null C) setImageDrawable/Bitmap(null) D) removeView This simple construct, that takes into account all the suggest practices I'm aware of, will inevitably crash with an OOM error at some point. Using BitmapFactory.Options inSampleSize and inPreferredConfig will delay the inevitable, but not forever, and at the cost of image quality. In this example, I've used remote images, but the issue exists with images stored in /assets/ or in internal memory, etc. My feeling is that if we can display X amount of image data at one point, and we take all steps to remove that image data from memory, we should be able to display that same amount of data later, without having to compensate for what has happened before. With the sheer quantity of questions about this very issue, I'd hope to have a standard solution documented, but if there is one, I can't find it. I've seen answers posted by Romain Guy, who otherwise seems very generous with his knowledge and active in the community, that say something like Simple. Don't use so much memory. OK. Tell me how. Am I missing something fundamental? Is there a way to discard image data once it's no longer being used? What is missing from the above to create a simple photo gallery? Assuming the built-in gallery app uses the FW, I imagine there has to be a way... TYIA. -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Thursday, 12 April 2012 15:27:29 UTC+1, latimerius wrote: On Thu, Apr 12, 2012 at 2:34 AM, b0b wrote: Would it also be possible to initiate the LVL check from the free app? Not possible. You cannot add the request LVL permission to a free app. Hmm, that's kind of silly. Obviously, it makes no sense to LVL-check a package that's free in the first place, however this should not depend on the package that is asking but the package being asked about, right? The solution described by MagoutaWare works very well. In theory yes, but although I'm most definitely not too much of a cracker, I'm confident I could disable a security check that's alone in its executable in a matter of minutes. :-( This sounds like a borderline showstopper to me, I'll have to consider whether it's actually even worth bothering with LVL under these circumstances... You know, that's not a terrible idea. You can still release stuff on Play without implementing LVL, right? Or even if you can need some, you could implement token code that does nothing. Iain -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Thursday, 12 April 2012 16:26:37 UTC+1, latimerius wrote: I too consider not protecting the app at all a valid option. However, ideally I would like to have something to deter the more simple-minded cracking attacks. Anti-copying protection seems to follow the 80/20 rule quite often - confusing and annoying the army of script kiddies or attackers who are not very knowledgeable or motivated doesn't cost you all that much. The rest you'll have to bow to anyway. And I too agree that user convenience weighs more than good anti-copying measures. Which is why I'm considering, if I can't do LVL under the free/paid app scheme properly, it might be better to avoid it altogether. Because pretty much anytime you use a protection scheme, you run a risk of annoying legitimate users - and running that risk doesn't seem to be worth it for a protection that doesn't even protect very much. Not being able to obfuscate and hide LVL code in other code is quite a big deal here - under the particular circumstances (all of your code and assets live in untrusted environment) obfuscation is your front-line security measure. Without it, your security core (the LVL check itself) becomes exposed and vulnerable. I'll have to think about this some more and weigh carefully pros and cons. 2012/4/12 Kostya Vasilyev kmans...@gmail.com: I'll try to throw in a few more two cent coins :) 1) Hackers and piracy, pt1. Some people on this list have stated that they've chosen to not implement LVL for a paid app, and to spend that time improving the app. There is certainly nothing wrong with that decision. 2) Hackers and piracy, pt2. Not every user is going to search for a cracked copy of a paid app they would like to have. Some just press Buy, even when there is a cracked version somewhere. Of those, I suspect some consciously do it to support the developer, some don't realize there are sites with cracked apps, some are worried about malware and so install from the more official source (Market), some do it for the convenience. 3) Base app + unlocker key vs. limited free + full paid apps. There are apps in Market that use either approach, and at this point, I believe both ways are well understood by the users (at least the type who can find the Menu button on their phone... some can't...). I would look at how the users are going to transition from the free/base app to the full/unlocked app with as little interruption as possible. If the app is such that the user spends a lot of time setting it up (the free/base version at first), I'd either: - go with the base/unlocker approach so that the data stays intact - provide a really easy, preferably automatic export / import or transition capability -- K 12 апреля 2012 г. 18:35 пользователь Justin Anderson написал: In theory yes, but although I'm most definitely not too much of a cracker, I'm confident I could disable a security check that's alone in its executable in a matter of minutes. :-( An experienced hacker could pretty much do that no matter what you do... Thanks, Justin Anderson MagouyaWare Developer http://sites.google.com/site/magouyaware On Thu, Apr 12, 2012 at 8:31 AM, Iain King wrote: On Thursday, 12 April 2012 15:27:29 UTC+1, latimerius wrote: On Thu, Apr 12, 2012 at 2:34 AM, b0b wrote: Would it also be possible to initiate the LVL check from the free app? Not possible. You cannot add the request LVL permission to a free app. Hmm, that's kind of silly. Obviously, it makes no sense to LVL-check a package that's free in the first place, however this should not depend on the package that is asking but the package being asked about, right? The solution described by MagoutaWare works very well. In theory yes, but although I'm most definitely not too much of a cracker, I'm confident I could disable a security check that's alone in its executable in a matter of minutes. :-( This sounds like a borderline showstopper to me, I'll have to consider whether it's actually even worth bothering with LVL under these circumstances... You know, that's not a terrible idea. You can still release stuff on Play without implementing LVL, right? Or even if you can need some, you could implement token code that does nothing. Iain -- 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 -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Thursday, 12 April 2012 16:26:37 UTC+1, latimerius wrote: I too consider not protecting the app at all a valid option. However, ideally I would like to have something to deter the more simple-minded cracking attacks. Anti-copying protection seems to follow the 80/20 rule quite often - confusing and annoying the army of script kiddies or attackers who are not very knowledgeable or motivated doesn't cost you all that much. The rest you'll have to bow to anyway. And I too agree that user convenience weighs more than good anti-copying measures. Which is why I'm considering, if I can't do LVL under the free/paid app scheme properly, it might be better to avoid it altogether. Because pretty much anytime you use a protection scheme, you run a risk of annoying legitimate users - and running that risk doesn't seem to be worth it for a protection that doesn't even protect very much. Not being able to obfuscate and hide LVL code in other code is quite a big deal here - under the particular circumstances (all of your code and assets live in untrusted environment) obfuscation is your front-line security measure. Without it, your security core (the LVL check itself) becomes exposed and vulnerable. I'll have to think about this some more and weigh carefully pros and cons. You've pretty much summed up what I was thinking. Iain -- 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
[android-developers] Demo/Full Game options on Google Play
In the near future I'll be releasing a game on Google Play: both the full game (costed) and a free demo. The LVL license model looks good for this: when I check whether the user is licensed to play the game I can have it fully available if they've bought it, or switch to a cut-down feature set if they have not (i.e. a demo). My question is: does the Google Play store support this? Can it provide both a Buy and a Try button? Buy gives them the license and downloads the app, Try just downloads the app? I've had a look, but for any given app have only found a single Install/Buy button. Everyone who releases a free version seems to do it by releasing two different apps - I'd rather avoid that if I can. So: does Google Play have this built in? If not I'll happily go suggest it on their site: wanted to make sure I wasn't missing it first. -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Wednesday, 11 April 2012 12:47:30 UTC+1, Mark Murphy (a Commons Guy) wrote: On Wed, Apr 11, 2012 at 7:39 AM, Iain King wrote: Everyone who releases a free version seems to do it by releasing two different apps - I'd rather avoid that if I can. Then use in-app purchasing. Only distribute the free app, and have the app upgrade itself to paid (e.g., unlocking features) if the user buys the upgrade through in-app purchasing. The separate free/paid apps are for cases where you do not want to use in-app purchases for the upgrade, and for apps written before in-app purchases existed. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ On Wednesday, 11 April 2012 12:47:30 UTC+1, Mark Murphy (a Commons Guy) wrote: On Wed, Apr 11, 2012 at 7:39 AM, Iain King wrote: Everyone who releases a free version seems to do it by releasing two different apps - I'd rather avoid that if I can. Then use in-app purchasing. Only distribute the free app, and have the app upgrade itself to paid (e.g., unlocking features) if the user buys the upgrade through in-app purchasing. The separate free/paid apps are for cases where you do not want to use in-app purchases for the upgrade, and for apps written before in-app purchases existed. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ That would work, but I don't like the user experience: their first interaction at the store is to see Install (Free), and then their first interaction in the game is to see Buy me now!!!. I take it you're confirming that Google Play doesn't as yet do what I was asking? If so I'll probably go down the two-app route, (and go post a suggestion to them). Thanks! -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Wednesday, 11 April 2012 13:04:51 UTC+1, Mark Murphy (a Commons Guy) wrote: On Wed, Apr 11, 2012 at 7:56 AM, Iain King wrote: That would work, but I don't like the user experience: their first interaction at the store is to see Install (Free), and then their first interaction in the game is to see Buy me now!!!. Then don't do that. You are the one coding the Buy me now!!! stuff. If you do not want that to be the first interaction, don't make it be the first interaction. I take it you're confirming that Google Play doesn't as yet do what I was asking? I have never seen it, nor do I see where it would be possible. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ You don't see where it would be possible? Fair enough. -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Wednesday, 11 April 2012 16:06:58 UTC+1, MagouyaWare wrote: I have an app that uses two apk's... One is the free one, and the paid one acts as a plugin to unlock features in the free one. I developed this before in-app purchasing was available, but I don't know if I would have used in-app purchasing had it been available for use due to all the drama with patent trolls (you know who you are Lodsys)... But what worked for me was this: 1. Put ALL functionality in the free app 2. Give both apps the same sharedUserId (there are some unintended side effects of this, and Dianne Hackborne often recommends you don't use it, but I think it is a good fit for my case). 3. Put all the LVL code in your paid app... When the license check happens, set a preference value (encrypted) indicating whether it succeeded or not 4. Create a service as part of the paid app that your free app can call to initiate the LVL check 5. In your free app, read the same (encrypted) preference that is set in the paid app to determine if you should run in free or paid mode It seems like a bit of work but it wasn't all that hard to actually implement. My paid app actually does nothing other than the LVL check through the service. It has a launchable activity in case users get confused but all it does it launch the free app and quit. On a side note... Does anyone know if anything has gotten resolved with the in-app purchasing fiasco with Lodsys? I know Apple contends that their developers are safe because their license covers them... I haven't heard of anything official from Google though... Thanks, Justin Anderson MagouyaWare Developer http://sites.google.com/site/magouyaware 2012/4/11 Kostya Vasilyev And to add two more cents: in-app items don't show in the user's purchases list in Market... scratch that, Google Play application on the device. Sometimes this raises questions about whether they'd have to be repurchased - even though they don't, obviously not every user understands this. -- K 11 апреля 2012 г. 16:42 пользователь Latimerius написал: On Wed, Apr 11, 2012 at 1:47 PM, Mark Murphy wrote: On Wed, Apr 11, 2012 at 7:39 AM, Iain King wrote: Everyone who releases a free version seems to do it by releasing two different apps - I'd rather avoid that if I can. Then use in-app purchasing. Only distribute the free app, and have the app upgrade itself to paid (e.g., unlocking features) if the user buys the upgrade through in-app purchasing. Be aware though that in-app purchasing doesn't take care of content delivery. In practice, that makes it quite a different beast from the two app model if you have content to deliver in response to purchase. -- 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 -- 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 Doesn't that end up with your user ending up with both apps installed anyway? So at some later time when they are trying to clear up space, they still see YourGame Demo is installed, and nuke it? Probably not that big an issue, but might be unexpected for them. Regardless, it still requires you to build 2 different apps, which is the main annoyance for doing it that way. Definitely better than In App (which looks fiddly and much more likely to foul up than basic per app authentication), but if I'm going 2-app I'm gonna keep it simple. Iain -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Wednesday, 11 April 2012 16:22:11 UTC+1, latimerius wrote: 2012/4/11 Justin Anderson My paid app actually does nothing other than the LVL check through the service. Would it also be possible to initiate the LVL check from the free app? Client-side security has to rely on obfuscation to some extent, otherwise the attacker can simply find and disable the LVL check. From what I understand the LVL code should ideally be intermingled with unrelated code - but if it resides in an executable pretty much by itself, doesn't it mean the check is easy, perhaps even trivial to circumvent? I'm also leaning towards the two .apk solution but I thought I'd be able to run the LVL check for the paid app from the free app. One thing you could do is create the app as normal, put it on Play as a paid download (and have it function as a demo when not licensed), and provide a link to the .apk on your own website, with a prominent link on the Play page. Not as nice as if Play offered it for download intrinsically, and you'd probably run into trust issues with users unwilling to install an app from a 3rd party site (and it would require them to toggle the switch in settings to run too, wouldn't it?), but would basically allow for having 1 app do both jobs. Iain -- 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
Re: [android-developers] Demo/Full Game options on Google Play
On Wednesday, 11 April 2012 16:37:24 UTC+1, MagouyaWare wrote: Doesn't that end up with your user ending up with both apps installed anyway? So at some later time when they are trying to clear up space, they still see YourGame Demo is installed, and nuke it? In my case no, because I don't market it as a trial version... I market it as AppSwipe! Task Switcher and AppSwipe! Unlock Key http://groups.google.com/group/android-developers?hl=en Ah, that's nicely thought out. -- 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
[android-developers] Sharing private data between apps of differing permissions
In order to minimise the required security for my apps I would like to split them into 2: the core app which has effectively no required permissions, and a manager app which will have internet access/write to SD/etc permissions. That way users can happily install the base app without having to grant anything, but opt into the advanced features with the manager if they want to. I'd rather not use the external storage to store data, so what methods can I use to get information from the core app to the manager? It looks like SharedPreferences and SQLite don't allow access from another app (even one from the same developer). Storing to Internal Storage? Any problems with that? Links to examples would be appreciated! -- 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
