Develop Reference

Basic precautions to prevent piracy?

It's my first app and I am concerned about piracy. I know it's not possible to fully prevent it but I would like to make it as hard that the hacker wouldn't simply find it worth.
I have read some older threads but I don't know how secure Android and libraries like LVL are today.
So far, I have only implemented Proguard and LVL.
What are other ways that people can crack my app besides reverse engineering and what can I do to make it hard?
Also, I asked another question specifically about lucky patcher piracy prevention. If you know anything about it, please help me there too.

You can stop worrying about it. Quite frankly- your code isn't that secret. Any decent programmer could recreate it. There aren't hoards of people out there looking to crack your app. What keeps your app valuable isn't the code its made of, its the understanding of the problem space and continuing resources spent on improving it. And as long as your code is running on devices you don't own, the most you can even theoretically do is add speed bumps that will cost you more time developing and in maintenance than it would to work around.
Instead, spend your time and effort writing the best app you can, and coming up with new ways for it to provide value for your users. That's how you'll get actual users.
Your app's data may be valuable. But you don't protect that by making your app harder to crack, you protect that with real security measures.

Android Traceview - It holds the Answers to my Unresponsive App... I think

Yesterday, I spent 12 hours becoming a student of Traceview. I didn't even know it existed (hangs head in shame) previous to this.
Now that I've overcome the absolute shock of the data it produces, I find Traceview can be boiled down into a couple simple concepts:
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation.
Look at the frequency of calls and the cpu time/real time per call. Obviously higher calls should be looked into. In most of my experience, if you sort by #1 above, methods which are called too much and take too much time will also be at the top of the list (makes sense as they are also using the most CPU).
Anyway, doing these two steps above I find 3-4 methods which are always using 90% of my CPU and taking up most of the real time delays in my app. The only problem is, none of these methods are methods I wrote, they are system methods such as:
BitmapFactory methods
WebKit methods
And other system methods
This being said, is it a correct to assume that if the top resource hogs are system methods, then it must have something to do with my design of my layouts? I am at a loss as to how BitmapFactory could be so high, my layouts aren't extremely complicated, though in one Activity BitmapFactory is taking 95% of resources itself.
TL;DR - If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue? Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Thank you very much,
Ryan

I find Traceview can be boiled down into a couple simple concepts:
Those concepts are not the best, IMHO.
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation
In particular, this concept is fairly lousy IMHO. Yes, this is useful data. However, you then need to work back up the call stack to try to figure out what is triggering this. Sometimes, it will directly be your code. Sometimes, it will be something else that you recognize that is part of the framework (e.g., onDraw() of a View). Just knowing that some random method is taking up a bunch of time does you no good until you identify what is triggering that method to be invoked in the first place.
If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue?
No.
Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Work your way up the call stack to figure out who is calling these methods so frequently, or at inopportune times.
For example, in the BitmapFactory example, you will probably find that you (or a library that you are using) is calling BitmapFactory, and perhaps is doing so on the main application thread.
To work your way up the call stack, click the triangle on the left edge of the row representing some method of interest. You will then see two branches beneath that: "Parents" and "Children". The "Parents" represent the next level up the call stack from the method, and you can continue working your way up the chain of parents until you find something that you recognize.
That's why, IMHO, you are better served sorting by inclusive time, as your code (where it directly is the culprit) will tend to bubble towards the top.

Well, I found the problem and it's bitter sweet. It's sweet because it wasn't my code nor layout causing the problem, it was the admob AdView using the loadAdOnCreate="true" to create ads. It's bitter, because I now may have to switch sources of revenue if I can't remove the loading delay created by the AdView! That was a tough one to find, I should have anticipated this though!

Choreographer(697): Skipped 152 frames! Debug log [duplicate]

This question already has answers here:
Meaning of Choreographer messages in Logcat [duplicate]
(5 answers)
Closed 8 years ago.
I am building a new game with andengine and for some reason i keep getting this debug statement in the logcat:
01-31 21:29:50.503: I/Choreographer(697): Skipped 152 frames! The application may be doing too much work on its main thread.
Im not really sure what is causing this error exactly during my game. I am checking a lot of collisions, but they arent initiated until after the game play scene has started.
I also noticed on my galaxy S3 the game causes my phone to "flicker" when swiping changing home screens and pulling down the task bar at the top.
I think this error has something to do with it, but i am not sure. What do you guys think?
Also each time the user goes to another level i initialized the collision detectors all over again. But i dont unregister or stop the last collisions that were started. I thought they would be automatically cleaned up when the new one is initialized.
What do you guys think?

It sounds like you're aware of what the message is telling you, i.e., your frame rate is lagging. Your follow up question, "why?" is going to be impossible to answer without more information. You've provided some possibilities: is it the collision handling? Is it processing of unnecessary collisions? Is it some problem in the scene transitions? The answer is, maybe. Maybe it's any of those things. Maybe it's something else. At the moment all we can do is guess, because we're not looking at the code.
But the good news is, you're not without recourse! What you need to do is test your code and find where the bottlenecks are. A good place to start is to throw in some calls to clock the milliseconds between blocks of your code that you suspect are the problem. You may discover that things you'd assume we're slow are actually happening pretty quickly, and conversely, things you thought were fast are happening slowly. Focus on the latter! Put more calls in there to see where exactly things are taking longer. And look at your code to see why it might be running slowly there. Are a lot of objects being instantiated there? Is it reading from disk? Etc.
When you're ready for them, there are some great third party tools to get deeper into the testing, but it's worth spending some time to clock and review your own code first. You have the advantage as the author of suspecting where the problems may be. Start investigating!
Side note, I'd provide some links to third party tools, but I'm writing this from a jacuzzi. I'll update later.

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.

Should I learn Google App Inventor as a supplement to Java for Android

