Develop Reference

Can I build this quiz client app?

I've been programming for over 20 years, but mostly in the VB and SQL. As a side job, I host game shows at local bars and restaurants (Trivia, name that tune, etc.) and I'd like to develop an android app that I can install on mobile devices to give to customers to interact with the game.
I'm trying to make the game shows more interactive than just pen and paper (and time-consuming, manual scoring). I can get Kindle Fires for $40 each, so I thought it would be cool to create an app that will allow the user to do 3 things:
Choose an answer from a list (Multiple choice), and everyone can answer
Buzz in (blocking other users out)
type in an answer
I'd like the tablets to send the responses to a central "hub" or application that will record the answers so it can automatically do the scoring for me. If possible, I'd prefer to be able to have everything connect through an ad hoc wifi network that I would set up on site (that part I know how to do, too).
I'm not looking to have the questions appear on the phone at this point; I have an office-based application that automates a powerpoint presentation based on questions/answers and other parameters imported from a database/spreadsheet. (VBA is nice and easy for me.)
Ideally, the quiz questions would work like this:
I project the answer where everyone can see it.
After announcing the questions, the tablet apps are "activated" and
the user can then select their A, B, C or D answer (or buzz in, or
type an answer depending the type of questions/quiz).
My hub application would then receive the following information:
team/player name, answer choice, time it took to answer the question
(because I'm thinking of using a points tier that gives faster
players get more points, either based on time ).
The catch is, I don't even know where to begin from an android development standpoint, as I have no experience in that realm. In most programming cases, I know keywords to search on, but I'm totally flying blind here.
Does this seem like a feasibly application? There are systems online that I can buy, but the buzzers are expensive and the software has some significant limitations that prevent me from spending the money. I'd rather develop something myself and spend $40 per client unit and load it up with my software.
(Then, of course, license the whole kit and kaboodle and make a mint and retire in 5 years, living the good life off of my pub quiz empire...)
So, if you have any suggestions on starting points, or specific methods and processes to being fiddling with, an IDE...any help would be greatly appreciated. Once I'm up and running, I will reward you with extra points if you ever come to one of my events.

