Develop Reference

Android Studio singningConfigs, is it safe to include the password?

My question is that there is a section in the gradle file called signingConfigs.
Is it a problem if the password is entered here?
Should I be worried about this?
Thanks.

We should NOT do this. These params are there for testing convenience.
We should NEVER store ANY crucial, personal, sensitive information as plaintext.
The testing key passwords and stuff just use dummy values. The actual release key we generate via AndroidStudio or Java keystore directly.
For PlayStore app releases, key files I usually let Google assign, manage and maintain via Developer Dashboard.

How to make a application that cannot be resold without the developers permission

This is my first time working on a solo Java project that would generate income from direct sales (meaning I would sell the product instead of a third-party platform).
I was curious as to the following: How can a developer prevent a customer to simply distribute his/her software?
I realize that there are always ways to bypass any sort of security that a developer can put into their project. However, seeing that my product will be run locally (.exe or jar file) there is no way for me to monitor what my client is doing after I sell the product.
Is there a way to put some sort of "illusionary wall" that someone without more advanced knowledge cannot bypass?
Any tips, suggestion or references are greatly appreciated.

I have a server. Some actions within some of my apps will call to the server with some status info. So I know who uses my software. This is plainly stated in the contracts, so no secret stuff.
If I want to limit my software, I do the following:
when my app starts, it collects some system infos and hashes/CRCs them
if there's a matching file, whose contents match the system infos hash, I unlock the app
if there's no such file, or the hash inside it does not match (different system, manipulated, etc) I will (re-)register
registering is either done
by showing the client the hash, forcing him to call/email me, or
the app connects to my server, checks registration infos, shows the page, and then forces user to pay, or unlocks, depending on some other infos i gathered.
on the server side (or manually) I create a key matching the system info hash key
that key gets back into the app (internet or typed manually) and the app checks if that new code matches its system info hash
if keys match, write key to file, and unlock the app
2 downsides:
java is really easy to reverse-engineer:
someone could create a hash generator and create the missing/wrong system info hash file
if you connect through the internet, you should use SSL/TLS, because in other cases, someone could just reverse-engineer (telnet) the answer the app needs to unlock
a good method to prevent reversen-engineering or to make it a lot lot harder is to create pure .exe/elf files. GraalVM native-image is one of those tools that can accomplish such feats. (only using an exe wrapper is rather pointless when it comes to code security, but i good for users)
whenever the client changes things in his hardware, he has to register/reconnect again

All the software i bought for my pc has to be registered once with a license key via internet or has a usb licenser. So maybe this are some ideas something for you. The disadvantages, running a server for product registration or sending an usb-licenser to the costumer. But i'm interested if there are any other solutions

Hide variable value

I'm writing a small Android app and I need to hide some variable values. I have a API key I got from the content provider who is providing me content to show in my app that I need to retrieve data from them. Because it is being used in an encryption algorithm, it is of vital importance the code isn't leaked.
I need to save the API key in my code and be sure it isn't retrievable by the bad people in the world. What I do now, is save them in my code as a variable:
private static final String API_KEY="mysupersecreatapikey";
After the app is compiled to an APK file, this is, in my opinion not retrievable anymore. Am I doing it in the right way now, or is there a better solution?
Thx in advance,
Daryl

You could store the API key in a file located in storage. You can encrypt the API key when you write it to the file and then you can decrypt it when you are reading it (upon program execution)

If you put the API key into the client in any form that can be used by the client it will be possible to get to it somehow. Maybe by unwrapping the APK and decompiling the code, maybe by traffic sniffing. That private static final variable for example can likely be extracted by a decompiler (if it's bytecode).
If you want to make really sure that none of your users can get to the API key then your app shouldn't be using it directly. Instead have it connect to a web service you set up that serves session IDs for example. That web service that runs on a server that you have control over (quite a few options) would then be the only piece of software that knows the API key.
But depending on the use case this might be a complete overkill solution to this problem.

How should I Encode my Twitter Key?

I have my consumer and secret key. I know I have to encode the secret key when it is included in my app. What is the best way to go around doing this?

The first solution could be to use obfuscation (search for ProGuard for Android, there are a lot of resources about it) and the next one could be to add extra security decoding all of your strings using one way encryption (algorithms like AES does are useful).
Of course the best option is to avoid adding this kind of keys and moving to the server side, adding the code to be used in the Android client. This solution not always can be applied, of course, but did you asked yourself if it's really needed the key in your client device? If you move your Twitter key to a server that does all the job related with the Twitter service (publish, get the timeline, etc), you won't need to add it to the app, you only will need to communicate securely your clients with your server. I know, that this solution only could apply if you have a really powerful service (lot of effort to do it) and you are able to sign to your server with secure methods (SSL, etc).

Security of string resources

I was wondering what's the security of Android's resources folders (I'm especially concerned with strings). I know, I know, it would be ridiculous to store a password in Strings.xml. It's not like that, but how easy it is to snoop on these resources, to access sensible app info?

Unfortunately it is pretty easy to get to the resources. Tools like apktool enable to do that. I have raised a similar question here. You may want to take a look.

Easy on a rooted phone. Expect anyone can read your string resources shared preferences, etc. I just hooked up ADB, changed to /data/data/com.tumblr/shared_preferences and read my username and password in the clear.
You can also download and decompile the apk. If you need to keep it secret, encrypt it.

The primary rule of thumb here is that ANYTHING stored on the device is open for sniffing and cracking.
There is no such thing as local security against those in physical control of the device.
Even if you encrypt it, the keys for decryption have to exist on the device or be easily accessible by the device.
As a side note, this is the number one reason for features such as Remote Wipe.
So, if you plan on storing something sensitive or just plain don't want a slightly interested user to see the data you've stored on the phone, then you're out of luck.

I know that the xml files are scrambled in the apk, but there is a hacker tool for unscrambling them back to plain text. I can't remember the name of it but I found it OK via Google. It works unfortunately!