I'd like to know if some of you worked out how to generate signed APKs and IPA with multiple configurations (ie : beta for hockeyapp, and production for stores) in a single command.
I'm exploring all the possibilities there, it looks like there are lots of ways to do this.
I'd also like to be able to pass a variable like ENVIRONMENT to set Javascript constants such as an API url or turn on/off debugs.
Here's what I'm thinking right now :
Using https://www.npmjs.com/package/react-native-config to solve the former problem.
On android :
I'm thinking about adding a type in buildTypes in gradle. So far, I couldn't get it to work, I'm not very experienced with native configurations.
I would then make a bash script to create the offline bundle with the chosen env (staging / dev / prod) and use gradle's assembleRelease / assembleBeta. Do you think that's doable ?
On iOS, it looks a bit more complicated :
It looks like it's hard to change the project's configuration in CLI when building. So I was thinking that I should duplicate the project for each environement : project-dev.xcodeproj, project-prod.xcodeproj... you got the point.
Once again, I would make the bundle, then cp it inside the given project. A nice touch would be to trigger the xcode compilation in CLI too, I don't know if this is hard to set up.
What do you think about this ? Maybe some of you are already using custom scripts to do that ?
The icing on the cake would be to use HockeyApp's 'puck' cli tool to upload it, but that should be quite easy to set up once the application has been build for both iOS and Android.
This is the process I use for command line build with parameters. My system builds a release version .ips file and then copies and resigns that file with a development provisioning profile that I can put on my development devices to test exactly what is being sent to the customer or to the app store. Not all of this will be useful to you, but hopefully some will.
First, I have a variables file that sets the global parameters that I'm going to use for the build:
Scheme="(The scheme I am going to build inside my project)"
WindowsSavePath="(path to my source archive directory on a shared computer)"
InstallSavePath="(path to my .ipa archive directory on a shared computer"
Customer="(relative path inside archive directories)"
Fleet="(Continued relative path)"
PathToProject="(path to the folder on my Mac with the xcode project file)"
ProjectName="(project name).xcodeproj"
PlistPath="$Scheme-Info.plist"
appScheme="$Scheme"
AppName="(The name that I want to give my .ipa file)"
Version="(The version number for this build)"
AppendedFileName="-QA" //I use this for QA and Production distinction
exportPath="$InstallSavePath/$Fleet/$Customer/$Version$AppendedFileName/"
CompanyAppIdentifierPrefix="(my generic provisioning profile identifier)"
ArchiveLocation="$WindowsSavePath/$Fleet/$Customer/$Version$AppendedFileName"
SourceCodeDestination="(my compiled absolute path to the archive directories)"
This is all contained in a SetVariables.sh file. Now we get to start building the project. In another .sh file first I call the SetVariables file, then I start compilation:
#Update the version number in the plist file for the project
/usr/libexec/PListBuddy -c "Set :CFBundleShortVersionString $Version" "$PathToProject/$PlistPath"
/usr/libexec/PListBuddy -c "Set :CFBundleVersion $BuildVersion" "$PathToProject/$PlistPath"
#Now build and archive the project, the create the .ipa file for either submittal or giving to customers
mkdir -p "$exportPath"
mkdir -p "${ArchiveLocation}/dSYM"
xcodebuild -project "$PathToProject/$ProjectName" -scheme "$Scheme" DSTROOT="$exportPath" DEBUG_INFORMATION_FORMAT="dwarf-with-dsym" DWARF_DSYM_FOLDER_PATH="${ArchiveLocation}/dSYM" archive -archivePath "$exportPath${appScheme} $Version$AppendedFileName.xcarchive"
/usr/bin/xcrun -sdk iphoneos PackageApplication -v "${exportPath}Applications/${AppName}.app" -o "${exportPath}${appScheme} $Version$AppendedFileName.ipa"
#Now resign and create an internal dev version to test on development ipads
rm -r Payload SwiftSupport
unzip -q "${exportPath}${appScheme} $Version$AppendedFileName.ipa"
BUNDLE_ID=$(/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" "Payload/${AppName}.app/Info.plist")
. ./CreateInternalEntitlements.sh "$CompanyAppIdentifierPrefix.$BUNDLE_ID"
. ./resign.sh "${exportPath}${appScheme} $Version$AppendedFileName.ipa" "${exportPath}${appScheme} ${Version}${AppendedFileName} Internal" internalDev.mobileprovision "(My developer account tied to the internal provisioning profile" Entitlements.plist
rm -r Payload SwiftSupport
#Now delete the intermediate files from the installs directory
rm -rf "$exportPath${appScheme} $Version$AppendedFileName.xcarchive"
rm -rf "${exportPath}Applications"
I have left out a few things in there (resign.sh, createentitlements.sh), but those processes I found on stackoverflow, so it shouldn't be too hard for you to find as well.
I've never done it, but I'm relatively certain that you can change the command line arguments for the xcodebuild to build either release or debug like you are trying to do. You could also run the xcodebuild twice, once for debug and once for release, and save the builds to different locations.
I hope this helps you at least a little with your goals. This took my a week or two to put all together and get working for my needs. Good luck.
Related
In the Android project that I am working on, we are using GitLab CI/CD to automatically build and upload in Diawi the .apk file. In current settings build application's name is static because it needs to be known and sent to the Diawi framework as a curl request. The script looks like this:
- ./gradlew assembleRelease && cp app/build/outputs/apk/release/app-release.apk app-release.apk && curl -v --http1.1 https://upload.diawi.com/ -F token=$DIAWI_TOKEN -F file=#app-release.apk -F find_by_udid=0 -F callback_emails="mymail#company.com"
But this causes some troubles during the manual testing because the .apk files with the same name can be easily mistaken or overwritten.
My idea is to add some metadata in the .apk file's name to be unique and to avoid such errors. Do you have any ideas about how this could be done?
First thing you can do is create version bump functionality. You can do it via version bumping tool and git sync.
For version bumping you can use our open source tool - https://github.com/relizaio/versioning . Now, assuming that you sync via a file called apk_version, you first initialize this file with the current version like:
docker run --rm relizaio/versioning -s YY.0M.Patch > apk_version
Then in your CI context, you can bump it with something like
docker run --rm relizaio/versioning -s YY.0M.Patch -v $(cat apk_version) -a bump > apk_version
Now, in GitLab CI you need to have a block that resolves this. Note, that you also need to commit apk_version file at the end of the bump.
For inspiration - see this question How to grant permission for semantic-release to push code to master and also our sample CD project on GitLab - https://gitlab.com/taleodor/sample-helm-cd/-/blob/master/.gitlab-ci.yml
Also my article here may be helpful (note it's a bit outdated at this point): https://worklifenotes.com/2020/02/27/automatic-version-increments-with-reliza-hub-2-strategies/
Finally, for other things that you can add to version GitLab has a list of pre-defined env variables that you can use in whole or partially as modifiers: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
ti build --p android --T dist-playstore
I build android application like this but, it require android keystore file.
Where is the keystore file used to sign the app?:
I need to type my file path.
I would like to shortcut like
ti build --p android --T dist-playstore --key my/key/path.keystore
however can't find the right option, is there any option for this purpose ??
Have you looked at the documentation? Link
There are 2 options to do it, as per doc: -K, --keystore <path> So either -K or --keystore
I have Qt application to deploy on Android. I am using command line build to generate an apk signed with my .keystore file. I am well able to do it using following command where I am using androiddeployqt.
androiddeployqt --sign my_key.keystore myAlias --storepass my_password --output android --verbose --input my_app.so-deployment-settings.json
Above command works great from my shell script to generate a signed apk. But I want to avoid writing my password on the command as done above. Typing androiddeployqt -help shows that there is a --sigfile <file>: Name of .SF/.DSA file option that I can use. But I don't know how to create this sigfile of extension .SF/.DSA.
Can someone please suggest how to create a sigfile of extension .SF/.DSA which I can use with androiddeployqt command with --sigfile as option ? Am I correct in understanding that I need a file of extension .SF or .DSA ?
Or, is there some other way I can hide my password from showing up on the script's code ?
Okay, I had to look at the oracle docs..as long as you have a keystore cert you supply the sigfile names it it creates those files for you per:
https://docs.oracle.com/javase/tutorial/deployment/jar/signing.html
and the qt tool you are using plugins into that so you should be good to go
I need to be able to build the release version of my apk, using a Jenkins job.
From reading the following SO question
How to create a release signed apk file using Gradle?
I understand I can do it in one of two ways. Either get the user to enter the password at cmd prompt, or store my password details in a plain text file that doesn't get committed to git, and lives on my local machine.
Neither of these will work when running the build job on jenkins though. 1) I can't gain user input because this may be running in the middle of the night (I don't even know how to get user input from the cmd line even if the user was at their machine) 2) Anyone who can gain access to that build box, would be able to cat the contents of that file either via the cmd line or from another build.gradle job running on that jenkins server.
Does anyone know of anyway I can keep my password hidden but so that the Jenkins job can access it?
Thanks
You can use Mask Password Plugin, which does just that. Or the same functionality is included in EnvInject plugin, and sooner or later all Jenkins projects get a need for EnvInject plugin (that does many other things), so might as well start using it now.
To securely use a password from within a build/post-build step
Install EnvInject plugin.
Under Jenkins Global Configuration, find Global Passwords section.
Add a name (this will be the environment variable name) and password (will be starred **** ).
Under Job Configuration, find Build Environment section.
Checkmark Inject passwords to the build as environment variables.
Then checkmark Global passwords.
In any build step, you can now use $name (as defined earlier) to refer to a password as you would if you were typing it in plain text.
The password variable is injected only at job execution time (typing $name on command line of the server by itself will not produce anything, and like all Jenkins variables, it is not persistent).
The job console log will show **** instead of password, if it appears.
You could configure passwords per job, rather than globally, so that other jobs can't use it.
The only security concern is that if someone has administrative permissions to configure your job, they can write echo $name > secretpassword.txt into a build step, and then review the file in the workspace. But you should be careful who you assign administrative rights to.
You should take a look for this plugin
https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin
If your Jenkins instance happens to be running on EC2, and you don't want to permanently store secrets in the file system, you can put the store and key passwords into Systems Manager Parameter Store, then query them at build time. In addition, you can put the keystore itself into external storage, such as S3, and only keep it locally for the duration of the build.
Here is a sample build script (assume that the secret parameters are named android-keystore-pass and android-signature-key-pass):
set -o errexit
set -o pipefail
keystore_file=keystore.properties
keystore=wise.jks
aws s3 cp s3://path-to-android/$keystore .
chmod go-rwx $keystore
touch $keystore_file
chmod go-rwx $keystore_file
cat > $keystore_file << EOF
storePassword=`aws ssm get-parameters --names android-keystore-pass --with-decryption | cut -f4`
keyPassword=`aws ssm get-parameters --names android-signature-key-pass --with-decryption | cut -f4`
keyAlias=android
storeFile=$WORKSPACE/$keystore
EOF
An example of the Gradle build scripts can be found in this answer. You can commit a dummy keystore.properties to source control so that (non-release) builds work on dev machines.
There are also open-source secret distribution tools that are platform-independent, e.g. Vault, but I haven't tried any of them.
I know of
ant coverage
However that does a few things, it compiles with emma instrumentation, installs, and runs the test apk. I don't want it to run the test suite through ant with coverage because I need to run it with some extra hooks, and I don't want to run the large test suite twice. So far I have tried this
Target_Project/build.properties
emma.enabled=true
Test_Project/build.properties
emma.enabled=true
Then in in a shell I execute this.
Target_Project$ ant debug
Target_Project$ adb install bin/Target_Project-debug.apk
Target_Project$ cd ../Test_Project/
Test_Project$ ant debug
Test_Project$ adb install bin/Test_Project-debug.apk
Test_Project$ adb shell am instrument -e coverage true -e coverageFile /sdcard/myFile.ec -w com.my_app.testproject/android.test.InstrumentationTestRunner
The response is
Error: Failed to generate emma coverage. Is emma jar on classpath?
So is there a trick to getting the apk to build with the emma libs? I tried invoking the targets created in the sdk xml templates but they are "private." Is there something I am missing?
Well for anyone interested. The SDK documentation is completely busted (surprising I know). Basically you have to do this,
take the base build.xml generated by android create-project and change the tag
<setup/>
and change it to
<setup import="false"/>
Now the documentation will tell you to copy from SDK/platform-/templates/android_rules.xml and place that into your build.xml ...
THIS IS WRONG and horribly unmaintained. This rules file isn't used by anything. What is used are the rules inside of SDK/tools/ant/. Grab the appropriate file for your type of project (library for a library project, test for a test project, or vanilla for a regualr project) with the latest _r and
copy the contents of it's root node into your build.xml. Insert it after the setup tag. If you don't use the files inside the ant directory, you will not be able to compile project libraries through the ant script. I was so glad they maintained documentation on how to do this.
Now you can change whatever you like in the build file to match your build needs. In which case I just made install-helper call my wrapper around adb which returns interpreted resultcodes.
// coverage.py
development\testrunner\coverage.py
def TestDeviceCoverageSupport(adb):
"""Check if device has support for generating code coverage metrics.
This tries to dump emma help information on device, a response containing
help information will indicate that emma is already on system class path.
Returns:
True if device can support code coverage. False otherwise.
"""
try:
output = adb.SendShellCommand("exec app_process / emma -h")
if output.find('emma usage:') == 0:
return True
except errors.AbortError:
pass
return False
adb shell exec app_process / eamm -h
build core images
http://duykham.blogspot.com/2009/09/how-to-get-emma-code-coverage-of.html