Related
I understand how to create logs but to not understand what they are for. I see that they are like comments in your code expect they show up in run-time. Why would I create a log instead of a comment? What were they created to do?
Logs can be very helpful in general debugging. For example when your application is stuck in, let's say, an infinite loop. You can then Log values to see what is actually going on and where in your application the infinite loop is occurring.
This holds true for every programming language, not just for Android. Comments are only used to clarify your code for other programmers, whereby logging can be a very powerful tool that speeds up your development process.
Background:
* I am new to developing for Android but I am a programmer/front-end web developer so I'm not totally new to this sort of thing
* My personal phone is the Samsung Droid Charge, on Verizon - I am unsure if this will really matter or not.
Problem:
It seems like I have lost all of my photos and videos, so I'm reaching out to see if anyone knows whether or not for sure I am in trouble, or if there's still hope of recovering this data loss.
What I believe caused the problem:
I followed the tutorial on how to make a simple Hello World application, as a first step in learning how to develop using Eclipse. I was unfamiliar, at the time, with signing applications. So, I just used the apk which was in the bin folder of my project. I placed it onto my web server using FileZilla, and pointed my phone browser to the file. It downloaded it, but when I clicked on it, it said something along the lines of "File is too big." or "Application is too big." or "Not enough room to install." or something along those lines. The application was only 28k, but I'm sure that it had something to do with the fact that I did not sign it properly before attempting to use it on my phone.
So - my theory is that since it looked at it as "too big," that it removed other things on my phone which were too big, in order to make room for it. I noticed that my phone suddenly forgot all my ringtone and other sound settings - because it moved them all to my 32GB micro-SD card (which came with the phone). Previously, this data was stored on the internal memory along with my photos and videos. However - I am now not even able to view the files on my internal memory when I go to "My Files" from the apps. Why this would happen, I don't know - it doesn't seem like a very good feature to have. A fellow developer at my office mentioned that it may be something Verizon has set in place for some odd reason.
If the photos are still there, which is very possible, I'm not sure how to view them. The gallery app does not recognize any files, and I am otherwise completely unable to look at my internal memory - even using a program called AndExplorer.*
As a new developer for android, this is extremely frustrating. Sure, perhaps I should have backed up my data before testing my app on my own device, but there's absolutely no reason that this should have happened.
I'm sure I can't be the only one who has ever done this. I tried searching for the issue ALL OVER the web AND on stack overflow and was not able to find anything.
Any and all help is greatly appreciated. And I have certainly learned my lesson - I need to back up my stuff before testing anything.
*EDIT: It turns out I actually can view the internal memory using AndExplorer, but there doesn't seem to be anything on there, as far as my missing photos and videos.
I placed it onto my web server using FileZilla, and pointed my phone browser to the file.
Is your Web server configured with the proper MIME type for APK files?
but I'm sure that it had something to do with the fact that I did not sign it properly before attempting to use it on my phone.
I rather doubt that. You have to explicitly do things to avoid signing an APK.
So - my theory is that since it looked at it as "too big," that it removed other things on my phone which were too big, in order to make room for it.
That seems unlikely. Even if true, this is a question for Verizon/Motorola, not StackOverflow, as only they can help you with end user device issues such as lost data.
Sure, perhaps I should have backed up my data before testing my app on my own device, but there's absolutely no reason that this should have happened.
It doesn't, in the course of normal development.
I'm sure I can't be the only one who has ever done this.
You are probably the only person on the face of the planet whose photos, etc. were lost or misplaced as the result of trying to install a hello-world APK.
And I have certainly learned my lesson - I need to back up my stuff before testing anything.
Then you did not learn your lesson. You need to back up your "stuff", period, unless you are somehow personally invulnerable and believe that this protection will extend to your device. Otherwise, you are as likely as the rest of us to have your phone accidentally get dunked in a toilet, run over by a bakery truck, caught in a fireball triggered by a terrorist attack on a natural gas pipeline, etc. And, in those cases, you would lose your data as well.
In a nutshell, Android development does not typically adversely affect a device, certainly not the mere act of installing an app. Whatever problem you have experienced is due to some combination of events triggering some bug in the Charge (possibly just your individual device).
BTW, the preferred way to test an app on a device is to use the USB cable, then run it from Eclipse on the device itself. FileZilla and downloading from the Web can work with a properly-configured Web server, but that's usually reserved for later in the development process.
CommonsWare, some of what you've said is helpful, but some of it not-so-much. Who says I don't already backup my data? Perhaps I do, and I just hadn't done it in a day? You don't know that much detail about my situation. Maybe I am only missing photos from one day. You can't definitively say I have not learned my lesson. I'll decide if I've learned my lessons or not ;). That should not have been my main focus and for that I apologize.
I'm more interested in why this happened than I am interested in getting my data back. I certainly wouldn't want this happening again. If it has nothing to do with "size" or proper signing, what else could possibly ever make something like this happen? Like I said - I am new to developing apps for phones - I can only assume so much using the developer guide provided to me by Android. A lot of the steps assume that the user knows certain things. And perhaps that's my fault and I should start somewhere else for basics.
But I still attest that the issue must have been caused by the app. I did not change anything with mime types, but according to what you're saying, that shouldn't affect things. That should not have had any effect on data loss. Yet, it absolutely, without a doubt did.
I've used a program to scan the flash drive to see if it could find any deleted files. That didn't work. So I've pretty much given up on getting the data back. Like I said - my focus should just be to prevent it from happening again.
My main activity is basically useless without another activity (act2). act2 can be accessed from a button in the main activity. It is also available through a home screen widget, which when clicked calls my main activity and immediately calls act2.
Right now, I have it set to check license anytime the function that handles the button click is called. This covers the button press in the main activity as well as if you come from the widget.
My question is, is this too often? Is getting a cache response anymore draining than checking a variable for example?
I have tried putting it on onCreate but when it says it's not licensed, you can just close the application and open it again and it will not run through onCreate again.
Here I assume you've read all the licensing documentation, and that you're using the SDK. You said nothing, so I'm going for the "defaults". There are a few clues on the Android developers blog as well as on the Internet.
I asked myself the same question last year. Or at least something similar. So let's go one step at a time:
My question is, is this too often? Is
getting a cache response anymore
draining than checking a variable for
example?
I would say that the difference is going to be "imperceptible" to "not much". First of all, the validity timestamp (VT field from extras) is stored locally, properly encrypted/obfuscated. I'm assuming you're using the ServerManagedPolicy policy, since you said nothing about it.
Depending on the kind of the app, we should notice that you may be even writing things on onPause, for example (checking for changes if applicable, of course). So, I wouldn't worry about it.
But because there is no perceptible harm does not mean you should do something. That's why I disagree with what Kerin posted:
I'm sure you'll stop loads of piracy and you aren't wasting your time at all.
More on that later. For now I say that you shouldn't need to do lots of checkings. That's what the policies are for. They handle it probably better than you and me. Anything else is indeed a waste. Personally, I only do checkings on onCreate (obviously), and also in one more situation rarely used (but very important on the app usefulness).
What you should do, however, and I say because nobody said here yet, is properly obfuscate and change the LVL library, as well as your own code side (the checkerCallbacks). Here, I changed a lot of things on the LVL library, including some simple single key cryptography (weak), and also changed how the interfaces are implemented, and how arguments are passed, and so on. Basically, I created my own LVL after posting that question here on SO.
On the opposite of what you're doing, I also customized the VT field in order to mandate a minimum time for the validity of the cached response. That's why my app is to be used in the wild, where net access is not always available. Those subtle details depend on your app, what it does, how it does, where people would be using them.
If you're a developer, it's easy to forget about the user. There is nothing worse than a legitimate user being denied access to an app he bought. So far, I didn't have problems (I check usage statistics and compare to my account), but I believe games have more trouble (it's typical of that field).
So, returning to my constructive (please, we are all trying to learn here, myself included) critic about Kerin's post, I would say that even LVL itself is not enough to "stop loads of piracy".
If you know anything about how Android works, you'd know that the apks can be easily decrypted to source code, just use dex2jar and jdgui (Google them). In fact, I always decrypt my apps before publishing to check if everything is working the way it should. And take into account that I never did computer college, I just happened to learn java and Android to create my own app that I needed and was unavailable for Android (a tide app for my country). I'm sure there are hackers and techies much smarter out there that can do even more.
People start thinking that LVL will stop piracy, and then learn the ugly truth and be disappointed. That's not what the LVL is for. Just look at the code... it was made to avoid "automated" piracy. It is to force someone to personally look into the code, see how it works, and then "switch" the proper flags, if he can make sense of them. But then again, if you use proguard, it will make the task horrible, exhaustive (believe me, that's why I use dex2jar + jdgui myself).
If your app is being sold for $1 or even around $5 or more, it will make this trouble not worth it. That's my stance on the LVL. Obviously, if you have an niche app that costs $100, for example, you probably can do it properly, server side, with public keys. But I feel that it's not the case here.
Anyway, just my 2 cents.
You can check for the license for the first time, then cache it. The next time when your app runs, read the license from the cache, and also start a Thread that gets the license from your server. If the license that you got from the server is now invalid. You can pop up a dialog box to tell the user that the license is invalid, remove the cached license, and quit the app.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm just about ready to publish my first app to the Android market, and I'd like to know if any of you have any tips about any experiences you may have encountered in regard to publishing an app that goes beyond the obvious and already documented.
Any hidden caveats and/or ideas about what to do before publishing an app to the market? For instance, a buddy of mine recommended that I remove any and all comments in my code just in case someone gets to the source code, thus making it more difficult for the would-be "code jacker" to decipher the code. I thought that was a sensible suggestion.
What are all the things to do before posting their app to the Android market?
Hope it's not too late, here is some advice:
Launch your app at the end of the week (Thursday afternoon is usually a good time). Why so? Well, no companies would like to publish an app only 1.5 day before the week end -> too dangerous (in case there is a problem that needs a quick reaction time).
Use proguard on your app (usually, you just have to add this line: proguard.config=proguard.cfg in the default.properties file). This will optimize, shrink and obfuscate your code, very useful for preventing from code thieves. You don't have to delete any comments, they are automatically deleted at compile time.
Optimize your images (using Paint.NET, PNGCrush or OptiPNG).
Optimize your layouts for most of screen sizes. You can do this by simply changing the screen size while editing a layout in AndroidStudio or Eclipse.
Try/catch all exceptions on the UI and display a simple toast which indicate to the user that something wrong happened. In the meantime, retrieve the error with Crashlytics or something similar.
Don't use too much .jar libraries, prefer library projects (optimize the code size) and add them using gradle.
Prefer using vector images since it will reduce APK size and fit correctly on all devices.
Don't use the Android preferences windows -> that's not really beautiful, even if it's in the Android guidelines, prefer making your own settings page. But if you keep Android preferences: consider adding icons and colors.
Don't show the title of your app on the main screen (this.requestWindowFeature(Window.FEATURE_NO_TITLE);): good brands don't need to take so much space on a screen to be recognized (show some icon or title in the menu or somewhere that is not always visible), and consider using the fullscreen mode (this.getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);) when dealing with games and very immersive content.
Use Google Analytics, Fabric Answers or Flurry for future analytics -> try to get as much information as possible, but don't grab anything that violates the anonymous identity of the customer. Don't forget to retrieve exceptions (errors and stack traces) that happens on the user side.
Ask your friends to do monkey tests, learning from users usually brings many good things (such as priorities and new ideas).
Consider publishing your app before having finished all features (most important feature only), you don't already know what your users will want or need besides your main feature .
Add a section "More apps", or "More from developer" in your app, that's free ads.
Add a section "Send feedback" to give the user the possibility to ask for a new feature or report some bug.
Ask your users to translate your app by providing the strings.xml somewhere on the web like Crowdin.
Try your app on each Android version with the emulator -> many bugs or design issues will be detected this way. For this, you can use the provided emulator, or use Genymotion instead (Genymotion has a lot of very useful features).
Think about the name of the app -> what keywords would you use to search for your app? These keywords should be the name of your app (Google will help you get discovered this way).
Consider including keywords in the app description, but in a descriptive way (make understandable sentences using your keywords). Never add a keyword list as is in the description.
Be the first to rate your app with 5 stars, and ask your family and friends to do the same -> this will likely influence the future users ratings.
Consider using Google to translate your app either for the description, either for the strings.xml or both.
Consider displaying ads in your apps and use mediation to improve your revenues AdMob.
Instead of providing a paid version, consider doing in-app billing -> users are more likely to pay in-app rather than paying for a paid version.
Add a change log in the app -> users usually like to know what changed since the last version.
Add a "Thanks" section for the users that helped you -> this will engage users to your product.
Add a "If you like this app, please rate it" link (to your Google Play description) in your app -> you will get more 5 stars (usually a popup on startup, or after a feature action).
Consider explaining your product via a "Tips" or "Instructions" section in your app.
Save your keystore and credentials information somewhere safe. You won't be able to publish an update for your app if you lose your keystore.
Make your icon really simple and clear. The icon is the first and also mainly the last thing that will make the user download your app.
Unless it's not possible, prefer external installation (android:installLocation="preferExternal" in the AndroidManifest.xml).
Read AppAnnie tips and blog posts, it will give you hints on how to improve ASO and help your better understand your users.
Really, don't bother removing code comments. Your source code doesn't make it to the user's phone - only the compiled code gets there, and that doesn't contain any reference to your comments whatsoever.
Android users tend to appreciate apps being as small as possible, so double-check you're only including resources (images, etc.) that are still being used in your app. Use OptiPNG/ PNGCrush on any .png images you have in your app - that can reduce the image file sizes by about 10%, which can be a significant part of your overall app size.
Also, use an audio editor such as Audacity to reduce the size of any audio as much as possible. Going for mono OGG Vorbis files is often best, and sounds plenty good enough on a phone.
Don't worry about comments. If you are concerned about malicious dissection of your app, though, DO run it through an obfuscator like ProGuard.
Other tips I would offer:
Have all your graphics and promotional materials ready to go ahead of time.
Time your release strategically for when you don't have a lot else going on in your life (like right before a weekend) so that you'll have time to respond FAST if the first handful of users start having problems. Low ratings early on can kill you, but fast e-mail response and fixes can totally redeem a customer's opinion of your app.
I'll agree with earlier comments on reducing image sizes as much as possible.
Get your code into source control if it's not already. You're sure to need to issue updates and fixes at some point, and source control can play a big role in that.
Not sure if you've seen this before, but you should excercise your UI with the monkey - my app has only had one crash, but it wouldn't have had any of those if I'd tested it with Monkey first.
Some points that I tend to forget:
double check your minSdkVersion in the manifest
test your app on an emulator with your minSdkVersion
let your friends test your app to see if it is self-explanatory
If you are going to provide updates in your app:
you might want to add some kind of 'Whats new in this version'-dialog
backup your old version!
don't forget to increase versionCode and versionName in your manifest
I'll add an obvious, but important one: save your signing key somewhere safe, and make a backup. If you're letting Eclipse manage this for you, pay attention to where it creates your keystore, and save a backup copy of it. And don't forget the passwords for the keystore or individual signing keys.
Why: you need to sign updates to your app with the same certificate you used to sign the original. If you lose that certificate (or lose access to it), you cannot update your app. You'll have to create a new listing in the Android market.
Don't forget to make debuggable=false in your Manifest. That's caught me out a couple of times.
I'm not totally sure but I think this would then include a lot of information making a code hackers life a bit easier.
I remember years ago I accidentally deleted the source to a java project, in horror I realised I had no backup! I used a utility called jad to decompile the jar file on the production server, it had all the variables intact and was almost perfect. I can't remember if the comments were there or not, but then I didn't put a lot of comments back in them days anyway :) This is because I was including symbols when compiling.
In addition to the great suggestions above, think about using Flurry for mobile analytics. I didn't know about that when I first started releasing my apps, but now that I've updated them to include it, I love seeing what users are actually doing with the app. This can provide valuable feedback and guidance for things that might be hard for users to find or not interesting/useful to the user.
As far as I know comments are not included in the app in any form.
The only "gotcha" for a developer that I found during app submission was the various graphics you can provide to the market. Be prepared to take several screenshots and create several app icon sizes as well as promotional graphics.
On the bright side, be prepared to have your app show up instantly in the store -- there is no approval process to go through for Android Market apps.
I would also make sure you had some sort of error reporting so you know how many users are encountering error's. You may want to keep a copy of your old version when updating your app incase you need to roll back. Its also nice to compile a checklist specific for your app that you can go over everytime.
Also to add to this you may want to use a trimmer to take pieces of code out that are unused to cut down on the overall file size(as phone space is pretty limited). You also may want to obfuscate your code for extra protection.
To get a clear idea..go through this ..
http://bewithandroid.blogspot.in/2012/05/publishing-android-application-on.html
Declare an android:process and android:sharedUserId attribute!
See sharedUserId: safe to change when app is already in market? for why.