I have a module here that has the job to smooth some UI output. It is fed by data that is timestamped. The module itself has a timer that, along with lots of code, makes sure that on the other end there is a nice visual result.
But sometimes, the whole thing gets stuck. Its extremely hard to reproduce and so far i could narrow down some things.
1) the input is still working and fine
2) the device is still responsive
So somehow the logic of the smoothing has a bug that under certain conditions hangs the thing up. I logged all "returns" because its still drawing stuff, but the values dont seem to change, so the chain has to be cut off somewhere.
Every return statement in the code makes sense and they are called every once in a while for legitimate reasons and they dont break the code. But there has to be a combination of events/things/values that break it.
The code itself is poorly written (by some intern, who now has no clue what he did back in the day), almost no documentation and i have a HARD time understanding the code and im not a dummie.
The module "works" and we dont know if the bug has been there always or if it was introduced one day by some other changes. Time is pressing, unit testing is nonexistant.
I know it should be different, but thats just real life.
Now there's always the rewrite... But how could i first try to narrow down on the bug and maybe save myself a lot of trouble and just FIX it with some quick-n-dirty ?! (maybe its not even dirty at all and i just fix the missing 1% to 100% working)
I have no experience with unit testing and i dont really know what kind of time we are talking about to set up a test in this case. I am far beyond the ideal conditions, its more like Schwarzenegger in the movie Predator.
Any help is welcome.
In my experience, sometimes it takes much more time understanding and reverse engineering someone else's code, than writing your own version from scratch. In the past I've decided to rewrite complete programs myself, reducing the code sometimes by 80% and resulting in much more elegant and readable code. This might be impossible if we're talking about a huge project.
Some important things to have in mind though are:
- do you know the algorithm, or would you first have to reverse engineer it
- is rewriting the code doable with your skills in a reasonable time
- do you need to maintain the code often
Also, if the code was written by an inexperienced programmer, chances are that you'll find more bugs in the future.
It is impossible to give you precise advice, with the little information you give us. Use your best judgement, rewrite parts of the code if possible, split the code in different classes, modularize, rename variables, clean it up... and the bug will probably become much more evident.
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 9 years ago.
Improve this question
I was wondering how bugs in iOS, Android, Facebook, etc detected. Is there a specific pattern one may go about detecting them? I am asking about bugs in operating systems and also websites (including web applications). Is the process the same or different. If so, how?
Generally bugs are found through the QA or Dev process. Having a dedicated team or not, the process is essentially the same.
Run through all functionality of what you're testing - note any unexpected behavior. At a minimum, try to think of all possible scenarios, use cases, test cases, and if possible edge cases (things that aren't what you would expect the user to do, but theoretically could happen).
If there are no visible bugs, then looking at your backend may be required (if you store values for example, you should check these)
There are several stages that are gone through (at least by myself and I can imagine many others) to detect bugs in applications.
REVIEW -- Once it is written, comb through the code and check for any
non-optimum situations that can be easily remedied. Don't try to
re-invent the wheel here, just check for anything which can be
swiftly and easily resolved.
PERFORMANCE -- Performance testing is key. Run your application and check what it
takes to run. How much CPU is it using? How much should it be using?
MEMORY -- Watch your memory usage. Memory usage can become one of the greatest problems if leaks or zombies exist. check to make sure that all of your memory is being allocated and deallocated properly and that there is no wastage. A small increase of memory over a 1 minute period could mean a crash in a few hours.
UI TESTING -- UI Testing is the next crucial step. Now that you are satisfied that you application runs and performs well, what will the user see? Is it slow to respond? Do transitions and animation flow? Does it feel natural? does it look nice? Play with your app and use every function available to see that it works nicely.
IDIOT TESTING -- Idiot testing. No joke. You will get some users who are below average on the user intelligence scale and you will be surprised to see some of the bugs that they come up with. So go through the UI testing again, but this time be dumb. Do strange things that a normal user wouldn't normally do. TRY TO CRASH THE PROGRAM. Break the "rules" and go hog wild. you might find some surprising bugs.
BETA -- Beta release. That is the biggest tool used in testing. Select a few users from many and give it to them to use. See what happens and request that they turn in feedback. Survey them and find out what they do and do not like. Based off of their feedback, change or ignore as you like.
These are the steps that I usually take before releasing an app or program.
Another tip, if you are developing, is isolating the source of the crash. It might seem obvious, but sometimes even I forget to do it. If I notice a bug, I don't just kill the bug. I find where the bug came from, how it got there and I kill the reason it came into existence. That way, no other bugs can result. You might also find that the source of one bug was actually the cause of many others.
I have finished my initial project but facing 2 issues while finalizing. If you kindly show me light
1) I am receiving lots of skipped XXX frame errors from Choreographer. I started looking one by one, then I realized some of them most probably have nothing to do with my code. For example, I explained here Android - Skipped frames message from Choreographer.
So, How can I know which LogCat choreographer messages I should be focusing on? Again, I am receiving lots of them, so it is very tough to check one by one which are real.
2) In my whole project, I only have one warning when I open and close menu tree without choosing any option. However, I guess it is also problem with emulator as explained here.
I am using Eclipse as my emulator.
Any kind of advice is highly appreciated.
Thanks,
A lot of skipped frames (probably) means you are doing too much calculations in the UI thread. If you are doing a lot of calculations, consider moving them into another thread, which might solve your problem.
You can hide the Choreographer outputs onto the Logcat view, using this filter expression :
tag:^((?!Choreographer).*)$
This question already has answers here:
The application may be doing too much work on its main thread
(21 answers)
Closed 6 years ago.
I'm developing a calendar app, and using textview as calendar cell, when i check the logcat after launching the app, i find this message from Choreographer "Skipped 76 frames! The application may be doing too much work on its main thread".
i know i'm creating a lot of textviews (120), but how can i build my calendar without affecting my app performance ?
is there another way to build a calendar who supports events ?
120 text views seems like a lot, and in particular it seems like several screens worth of data.
When you have multiple screens of data, it would be logical to think about using an adapter view, for example ListView or GridView. Adapter views use view recycling to limit the number of views in use at any given time to approximately one screen's worth.
Is there a reason you're not using Pickers.
If you need to roll your own control, you'll need to move any heavy lifting to another thread. You can either
1) Use the java Runnable interface or Thread class, probably with an anonymous inner class (see here).
2) Use FutureTask + executor service (here is an example).
Since you are making a calender, and therefore are aware of the number of cells before hand, considered maybe inflating the layout containing the cells and that way with one command the entire layout is set, and then you just fill in the text of the TextViews?
I did a search and found this link: http://developer.android.com/reference/android/view/Choreographer.html. This is a new class introduced in API 16.
Choreographer lets apps to connect themselves to the vsync, and properly time things to improve performance.
Android view animations internally uses Choreographer for the same purpose: to properly time the animations and possibly improve performance.
Since Choreographer is told about every vsync events, I can tell if one of the Runnables passed along by the Choreographer.post* apis doesnt finish in one frame's time, causing frames to be skipped.
In my understanding Choreographer can only detect the frame skipping. It has no way of telling why this happens.
The message "The application may be doing too much work on its main thread." could be misleading.
You may refer this question
I'd be reluctant to make any changes unless I was CERTAIN that my app was performing badly. I see this message regularly on my emulators, sometimes when Android is still starting up, and sometimes when running simple osample apps supplied by Google. This is worth reading :
Choreographer(697): Skipped 152 frames! Debug log
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.