I do not have an Android phone and have hit a snag.
Google says you cannot test In App Purchases on an Emulator, details found here.
Install your application on an Android-powered device. You cannot use
an emulator to test Google Play Billing.
Question 1: Is this also true for the Genymotion emulator?
If this is truly the case, I guess I could not have in app purchases, and instead have two versions of the product. A Free, limited edition and a paid-for edition.
Question 2: If I have a solely paid-for version, do I need anything in my code that needs to be checked? By this, I mean the user can only install a paid-for version once they have paid Google Play. The actual program itself is oblivious that it has been paid for. Do I need anything in my code to indicate it is a paid-for version?
If the Android version sold, I would obviously get a physical machine. But at the moment, I do not want to keep on buying loads of different hardware just to keep on checking stuff.
Buying a phone is a personal decision, and you aren't going to get good advice on a programming site. You might be better to try https://android.stackexchange.com/, but even there, opinion based questions "what phone should I get" aren't encouraged as the stackoverflow / stackexchange sites are for things with right and wrong answers, not opinion. If I were you, I'd either do the research myself (if your time isn't valuable). If your time is valuable, I'd just go to argos and get the cheapest Android based phone you can which currently is £15 at Argos right now. (less cost than your time). There'll be something you don't like about it, probably many things, but at that point you'll know what they are and can make a more informed decision.
Related
I have an android app that is a counterpart to our software product that we sell to customers.
When we sell our product to a company, I need an easy way to give those users access to the app, including updates, product description etc.
The reason that a service like Google Play will not work is, that different customers require different versions of the app depending on their version of the main software.
Some customers are unable/unwilling to stay up to date, and we need to be able to give out different versions of the app depending on their version of the software.
Is there a way to set the max version of the app that a group of users are allowed to download?
This is a really good and difficult question. As someone who has worked on app targeting for many years on Google Play I've been racking my brains for the best way to do this.
The trouble is the completely different business models. Android works on the principle "buy the app once, get upgrades forever, usually automatically". Your counterpart computer software clearly works on a slightly different principle.
I can't think of anything that works well. Sorry about that. Some possbilities which are all broken in some way:
Have a different package name for each version of your app. eg com.myapp.v1, com.myapp.v2 etc. You could have the counterpart software provide the package name in a link to be helpful.This is bad because it punishes users who do upgrade, they have to manually install the new version each time. It also means reviews and ratings wouldn't all be associated with the app. It's a pretty terrible idea.
Make the android app versions always be backwards compatible with all versions of the counterpart software. We kind of do the opposite with the Google Play servers. Because we can't guarantee users upgrade Google Play on their phones, the server has to be compatible with almost every version of Google Play (and Android Market) ever shipped. It's a lot of work, but keeps users happy. You could make sure your app always works with old counterpart versions. You could always have a "sorry, you are getting a degraded experience because you haven't upgraded.
Sorry I can't help more.
Is there any service that can be used to monitor how a beta-user engages in an android application I made?
I've looked into different analytic solutions, but they all come with the disclaimer that I should not send "unique identification information about the users" - fair enough, and I can appreciate the privacy concerns. But I need to dig that information during my beta testing.
Currently, I'm emailing the apk files to a few people to install the app and test on their phones. They give me feedback, but not all of them are good at describing exactly what they are doing. I need more detailed information - like how they opened the app (was it a fresh open, or did they relaunch it from the running app list?), what exactly they did in the app and if possible, to get some debugging information too, since some issues are unique to the specific model of phone they use.
In a nutshell, it means that I need to dig into my beta-testers devices - and they all agree to it too, so its not like I'm spying on them or some such. (At the very least, I want to record their behavior in my app with permission)
Is anything like this available? If not, are there any other approaches I can use to solve/debug issues that generate from end-user behavior? (NOTE: I'm not talking about app crashing/hanging. The app is stable - its just not working correctly)
Stuff that doesn't seem to work:
http://acra.ch/
This looks more like a crash reporting tool than a usage/monitoring tool. :(
http://try.crashlytics.com/
Similar issues to above
Paid levels of BugSense come with a feature called Bread Crumbs, which I've never used but which sound like what you need.
I am going to have a alpha release of my app, which is not yet on the market. I want to have the app APK link sent out to friends via email so they can download it from my site CDN.
One question here: if I want to give them updates, what will be a good way? Can I download the new APK within the app, and somehow install the APK to replace the old one without anything to do with the market? So my friends can have the app upgraded while it is still in alpha release?
When I did it, I used Zubhium -- they were a web service with a small API that you could install into your app, giving you a mini "app store"-style backend and handling distribution for you. It would host and distribute your APK, connect up to their server when the app launched, check for updates, invalidate old versions, gather crash logs for you, etc. It was very good.
Zubhium are now https://www.vessel.io -- I presume they still have the above features as part of their now-much-bigger service, but when I checked you had to give them a credit card number even to sign up for the free plan, so I've not played with it.
A friend of mine uses http://testflightapp.com for iOS, and it looks like they have an Android version now, so that's certainly worth checking out. A quick search also shows up http://applover.me. #Janusz recommends http://hockeyapp.net/features in his comment.
As #Nanne points out in his answer, the Play Store itself now lets you distribute to limited alpha- and beta-test groups. That looks like it has fairly minimal features compared to the third-party services (no A/B testing, etc.), but will be familiar and free. And it doesn't need an extra SDK rolled into your app.
So, my general answer is that there's more than one professional beta-testing API/service that you could use, that they're generally very useful, quite easy to roll into your app, solve all the problems you're anticipating and more, and often have a free plan to get started. I'd recommend picking one of them rather than trying to roll your own solution.
If you want this only to be able to release your app in Alpha, and maybe later in beta, take a look at the android market again.
Check out this link: https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
It boils down to the fact that you can have an Alpha-test, and a beta test, each with selected users. You can upload your app as normal, so you'll have updates via the market, but not everyone can download your app.
For the beta at least, you can select a community that is the source of your users, so all that are in that community could be testers.
This is the best method for testing I believe.
I am working on a project that we use internally in the company. We have a single target device and at this time and that is the Google Nexus 7.
I need to find the quickest and least painful way to update the
android OS on every one of them (we are talking about a couple of
hundred of devices).
I am also looking for suggestions on how to distribute the app
version and updates afterwards. Updates are not something i want to
do through my app, that is implementing some code that will check
and download updates.
I already tried TestFlight which i feel takes too long to setup on each device,
Also tried Deploying through the Google Play beta program but the updates take too much time to show up, plus the setup is kinda wierd (i feel this is the best way to do it). i know of the google play enterprise apps distribution, but i need to have a google account linked to google apps and a developer account so i haven't tried that still.
I also was looking into https://www.push-link.com/ which seems interesting. Any alternative?
Any suggestions are really appreciated!
Thanks
AppBrain has a fantastic new app that lets you automatically install applications on your phone using your web browser. Similar to the Chrome push. In their case, they are using it to let you install apps without a prompt directly on the phone. Engadget has a good video demonstrating their system.
http://lifehacker.com/5582169/appbrain-upgrade-installs-android-apps-instantly-from-the-web
My question is: What mechanism are they using to avoid asking for a prompt on the phone and to do the installation directly?
The reason I'm asking is that have a couple hundred android phones that run some custom software, the users have to manually update the software by clicking through the install process. And ideally I'd prefer to be able to do push updates without having to prompt people (in exchange for a free phone+service you have to run the software, so 'you shouldn't do that' doesn't invalidate the question of how do you do that). The biggest problems are that if you're doing rapid development/testing it's a pain to get everyone up to the right versions and it's hassle for people.
What AppBrian does sounds like a perfect fix to this problem, but how does it work? The only permission the AppBrain fast installer asks for is access to your accounts and network access. Now, there was the interesting development about Jon Oberheide's REMOVE_ASSET and INSTALL_ASSET which he says uses the GTalk service to imitate prompt-less installs. The interesting this is that AppBrian's FastWeb installer works on a 2.01 Droid but does not work on a 2.2 Nexus One (maybe one of the last round of Froyo updates disables AppBrain's access to the INSTALL_ASSET intent).
http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/
Can anyone shed any light on this? I know auto update is coming for the Market but I'm not sure if this would be a usable workaround. I'm fine with saying 'you need to click to install this once', but having hundreds of people waste their time clicking 'ok' is a waste.
I personally think that this is something Google should support for Enterprise users in the future with the Device Administrator features. If I went with Android and could easily stage and keep people up to date with apps it wold be pretty useful.
So I think I have a reasonably good idea on how app brain is able to work its magic. I have found a couple of links you might find interesting and then you can always refer to the discussion on this other question.
Link 1: Here is a link on how the first app that was built by a researcher shows how a person with malicious intent can easily use two commands that google has put in for "our" convenience for silent install and uninstall...!!
Link 2:Here is how the exploit works and you could use it...