I'm newbie on Maven and I would need to set up a testing project for a complete Android device using Robotium, Android Maven plugin & Jarsigner.
In order to successfully deploy, install & run the tests on device, they would need to be signed using the same private keys the native apps (Eg. Contacts, Messaging, Camera...) on the device are using. Since there are several different keys, and it seems that the key aliases are defined in pom.xml-files (only one in each file in jarsigner configuration?), do I need to have multiple pom's defined in my project, or can they be defined elsewhere? The approach using multiple poms sounds hard to maintain.
Look at the morseflash example on how to set up signing. I am not sure I understand your question in terms of multiple keys and the native apps. You have to use your own key for your own app. And that is completely independent of any other app.
Related
I'm working with a client who wants to deploy multiple versions of their android application (representing DEV, TEST, UAT, PROD, etc) to the same device.
Normally, with any application, I'd prefer to promote the same compiled binary code from one environment to the next. For example, if a build passed testing in TEST, I'd like to promote that exact build (perhaps with different configs) to UAT. This would be possible if the clients test environments were different devices, but given they have the same android device running multiple versions of the app, I'm wondering if there's any kind of best practice here.
The client is using Azure DevOps. Is there an easy way to build the APK as part of an Azure build pipeline, and then change its Bundle Id, or google-services.json in a release pipeline to indicate that it's a "Dev" or "QA" version of the app?
You may try to use extension 'Mobile App Tasks for iOS and Android', this extension includes tasks to change app's version name and code or app's package name at build/release time. If the extension can not satisfy your requirement, you can refer the source code, modify it and create a custom extension. Please see how to create a custom pipleline task.
My project contains a dynamic feature called feature_login
In the AndroidManifest.xml file, I configured feature as included and NOT on demand.
<manifest ...>
<dist:module
dist:onDemand="false" dist:title="#string/title_feature_login">
<dist:fusing dist:include="true"/>
</dist:module>
</manifest>
So I assumed that the given feature will be included in the .apk file by default. But when I am generating .apk using Android Studio
seems that it doesn't contain that feature as the app is crashing as soon as I am pressing on the button which starts the feature.
But the app works when I am running it from the Android Studio on the Emulator using Run button.
Question
Are dynamic features good for a use case like Login?
How I can build debug app which contains dynamic feature?
Are dynamic features included in the .apk if dist:onDemand="false" and dist:fusing dist:include="true"?
Are dynamic features good for case when you want to have separate modules (ex. Login, Profile Details, etc) or better to use library module?
Are dynamic features good for a use case like Login?
If you can decouple dependencies from the rest of your app while still using login, sure.
How I can build debug app which contains dynamic feature?
Either through the app bundle flow using bundletool or using Android Studio.
You can also use ./gradlew assemble and then adb install-multiple with all relevant debug apks.
Are dynamic features included in the .apk if dist:onDemand="false" and dist:fusing dist:include="true"?
No. The fusing flag is relevant for .aab. APK fusing is honored when the target device runs on API < 21.
Are dynamic features good for case when you want to have separate modules (ex. Login, Profile Details, etc) or better to use library module?
I recommend using dynamic feature modules for user facing features. So e.g. Profile, Login, Shopping Cart, PremiumWhatever can be good starting points.
There are advanced use cases for saving more on device space, but these rely on delayed delivery via on demand or conditional delivery.
For more information I recommend taking a look at the Plaid sample app or watching one of the presentations on the topic.
the dynamic feature needs to use with app-bundle, not APKs.
When you debug the app, you could include the dynamic feature by modifying your existing run/debug configuration.
Firstly, select your desired Android App configuration, then
under dynamic features to deploy in the General tab, check the box next to each dynamic feature module you want to include when deploying
your app.
If Build APKs option would be selected, then it will create multiple Apks same as the number of dynamic features into your app.
But it seems the requirement is to create a single APK having all the dynamic features, so to do that
a) For debug builds :
Edit Configuration -> General -> (Look for dynamic features to deploy option) -> Select all the dynamic features to include them into the build -> Apply -> OK
b) For release builds :
Generate the signed App Bundle and follow below steps:
i) Download the Bundle tool from the below link :
https://github.com/google/bundletool/releases/download/1.5.0/bundletool-all-1.5.0.jar
ii) execute the below command in the terminal or android studio terminal in the same directory of above bundle too
java -jar bundletool-all-1.5.0.jar build-apks --bundle {path/of/yours/.aab} --output {output/path}/name-of-output.apks --ks <key-path> --key-pass pass:{key-password} --ks-key-alias {key-alias}
--ks-pass pass:{key-alias-password} --overwrite --mode=universal
Replace {} strings with your own values, after executing above command it will create a univeral .apks file. (Note it is .apks , not .apk)
iii) To install .apks into the device:
adb install -r <output/path>/name-of-output.apks
Hope it would help.
I want to make my Android code “open source” and this link says there is certain sensible information in the build.gradle files that should not be published:
https://developer.android.com/studio/publish/app-signing.html#secure-shared-keystore
The thing is that I cannot see such information in my build.gradle files. No passwords nor anything sensible. I sign the apk with a digital certificate by using Android Studio’s “wizard”.
Could it be that the link above is out of date and perhaps, with a new Android Studio version that sensible information is not put in the build.gradle any more? Or what am I missing?
Thanks
Android Studio doesn't add anything to your build.gradle files. The so-called 'wizard' uses standalone jarsigner, and the credentials are provided each time or cached by the IDE, so it's like you used the second method.
The first method describes a way to sign apks using a gradle task, which is also an option, but it seems, not the one you're using.
To conclude, you don't need to provide signing config to build.gradle to have the ability to sign apks. So unless you have any other secure keys in your files, you should be fine.
I've got a handful of side-project apps on the go at home, I've setup a Jenkins installation to check them out and build APKs, which I then transfer over to my handset and play around with.
I'm looking to release some of these freely on the market, so I need to sign them with a certificate and prepare the final APK.
Is it possible to do this from Jenkins? For example, could I have one build target that generates my "in development" APKs, and also have that target (or another) create the final APK files ready to go?
Any advice?
If the signing is possible to do automatically (by command line or similar), then the answer is "Yes".
There are several ways to achieve this, but firstly: Is there any good reason not to sign every build?
Signing every build would mean that you don't need any extra configuration to create a releasable artifact, and you know that what you test and what you deploy are the same things.
If you want to be selective about what builds you sign, two approaches come to mind:
Parameterized builds: These are environment variables that can be customized when you click Build now. You can add a flag that you later react on in a build step.
Add another job that picks up the artifacts from your main build job and signs them, using https://jenkins-server/job/jobname/lastSuccessfulBuild/artifact/ or one of the approaches here: How to access Hudson job1 artifacts from another job2?
In the standard Android ant build file is a release target contained. This will if started without further configuration just build an unsigned apk. As Christopher pointed out to do a signed build you can use key.store, key.store.password and key.alias,key.alias.password to configure your keystore and generate signed apks through the ant script. The documentation on this may fprovide further information on configuring the build.
Yes... the easiest way imho is to automate it with Maven Android Plugin. The samples project has the MorseFlash example I wrote in there that has the whole release process automated including jarsigning, zipaligning and proguard runs, switching between development and production config and more.
This can all be done on the command line and therefore on Hudson. Btw if you are interested I did presentations about Maven and Android as well as testing and CI for Android at AnDevCon and the slides are on my web site. http://www.simpligility.com
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.