Just curious. I am already a Java android guy but am interested in the new app inventor beta for android.
I was wondering what "real" developers are thinking. A lot of people want to develop an android app but don't really have programming skills. Seems like a lot of apps could be written with app inventor - not sure since I haven't tried it yet.

Hopefully this clears up some things for people that are still just hearing about App Inventor. (Keep in mind App Inventor is extremely beta right now, so all of this is subject to change.)
If you're interested in playing around with some of the features it offers and haven't had the time or interest to get involved with the full Android SDK, then App Inventor is probably a good fit for you.
The interface of App inventor offers some unique features you won't find in the Android SDK and is pretty easy to get the hang of (make sure to look at the shortcuts for the Blocks editor, or it might start to feel tedious real fast). It has live debugging and live edits to both the interface and the supporting logic. That alone cuts down on time and frustration if you aren't quite sure about the proper way to do something yet and is probably my favorite feature of the whole system. New developers will especially find it rewarding to actually see their changes implemented on their phone without waiting for things to compile and run. It is a huge time saver and much easier to get used to than the traditional compile and wait process you face if you are trying to learn things through the SDK.
It is also quite handy if you have been playing around with the Android SDK and simply want to try something new out that App Inventor supports that you haven't had the time or aren't quite sure how to approach yet. So long as you keep things focused on features that App Inventor supports, this can provide valuable insight into understanding a problem by getting your phone doing something you can see and use in a matter of minutes. That's something even seasoned developers are likely to appreciate.
The real problem is more when you start hitting walls. Walls that you simply can't climb. And you quickly realize that the limits of this tool must be understood or you will probably spend a lot of time trying to do something that just isn't currently possible. Sooner or later your going find yourself in this position if you use App Inventor very much.
All coding is graphical.
Look at some of the demos or screen shots of what's available through the Blocks editor if you don't understand what that means. Setting values in those big colorful blocks is as close to code as you will get with App Inventor, for better or worse.
If you have any previous development experience, you are going to find yourself longing for the ability to do some simple coding to supplement what you are doing. Or at least the ability to export your project and pick up where you left off in Java. Sorry, this isn't that kind of tool.
Your only options when you get to this point are to pick up and start all over in code or forget about it, at least until the desired feature gets added to App Inventor (which may be never). That right there likely to irk a good number of people and turn them off to it.
If you are looking at getting into Android development, I see no problem with starting out with App Inventor. It might even save you hours of effort that might otherwise be spent trying to wrap your head around some concepts that are simple to understand when you do them, but a bit confusing if you are building them for the first time.
If you are a seasoned developer, or looking to make money or gain Android experience beyond just the concepts, this isn't your end destination by a long shot. If you are a student that is new to programming, this is probably a good environment with sufficient challenges and room to play around in to keep your interest for a decent amount of projects.
Despite it's current limits, I still see App Inventor as valuable resource to learning new concepts and as a playground for trying out new ideas. It is proving to be an awesome tool for introducing someone to Android development, and would probably do as good a job as you could ask for when introducing someone to programming in general.

I have been playing with it for a bit and my thoughts are that is is great for:
An introduction to programming. It is not something people can pick up and develop great programs with straight away, it does still require a lot of thought and logical thinking, but it doesn't require people to learn the correct code syntax
Prototyping. As it is relatively quick and easy to develop with (and has live debugging on the Android device), it allows you to prototype and see/interact with it in real time
Quick coding. If you want to develop a program quickly, this might be the simplest tool
As the tool develops, it will allow more feature-rich applications (it already allows integration with other back-end programs, etc.). The screen design right now is very basic, but will be improved soon.
Overall, I think that if you know Java for Android, then you will be able to pick up Google App Inventor within an hour and start making some functional apps. You might find it more suitable for building some apps, or you might prefer to stick with your current tools.
For people looking to start programming, I think it is an excellent introduction. They can concentrate on logic and program design, instead of setting up their IDE, code structure and syntax. Plus they will see results as they code.
To answer your question 'Should I learn it'. I would suggest that you play with it for an evening - that is all it will take you to get a good feel of it.

It probably won't make you a better developer, but all knowledge is good, so it can't hurt :)
I plan to play around with it anyway.

The generic answer to any "Should I learn ..." question is usually "Yes, it can't hurt to know things." From a practical standpoint, I would skip it. These sorts of things are usually nice ideas that never catch on. Sure this might be a neat way for non-programmers to build very simple applications and perhaps a real programmer could build a compelling application with it but it looks like if you are a programmer the benefits to using App Inventor don't seem that compelling.

I haven't checked it out, but I think it might be worth a look to help in UI development. Most software engineers are good at really solving problems with software or coming up with cool ideas for apps, but when it comes to UI design we find a lot of obstacles. At least myself, I've always been used to working with UI Designers.
I honestly don't like tools that generate code, (except WSDL to java or java to WSDL) but pretty much anything else I find myself spending more time trying to trouble shoot an issue when it comes up than the time I would've spent writing the app from scratch...

Appinventor is so easy to learn, I would suggest go for both options.
Concentrate most of your time on your main Dev environment and learn AppInventor, in the background, to give yourself a break.
The advantage of Appinventor is you can put together reasonably complex apps
in a relatively short period of time.
It's also pretty forgiving, for example, if you have a numeric variable, you can treat it either as a string, or a numeric value, meaning you can put together
prototypes pretty easily and quickly.
If you want an app putting together, quickly, Appinventor might be the better
option, if you need something more powerful, more control over you UI etc, then
a more sophisticated Dev environment might be called for.
With Appinventor being so easy to use and learn, you're giving yourself more options.

Considering Eclipse seems to introduce errors I can't find and can't remove--even after using Project-Clean, I'm looking forward to any alternative.