Go full kotlin !
Android works well with Kotlin and you can have a server quickly setup with : https://start.spring.io/#!language=kotlin
https://kotlinlang.org/docs/tutorials/kotlin-android.html
A good client for Android is provided here :
https://github.com/square/retrofit
You will probably have hard time to get started. Using same language for every part of the system will make things easier.
Also, Kotlin is less verbose than Java and will prevent you to make the usual mistakes found in Java world.
Also, if you create an open source project out of it, you may be eligible for IntelliJ.
Your very first stop is : http://try.kotlinlang.org/#/Examples/Hello,%20world!/Simplest%20version/Simplest%20version.kt
Get to know the language by trying it out. When you are in ease with it, start looking at Anko (https://github.com/Kotlin/anko).
To do the project in an easy way, break it down in milestones.
Simple app which shows 4 buttons (choices) and shows a message for each button. (Eg. you clicked "1")
Small server with spring boot. It should display whatever you post to it. (An "echo" server)
Improvement of the simple app to POST something to the server and display the answer in a dialog.
At that point, you application is practically done! You would have understood enough to complete it. The hardest thing would be behind.
Don't think your are smarter than the flock. Do these milestones, at least. You will be thankful to yourself.
This post may seems unrelated, but I explain how good Kotlin can be in such projects : https://www.linkedin.com/pulse/why-do-android-projects-cost-less-than-ios-christian-baune

Why my app is as "hidden" on Google play?

First sorry for my bad English : I'm French and I may make a few mistakes.
I created an app and I uploaded it last month on the Google Play store. You can find it here without problems : https://play.google.com/store/apps/details?id=com.malerbati.fourInAMine.
The problem is : my app is almost impossible to find with the search engine ! When I search "4 in a mine", my app name, in Google Play, it only appears at the 20th result !
Besides, the app didn't appear at the "Top news" when I uploaded it.
I remember that the last app I created counted 200 downloads 1 day after its release, obviously thanks to the "Top news" thing... whereas this app has only 65 downloads, 1 month after ! And when I look at the statistics, I see that 100% of the downloaders are French (my country), which means that ALL the persons who got my app found it with word of mouth ! That's quite inefficient...
Therefore, here are my questions : why the hell can't we see my app easily, like the others ? Did anyone else encounter the same problem ? I have some suppositions about the origin of the problem :
The last app I created was a big failure : 95% of the people uninstalled it, essentially because the game was too hard. Does Google Play search engine take this into account ?
I created my last app last year. There must be much more apps now. Is my app simply hidden by the (too) big number of other apps ?
My app is very smaller than the last one (only 300 ko, against 3 Mo). Is that taken in account too ?
Thank you in anticipation. I really want to know where the problem is.

Here are a few resources to help:
How Android Developers Can Thrive with Google Play
Maximize search potential in your app title: identify your most successful keywords and make sure to include them in your app title. In fact, this is so critical to success (potentially 80 to 100 places in your search ranking), that you should seriously consider removing your app name from your title and focus your description on the best keywords. Include the app name in the body of the app description – users will still be able to find it by name. Unlike iOS, the body description is searched under Google Play.
Use, but don’t overuse, keywords: try to use the best keywords at five times the body of your app description. This can affect search ranking from 10 to 20 places. Anything over five times has no additional benefit, so don’t overdo it.
Test your search parameters: the above recommendations are guidelines based on accumulated experience, but search results can vary based on many factors.
Steady efforts work best: Google Play’s ranking algorithm is tilted towards long term user acquisition – apps that acquire and retain satisfied users are rewarded with higher ranks. Advertising campaigns should be run over a longer term and sustained over two to three months, as opposed to the short bursts of activity often seen in the iOS market.
Use closed loop attribution and target long term users: since retained users have an important impact in ranking, use closed loop marketing to ensure you are identifying and utilizing ad sources that bring loyal users.
Don’t be afraid to experiment and test market your strategy with Android. You can apply these learnings to your iOS versions and reduce your costs and risks.
Google Play Optimization Secrets - 5 Helpful Tips
The second link contains more information that leans more towards marketing and sales strategy than practical steps.

Your application contains a number of very common words. Some of the most common, smallest little auxiliary words are probably discarded because they return a hit on everything.
If you put quotes around it, then Google Play will search for the whole sequence. When I search 4 in a mine then I basically don't see your app. When I search "4 in a mine", then your app is the only result.
I understand that this information doesn't really help you because, while it answers your question, you cannot control users' behavior. You would do better to make your title unique. That of course also makes it less descriptive and harder for users to remember. It's an unavoidable tradeoff.
Responding to your other questions:
I would be surprised if the success or failure of your other game had anything to do with the search relevance of this one. I could believe the uninstall rate affects the search relevance of the uninstalled title.
The huge number of new apps being published does mean that you want to get onto the virtuous cycle of installs quickly. So, the same day that you upload the app, get onto your social networks and tell all your friends and followers that you have a new game to try out. Make sure it works on most of the devices they are using. :-)
A listing page that describes your app well helps you get some collateral benefit from the "Users also viewed" lists for searches that lead to similar games. You gain a little more collateral benefit by publishing additional apps that appear under "More from developer". It may not be a big boost, but it is a feedback path -- probably the only one that you directly control.
I would be surprised if app size made any difference at all.
To sum up:
I think your problem is your title is composed entirely of either tiny words that get discarded, or common words that match lots of other games. You can easily locate your app by searching for the phrase all in one piece, but users won't do that. So work on combining unique terms that only you use, with descriptive terms that help the search engine determine your relevance in searches. And follow it up with some marketing.

What are "entry points" and "exit points" when referred to reverse engineering?

The tips in the Security and Design document for Android's In-app Billing state that:
In particular, attackers look for known entry points and exit
points in an application, so it is important that you modify these
parts of your code that are identical to the sample application.
Since I am going to use In-app Billing for the first time, I am very much interested in understanding what this means exactly, in terms of securing my subscription-based app:
What are exactly those "known entry/exit points"?
What do I need to modify in these parts, to make the task of an
attacker more difficult?
Given the fact that nothing can be protected from eventual reverse-engineering, is it really worth it to go to such great length to protect an
application/service?

I think that document is talking about the methods that are standard in Android for starting an application, namely the activity lifecycle methods (onCreate, etc.). These are easy for attackers to find because they aren't obfuscated (since the framework needs to be able to find them).

