I have an Android app public on the Github. Even if it is public I have some values like API keys that I don't want other people to see.
I've seen people storing them on gradle.properties but I have that file visible also.
I've see that the gitignore command will not commit that file at all in case I update it.
Question: Which is the best way to achieve this for Android projects and keep the project public?
There is a file called local.properties at the project root level which could be used to hold the api keys. It shouldn't be committed to source control.
Related
I want protect some files inside my project source code so if I sent source code to anyone he can only read the specific files and the protected ones can't read it without something like password or something else
I need to send all the project source code to someone and he can edit it and build the application normally but prevent him from access or read specific
I am not sure if there is something do that so if someone know is that possible please answer me
You can't. This comes up sometimes with keys and other sensitive files. What we do in cases like these is to have separate development/test/production keys or files and the developer has only access to a repository with the developer keys or files. Then on merge we merge in a way which means the final build will contain the production files the developer has no access to.
If you want to defend source code parts you can use obfuscation. This will still make the build work but it only makes the code harder to understand, not that it is unavailable. Note that if the developer wants to build the project locally it needs to access all the files the build will need, and that means read access.
For a mistake i've overwritten my two project that has same names from android studio and i've dismissed that action today i've tryed to open the main project and i've found no Java classes in it and just the layout's files.
While in the second project to which i was overwritting there is a huge confusion of files and trying to recover the project version by using history of Android Studio even those files has disappeared.
Is it possible in anyway to recover the whole project?
Ps: all that remain from that project is a generated apk.
I have some solutions that may work.
Candidates are:
Search for $AppData$ folders
Search for registries
(Hardest) you may have to preserve the disk state and carve the files yourself..
Cheers, and hope it helped..!
To use the third method(file carving), you may not cause many file operations occur!!(The system may overwrite the previous data)
Hopefully you used source control such as git or svn and it is a simple matter of reverting to the last commit you made, however that is done in your chosen source control. If you don't use source control, perhaps this will serve as a lesson to do so in the future.
I've not used Android Studio, but as a JetBrains product like IntelliJ, it will have a local history record of changes. But that would only record very recent changes.
If that doesn't work, you may have to find out if your chosen operating system backed up the files in a restore point etc.
If you have turned on the file history, you can use that to go to a previous version of the folder. Can also use system restore to go back to a previous date. Can also use third party softwares such as Recuva to get deleted files back.
Make sure to keep a copy of current state somewhere before trying these out.
If a hacker decompiled my APK would he be able to see my API keys from this file? I am not worried about my source code repository. I am just worried about a hacker being able to see this API key from my APK somehow. I'm trying to encrypt this file and decrypt it at runtime but having some issues
The way that the Google plugin is set up, it will be really hard for you to hide the content of the google-services.json file. The only viable way would be to re-implement yourself what the plugin already does for you, which I wouldn't recommend. When using the plugin the way Google intends you to, it will unfortunately be easy for anyone unzipping your APK to get hold of your Firebase/Google API Key.
However, you can prevent any abusive use of that API key by configuring who can use it. For an Android app, you can specify that your API Key can be used only by an Android application that has been signed by a given keystore and using a given package name.
To configure those restrictions, follow the documentation here: https://cloud.google.com/docs/authentication/api-keys#api_key_restrictions
On top of restricting the API Key, if you're using Firebase RTD/Firestore, you should also make sure that you configure security rules on the data store. Depending on your use-case, you can prevent anonymous user to read or write in sections of your database.
If you want more details, here is a good article I found on how to secure your API keys in an Android application:
https://proandroiddev.com/developing-secure-android-apps-8edad978d8ba
According to Firebase documentation here:
When you connect an app to your Firebase project, the Firebase console provides a Firebase configuration file (Android/iOS) or a configuration object (web) that you add directly into your local project.
For iOS, you add a GoogleService-Info.plist configuration file
For Android, you add a google-services.json configuration file
A Firebase config file or config object associates your app with your Firebase project and its resources (databases, storage buckets, etc.).
And then it identifies the content as public:
The content is considered public, including your platform-specific ID (entered in the Firebase console setup workflow) and values that are specific to your Firebase project, like your API Key, Realtime Database URL, and Storage bucket name.
Remember that, if you use Realtime Database, Cloud Firestore, or Cloud Storage, you still need to follow the security guidelines described by Firebase.
Also note that, although they are public for your application, these files should not be made available on public repositories of open source projects.
Everything in the app can be read in a very easy way, so as Google suggests you must avoid to put information in the apk, especially server key in case of firebase/google cloud messaging or services of this kind..
It's clearly not safe but you have no choice so it's important to limit your license keys.
Unzip your apk (either rename it to .zip and open, or from bash unzip [your apk path])
Now - le coup the grace: Find a file (in the root of the zip) named resources.arsc and open it with any editor that agrees to open it. Even TextEdit or Atom are enough. Search for AIza and here it is. With your user ID's.
... or the less Hacker-style method: Just drag and drop your APK to Android Studio. You can see everything inside: In resources.arsc you will find all the keys and values, all your strings, all your integers... all in easy beautiful GUI.
The bigger question: is there a way to tell ProGuard to obfuscate it efficiently.
Or is there a way to encrypt it with a secret key shared with a server.
We have an Android project where we maintain a single code base for different customers, what will be the fastest/most efficient way to compile for different customers every time? Few options I found and my questions:
writing scripts: to replace resources folder and edit app name, version, etc.
Using Android Library Projects It is gonna be quite impractical to separate current project as Library projects, I am thinking whether it is possible to save some settings and resources files as a Library project and just import different library projects for different compilation?
Storing settings and resources on a remote server Is it possible to store resource files and some app settings (xml, constants, etc) on a remote server, and download them and replace to the app when the user first launch the apk? Where will these files be stored?
Any other options you would suggest?
Android Studio provides a feature called "flavors" that allow you to quickly define different configurations from a single code base. I have just learned about this in the last couple of days, so I don't know a lot more than this.
The best way I've found is a post build script step. Use a default set of resources/assets for your main build. This is your default apk, use it for default testing. Save the unsigned apk this builds. Then for the customer specific APKs, open up the unsigned apk (its just a zip file), overwrite any overwritten files, then sign the new version.
This works fine so long as you don't need to change code for different customers. It also doesn't put any unneeded assets/resources in any build, so you don't leak info to one customer about your other customers by including their files.
If you do need to change code, the best way is to do a runtime check on a variable from a settings file. And overwrite the settings file the same way you do everything else.
As an added bonus, if you need to you can write a very fancy system that would allow the customer to upload his own files to override your defaults (including allowing them to override some of your settings), so you don't need to deal with a dozen change requests. That requires a lot more work though.
Is there a way to save projects on Google Drive when using Android Studio?
I want to access the project from two different locations, but the path to my account under "users" is different, as I use two different usernames on each of the machines.
Since Google Drive folder is under my user folder, the config is wrong if the project is opened from the other machine.
Any advise how I can use the cloud to work on my project?
Thanks!
Trying to use a networked folder to access from two different machines is problematic -- At a minimum, you'll be trying to share local.properties files between the instances, which it's specifically intended to not do. The .idea and .iml files, if you're using Gradle-based projects, aren't intended to be shared among computers. I've seen reports that these can contain absolute paths, which will make sharing them tricky. That's perhaps a bug that could be fixed, but we treat those files as local in Gradle-based projects and not intended to be checked into source control, for example.
I think that's your answer -- set up your project in source control and use that to use it from multiple places. You'll lose the ability to be able to access the project in the exact same in-progress state from multiple places and will need to commit your changes first, but that can sometimes be an advantage, too. The saving of commit history may also be a big benefit -- it's one of those things that sometimes comes in really, really handy when you get your project in a bad state and just want to hit the reset button. Granted, Android Studio has local file history (which is a great feature, but is machine-local), but source control is more resilient.