This question already has answers here:
Difference between eng and user-debug build in Android
(2 answers)
Closed 4 years ago.
In Android, what is the difference between debug build and production build ? Also are there any other kinds of builds ?
Thanks.
I'm not sure if you are asking about the debug/production app or debug/product framework. So I will cover framework.
There are two different types of android framework build (the entire system image) user (aka production) and userdebug.
All standard device maker release their device with "user" build. Userdebug is meant for development and typically only built for in-house use.
Getting root:
In userdebug build you can simply do "adb root" to switch your adb shell to root mode. In addition, you can also do "adb remount" to remount the system partition to writeable mode for further control.
In user build, you can gain root access by installing special su binary and corresponding controlling app (like supersu). This way, while in adb shell, you can use "su" to gain a privileged shell. It is not as convenient as userdebug build.
In AOSP, you can choose the build type via the lunch command. For example
lunch aosp_hammerhead-userdebug
vs
lunch aosp_hammerhead-user
Well, the three little pigs had 3 types of builds but most of those didn't work out so well.
Anyway, you should see the docs here. When you build your app in the IDE you get a debug key and this is different than a production key. Having a debug build keeps you from needing to enter credentials each time but you obviously would want this prompt when you are ready to release a production build.
I guess this is what you are talking about but if you have something else in mind then please elaborate.
There is no difference between the two builds. The production build will run the same as the debug build with some limited exceptions. The limited exceptions relate to features that are signature dependent, i.e. they require you to register either the debug or production key to work properly. This would include most API's, like GoogleMaps or Facebook, and anything else that uses your build key to generate a unique identifier (think most OAuth2 products).
Your question is confusing/vague because in reality there is no difference in the two builds. Both will run exactly the same code. The difference is in who can run them and how you can run them. All android applications are signed when they are built by a unique key. This key identifies the app creator and is useful, in production, to ensure that the developer is not sending crap malware to those on the Google Play Store (or at least if they are we know where to find them).
Builds created in debug mode are signed with a debug key that is localized to a specific machine. This means if I build an app in debug mode to install to my phone, and another developer sitting right next to me builds the exact same code base to run on his phone our two applications will be signed with different debug keys. Why does this matter? Well, going back to the API registration process mentioned above, if I create our company wide Google Maps API registration using my debug key (bad idea) when my friend sitting next to me builds the app in debug mode on his machine he will encounter an error. The problem is that access to the Google Maps API is dependent on having an app installed that is registered with the right key. Because our two keys are different his app will not load properly.
Release/production mode allows you to sign the app is one universal key, not tied to a specific machine. This avoids the problem mentioned above. By using one key for all instals, every app will be able to access the same API's, so long as you register for them with your production key. This production key is not machine specific. You can send it to your friends (please don't) so they can sign apps as you.
That's pretty much it. You can read more about building and running apps here. If you have a more specific question please clarify.
Related
I have access to an Android tablets' platform key and certificate. I'm attempting to build an app and install it with system level privileges by doing the following:
Create a Java KeyStore file with platform.pk8 and platform.x509.pem using the bash script called platform_import_keystore found on GitHub.
In AndroidManifex.xml add the following:
<uses-permission android:name="android.permission.READ_LOGS"/>
android:sharedUserId="android.uid.system"
Sign APK with PLATFORM key and certificate using a Java KeyStore file in Android Studio.
Install APK
When the app runs, the system denies READ_LOGS permission.
Why isn't my app running with system level permissions?
What #Mark mentions is correct to some extent, for system apps.
I think you are doing something else wrong.
I have tried this with system apps as well, and as long it was signed with the platform keystore, it works. Now this was on Android 8 and Android 9. You haven't mentioned the AOSP version running the device.
That changes things AFAIK, so if it's AOSP 10+, it might behave differently.
Also the other comments are missing another key thing SELinux. SELinux is not permissive for user builds. Verity is enabled, and you cannot have root access. So you cannot push the app into /system/priv-app/ or push it into /vendor/app/.
You cannot access system resources without proper SE Policy files. You can check the logs yourself, to see avc denied messages.
I think overall what you are seeing should be inline with AOSP's security ideals. An app signed with System keys should not be able to get system permissions. It also needs to be located in the correct place, either as a privileged app or vendor app. Such apps need to be whitelisted. There's a built in script in AOSP source to even generate the permissions for whitelisting (it produces the required xml)
There's two classes of system apps, /system/app/ and /system/priv-app/
The privileged apps are the only ones that get signature level permissions, and according to newer versions of android, you need to enable whitelisting in the /system/etc/priv_app-permissions_device_name.
If you make any changes to the system or vendor when verity is enabled, firstly they are mounted read only, but somehow if you do make a change, the device will brick itself. This is the security feature. All custom development needs to be done in userdebug builds with SELinux in permissive mode, and then all the permissions need to be predefined, SE Policies fine tuned to utmost minimal, only then the user build can function normally. User build is not at all suitable for AOSP development activities, even if it's just for testing or trying out a single app.
User build is production type build that the end user can use and is not for development. It's the most secure form of android, so if you have platform keys, it may never be enough.
All that being said, I'm sure you don't have the right keys. Just pull an app from system/priv-app/ and use keytool or similar to check it's signature, and then try to match with your release apk.
It's little complicated as it is, and kind of hard to explain and there are levels of permissions also in android, so if you aren't following a specific approach/path, you will not be able to get it to work.
By default, Android Pay refuses to work in debug builds, which makes testing tricky. What we've done so far is to actually merge new code into a develop or hotfix branch so our build environment will make a signed APK which can be tested. This is not ideal.
https://developers.google.com/android-pay/get-started states
"Note: Our test environment will not return live, chargeable tokens in the FullWallet response, but will allow us to test your pre-purchase flow. You will see an Unrecognized App error on the Android Pay chooser until your app has production access."
which isn't too promising.
https://developer.android.com/google/play/billing/billing_testing.html suggests testing with specially configured static responses for "reserved product IDs", which would be a nuisance to set up and not a true test. The other option they offer is to publish the app to an alpha or beta channel, which would, of course, be a signed APK.
https://stripe.com/docs/mobile/android has a suggestion about "TEST_GATEWAY_TOKEN" but isn't really helpful in learning how to use Android Pay in test.
We even talked to a Google Developer Advocate, who did nothing but cut and paste some of the same documentation.
Is there any way to do a good test using an unsigned build? It would be wonderful to test Android Pay functionality successfully on a local developer machine.
No, there is not a debug mode option to that per docs:
https://developer.android.com/google/play/billing/billing_testing.html
set a separate machine with a CI server and have it do the alpha and beta builds for testing Google Play.
It is a pity but you have only one way to test IAP:
Grant testing permission to your google accout used at your device
Build .apk file.
Upload it to your account at GoolePlay as beta version
Wait until uploaded .apk processed
Try do to actions you need and check it.
If any issues - fix them and start from p. 2
So this might sound like a complete and total noob question, but I'm going to ask and see what I find anyway.
I'm working on an Android application using Eclipse IDE. I have two development machines that I use (one for work, one for home) and one is 64bit while the other is 32bit. The phone that I'm using to test my application is a Google Nexus (Verizon flavored, most up to date drivers). If I build and run the application using one machine, then try to do the same on the other machine I get a console error that tells me to run an ADB command to uninstall my app because the signature has changed.
From what I understand it's because "debug.keystrore" (located in %USER_HOME%/.android) is different for each machine. Why does it do this? I assumed that the application signature was unique to the app not the app + dev machine. Is this normal behavior? If so, is there something I can do to get around it? I'm worried that copy/pasting the file between machines could cause problems, so I haven't tried it yet. Would I have to move this file every time I switch machines? Also, if I release my app into the wild; then loose my computer and have to start using a new computer (thus, changing the application sig) will everyone who installed my app have to uninstall the app because the application sig is different?
Bonus round: is there some way I can configure my IDE so that I don't have to change where eclipse looks to find the SDK every time I switch machines (i.e. make it look in both the ProgramFiles directory and the ProgramFiles (x86) directory.
To make sure the app was built by the same developer, Android wants the signature to be the same. Feel free to copy your debug key between machines. It has nothing to do with your machine or whether it's 32/64 bit; it only proves that you're the same developer.
When it comes time to release your app, you want to be very careful to
Keep your release key private, and
Keep your release key backed up in several places.
If you ever lose your release key, you won't be able to update your app, as you suspected.
Update: To make my answer more complete, it looks like the way to tell Eclipse which key to use is under Preferences -> Android -> Build.
I use Linux and don't use Eclipse; what I do is just copy ~/.android/debug.keystore from machine to machine, and the ant build tool uses it automatically, avoiding the pesky "certificates don't match" installation error.
For my release keystore, I have this line in my ant.properties:
key.store=../private/my-release-key.keystore
and keep my-release-key.keystore in a private repository much to the same effect.
I guess that for different platforms Google team has created different debug keys (I guess for tracking purposes). These debug keys do not depend on your application. If you want to distribute your application you need to create your own key. If you sign your application with your own certificate there should not be such kind of problem (because in this case, certificate depends only on attributes that you've entered when you create certificate). Under the Preferences -> Android -> Build you can select which keystore to use.
The signature is unique to each of the developers. From what I understand, if you are using the debug key, it uses your mac address or other unique characteristic to create an arbitrary key. So when you build and install your app onto a device with one machine, and then go to use another, you have different signatures, and thus your issue.
To be able to not have this issues, you should create your own key, as others have mentioned, and then use that to sign when you build.
You will NEVER want to release an app with your debug key, this is just for developing and when you go to release your app, you want to use your unique key that you created.
These keys are used to keep others from updating your apps, without your permission, so create a your own dev key and you won't have this issue.
Here is a link that should help you get started and pointed in the right direction: http://developer.android.com/tools/publishing/app-signing.html
I've copied "debug.keystore" from one machine to another, there are no ill side-effects. You can simply overwrite one with the other, and the un-install/re-install problem is fixed. The debug key is there only to protect the developer's own devices from other developer's binaries.
As others have mentioned, you do not publish your app with the debug key, you must make a release key and sign it, per the instructions on developer.android.com.
Also it's worth noting that the "debug" key is only valid for 1 year from the date it was created (when the SDK was installed). After a year, the SDK will say it's expired, and generate a new debug key. You'll have to re-copy the new key to the other machine, and you'll have to un-install the app signed with the old debug key.
As for the other problem you mention, you should have separate Eclipse workspaces that both reference the same Android project, using different SDK locations. The project does not need to be in a sub-folder of the workspace, so you can make this separation.
I am getting the above error message when I try to debug an application that is already installed. Most others who run into this seem to be developing on different machines with different key files, but I am doing everything on the same box.
My issue is that I am testing my database upgrade process (i.e. what the onUpgrade() method of my SQLiteOpenHelper extension does). For this, I would like to try the upgrade on top of a variety of older builds. These builds are available as signed application packages. When I deploy such a package to a fresh emulator and then try to debug the current version on top, I get the error in the subject line. I think that this is because the debug deployment packages are unsigned, and the currently installed package is signed. Again, I know that the error goes away if I unstall the currently installed app, but then I cannot test the upgrade.
I do not want to go through the effort of switching back my dev environment to older build versions, so that I can build unsigned packages for these versions. I may not even be able to do this, because I switched source code repositories recently and lost some of the history.
I believe that if I were able to get Eclipse to generate a signed package for debugging, it should work. Alternatively, I could manually deploy a signed package and launch a debug session without a build/deployment step, but I have not been to figure out if this is possible, either. What can I do?
Edit: The Android documentation was helpful in figuring out how to sign a package with the debug key, but this does not help me, because I need to debug with a private key. I suppose that this is not possible.
You can sign current package with release key, install on device, run the application and connect debugger in Eclipse. How to connect debugger: in the DDMS perspective on the Devices view select your application and press button with "green bug":
I'll post it as an answer:
You should generate them all with one signature - otherwise it wont work. only uninstall and fresh install will work with different signatures. http://developer.android.com/guide/publishing/app-signing.html also taken from there:
Eclipse Users
If you are developing in Eclipse/ADT (and have set up Keytool and Jarsigner as described above in Basic Setup for Signing), signing in debug mode is enabled by default. When you run or debug your application, ADT signs the .apk with the debug certificate, runs zipalign on the package, then installs it on the selected emulator or connected device. No specific action on your part is needed, provided ADT has access to Keytool.
The application reads a key from a file to hit production vs test server.
I want to create a test apk build that will pick test key and second build apk for release that will pick the production key
I am currently building app using eclipse
I'm not sure if it is related with what you mention, but it sounds to me like you could perhaps include such functionality through the usage of License Verification Library (LVL), consequently having a single app and still being able to deal with the key issues.
Hope that helps.