Given the fact that nothing can be protected from eventual
reverse-engineering, is it really worth it to go to such great length
to protect an application/service?
This is indeed an interesting question! To answer it one also has to ask: What is the expected cost of not protecting the app?
If the items sold via IAP incurr an actual cost for the provider/developer (think for instance of selling MP3s where for each download the provider might have to pay a license fee himself) this becomes even more important. This usually indicates the the possible win for an adversary and, thus, the effort he may be willing to invest in reverse engineering.
However, my impression is that there is only a marginal "black market" for cracked/pirated/... apps, the rationale being that it is not possible to offer those cracks or cracked apps via Google's market, which is the only one that comes pre-installed on all Android phones. Regular users will never see any other source of apps.
So, if you expect to sell a bigger volume of your app, you might well live with, say, 1% fraud by "power users". If your app is somewhat special and pricey and you expect to sell only a couple dozens or hundreds, you will be more interested in securing your intellectual property.
The first step in securing will always be obfuscation, which will take your app's security pretty far with (almost) no additional effort on your side. I recommend to obfuscate every app published if there are no strong reasons against it (stacktraces, for instance, may become completely useless in an obfuscated app).

At a fairly basic high level, entry points are where the application is started and exit points are where it ends. Each of these (as mentioned above) are unprotected and also tend to make some calls which aren't made anywhere else, making them easy to find and change.

Android Scoreloop, OpenFeint etc al

I am looking to use one of the social networks in my Android program.
Most important for me is the ability to build a continuous leadership board in which players move up and down depending their wins/loses to others.
The idea is for players to challenge others head-to-head. The winner gains points and the loser loses points.
Equally important, I want this feature to include the possibility to "charge" the player game coins.
Scoreloop includes the possibility of challenges but they are there in order to win coins off other players. In other words, they are the means to the end.
In my case I need it to be the other way around. The "ends" is to be higher in the leadership board and the "means" are to play others with coins.
Scoreloop do have a continuos leadership board but it is not accessible from the program.
I tried looking at OpenFeint but their site is a real mess. It is impossible to understand from there exactly what is and isn't available.
I signed up and tried to add my program. I ended up adding it four times and cannot delete it!

Check out Swarm, which provides a similar feature set to the others you mentioned (Scoreloop, OpenFeint), but also specifically includes a virtual goods system (coins), that you could use to have users purchase challenge attempts (which sounds like what you're looking for). The docs are extremely well written, integration is a snap :)

Create a leaderboard using either OpenFeint or Scoreloop (we started off with Openfeint but quickly moved on to scoreloop - If you want the details, I'll be happy to explain our reasons).
Once its up, make sure its a leadarboard that allows overriding scores with worse scores.
Implement an ELO rating calculator. see: http://en.wikipedia.org/wiki/Elo_rating_system
Each player starts with a certain score (I use 1500, so that ratings will resemble the chess ratings range).
On a match end, you re-calculate each user's new Elo rating, and post it to the leaderboard.
You end up with a leaderboard that ranks each user according to their skill. i.e. the more they win, the higher their score is.
EDIT: per user request - her are some of the reasons that made us move to Scoreloop:
OF documentation looks like it was ported from iOS, and very badly so. For example, the docs gives an example of initializing OF in your Application class. This will cause their "Join / Don't like fun" full screen dialog appear out of the blue, when users are busy using other applications, as android will kill and re-create your application in the background as memory availability change.
ScoreLoop automatically creates a "userId" for the user, without them having to register / login. This allowed us to post user's highscores and display their highscores without having to bother the user for logging in.
Scoreloop have an "offline" mode, which makes it much more robust, efficient, accurate and easy to use.
In flaky network situations, OF login process took a very long time, and affected the game performance. (see #3 above).
OF does not allow you to fetch a score rank. If you want to get your user's rank, you have to fetch the complete leaderboard, cycle through it until you find your user's entry. This "solution" pretty much makes this option not-available.
Scoreloop provided us with grate support. I've opened several tickets, they all got answered promptly and professionally. These guys rock.
I wrote this code a while back, so there might have been other reasons which I forget.

Android Game Keeps Getting Hacked [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
So we've been through this several times now, we release a game (for cheap) and someone hacks it and puts it up on a mirror. We setup Google Alerts for all our apps, so we get told daily who's doing the hacking. So far, we have implemented the licensing service as Google has suggested, our salt is randomly made each time the license is initiated with the unique device ID. We run the check service once, when the application is started for the first time. We then generate a 512 character hash for the key and the stored value that is compared against in SharedPreferences from there on out.
Now, I know that checking once is probably where the application is being blocked. Our bytecode has most likely been looked at and recompiled without the line that initiates the check.
From here, I don't want to obfuscate our code as I have seen it broken before. I want something a little more solid, and I also want to learn how to do this properly. I am more interested in learning than making money at this point since only 2% of people will ever look for a hacked version.
So far, on my own, I have come up with a random number generator that is placed in several startup areas of the game. When initiated (say, 1 out of 50 times) the license is checked. I know this would make it harder to hack because the cracker would have to eliminate each case, compile, eliminate, compile. This method however, is still crackable...so what do you guys suggest? Again, I am really interested in this process of security, so please educate, don't turn this into a discussion on obfuscation or checking periodically based on a timestamp.
Thanks

My idea isnt hacker proof, but might remove some of the interest for hacking the game.
Freemium model
1) Make the first 5-10 levels free so people can learn the game and have some fun without paying. Less will want to hack the first level and the game will spread even further by Freemium model.
Shareware/clustered levelpacks
2) Let part of the game levels or logic stay online. Eg. when reaching for level 5 or 10 or 15, then download small parts for the game, and every time submit the progress-log from the game and validate this against possible values + hashcodes. This could perhaps make it possible to automatically close down of hacked accounts.
Stealth cheater protection
3) You could also just count "small warning flags" that you place around in the game. Dont just check for the "validation" in the beginning, no build these flags into the game logic itself. Dont make it break the gameplay, because then noone will look for it.
Then when the user reached the end of level monster, check if there were any logged warning flags. These will not show up inside the game, so the unknowing user with a hacked edition could be playing for hours/days and suddently realize that he/she couldnt finish the game or advance to next level, because the game had a "bug". What the user didnt know was that this bug only occures on hacked clients.
Conclusion
Be smarter than the crackers. Fool them into thinking the job was done. Make a copyprotection and know that the more advanced crackers will be able to remove it. But they probably dont want to play 50 levels to check if the crack also works all the way.
Once they realize this problem, they might start to crack it too. But if you break the game up into level-packs, you can still validate between each pack download. So once you receive hacked client hash data, then just execute an exeception and crash the game on the client. Whoops the game crashed. Dont tell its because its hacked. A program error can happend. :-)
Again, its not hacker proof. But it might annoy them enough to move on to the next game. Lastly, you could also put out regular updates for the game and only the latest version should be able to "post the records" etc. so the active users would have to update to keep in the loop.

I have been doing some apk decompiling and hacking for a while (not warez, but mods and hacks mostly to the google apps and the android framework, always abiding xda-developers policies).
Once you learn to read smali, it is almost as reading the original java code (but with way more LOCs). So, any code you add to check for keys can be found and deleted or replaced. You don't even need to recompile each time to eliminate more than one (some searches do miracles to find similar pieces of code) and, even if compilation/recompilation cycles are needed to find them, it's just a matter of one or two minutes to decompile: everything is automated by apktool and even more by apkmanager.
Having said that, my suggestion to you is to implement some sort of online scoring table or similar, and when the user looks at the score table online, you can check the hash code you implemented and compare it with the associated gmail account. That way you can report the hack to google and send a nasty message to the user of the warez, explaining why that is illegal.
Of course, a new hack could be implemented to eliminate the scoring table, but that would reduce the interest for the warez.
Good luck.
Update
After researching to answer this question: Injecting code into APK (really about the Amazon DRM mechanism), I can tell a little bit on how Amazon is protecting the apps: it includes methods for checking for the installation validity everywhere (you can see an example of how they do it in my answer to that question). This will make any attempt to hack an app not very difficult, but extremely tedious. I believe that is a strong point: hackers won't want to spend so much time doing so many repetitive tasks: it's not challenging and it's boring. The main flaw I see in that approach is the possibility to hack the Amazon app itself to always return a valid answer, of course. But, if you mix your current hash checks with some sort of online check scattered among your methods, I believe the chances of it getting hacked may be drastically reduced.

Taken from my solution from this post Avoid apk cracked
Implement your own licensing library
I'd also refer you to check out this from Google I/O 2011 YouTube recording:
Evading Pirates and Stopping Vampires
EDIT:
The Presentation Notes from Evading Pirates and Stopping Vampires
Some basic keypoints
Modify the LVL
Implement LVL Tamper Resistance
Use obfuscation
Add reflection

I know you're not really into obfuscation, but I really need to react to this:
From here, I don't want to obfuscate
our code as I have seen it broken
before. I want something a little more solid, and I also want to learn how to do this properly.
ProGuard is very reliable in my experience, and this although I use a couple of advanced features such as AIDL and some native code which calls Java method.. It takes a little work to read the documentation and do things properly, but once you're there ProGuard is extremely reliable and also optimizes your app.
Custom security/cryptographic tricks are good, but without obfuscation it's like throwing a stone in the water in my humble opinion.
I've used ProGuard in production for many months, and it just works flawlessly.
If you're into learning, then read the ProGuard manual carefully, experiment with it, and inspect its output logs.

Chance, that there are more talented programmers then YOU (applies for all programmer), is 100%. And if that is true, you can not fix hacking. But you can spend as much time and effort on it to go bankrupt.
If you want to make some serious money you need to do some research on your target user group, and behavioral science. You need to make users playing that bring in new money, and thats it.
Besides, you got it all wrong. Hackers are most active members of your user base, thy just behave in a way you did not intend them to.
Take Zynga games on Facebook for example, do you think thy get hacked? - Sure, and about +100000 players only play, because thy can use bots, that automate everything.
Having huge active user base botnet of actual people, makes archiver type gamers want to play the game - and if thy play, and it looks cool, then Avarage Joe will also want to play. If Avarage Joe plays, then his friends might want to play, and thy probably will not care anything other, then being better then his/her friend, killing time or having something to chat about. Avarage Joe friends will most likely be willing to pay to be better then Joe, but rather thy would like to invest in something that makes them able to be better.
Besides if the real value is playing the game for free, then users who use the free hacked version, will most likely never would have payed for it. But thy are Avarage Joes and their friends just might. So this is like the cheapest commercial you can have. If you want to make money of your large userbase, then just make new versions of the game with small changes to levels and graphics.

Piracy will always be an issue. By in large crackers are better at playing this Security Though Obscurity game than developers.

What an interesting and disturbing question. :-) As an exercise, you might try releasing an app through Amazon; they have their own DRM mechanism; I wonder if it works any better than ProGuard...

One of the key elements in my opinion is to spread out the code so it's not all in one place. If you have a function called LicenseChecker.checkLicense() which retrieves the license and checks it, you can be sure it will be disabled promptly.
The one advantage you have is that the crackers cannot see the comments of your code (and, if you obfuscate, method/variable names), so come up with something weird. In the onCreate() of one activity, you get the license ID. In onResume(), you get another value to check it against. Maybe create a thread and do some checks there. And then, some other irrelevant piece of code (maybe the player control) might pick up the value and compare it and store the result somewhere. Then three other irrelevant pieces of code will all independently check that value and disable your application if it doesn't match.
Now I should say upfront that this can cause headache for yourself - obviously, cluttered, nasty code is harder to debug and prone to cause errors. Worst case, you create false positives in legitimately purchased applications.
And, of course, everything can be reverse-engineered - once the crackers find the place where the app is disabled, they trace back the value that's being read from. They could then trace back where it's being stored, and trace that back..... or, much easier, they can just disable the final check (which is why I recommended 3 different places, all triggering delayed). Security is only as good as the weakest link.
You will not be able to stop piracy. Your best bet is to delay the spreading of a pirated copy until the initial hype about your app has calmed down.

First, I do NOT consider myself a pro in the SW security field whatsoever, but:
I think an important thing is to let the application be dependent in some part(s) on the signature check. Don't let it affect immediately, but let it set some flags or change some values. later on, use those flags, check them, let the absence/incorrectness of them cause an exception of some kind which will terminate the application maybe. As long as the signature check is only relevant at the moment, it is easy to bypass it, to remove the line, once it touches more areas in the code, your application becomes harder (or less easier...) to hack. Also as I see it, not all checks should call the same routine for the sanction, because this will also make it easy to find the protection mechanism and terminate it.
Of course, the sanction to take in cases of illegal SW may vary, you might want to crash the application when used illegally, but you might as well want to keep it running, and only send message that asks the user to buy a legal copy of the application.
If this is just what you didn't want to hear, then I'm sorry for your time :)

Android users are just going to have accept the pain of constant phone-homes. The only secure Android app is an always-connected Android app.
This is, in large part, due to Google's refusal to lock-down the installation, like Apple has. On IOS you have to jailbreak the phone. On Android you can load any APK on a stock, factory install.
Keep some/most/all your content on the server; deliver it in chunks; validate the license/session on each call.

It will be incredibly hard to inhibit this kind ov behavior. Anything that is handled on the client-side is hackable using APK decompilation and modding, memory editing with software such as Game Guardian ect.
The only way I can see how partially getting around it, would be to make an online game instead. Or have certain functions handled online. Or if anti-tamper encryption like denuvo ever is available for Android / iOS.