Develop Reference

Kivy App working on pc but not in android

I have made an apk by converting .py kivy with the help of buidozer in google colab. The earlier versions were working but now latest version is not working.
May be there is a problem in my .spec file so I am attaching it ...
At first I think my assest(images) are causing this problem but after removing them too it's not working.
I have done some research and got this buildozer -v android debug deploy run logcat but I don't know how to execute and use this command....
.spec file link : https://github.com/AyushRaj0305/APP/blob/main/.spec
All I want is that my apk should work in android
Thanks for Help

I have same issue in past and I solve by adding requirements in .spec
This requirements work for me:
requirements = hostpython3==3.7.8,python3==3.7.8,kivy==1.11.1, certifi,chardet, lxml, docutils, future, idna, Kivy-Garden, Pygments, requests, six, soupsieve, urllib3, deep-translator, arabic-reshaper, python-bidi, openssl, pyopenssl, numpy, pytz, python-dateutil, pandas, setuptools, zope.interface, datetime
you have to write all modules and parent module in requirements which your app is using.
To know module which you app is using has two method:
run command pip freeze in current app folder in powershell
install all the module as below photo which help to install your application module
I have debugged your code and found missing PIL

How to dynamically specify app name on automatic when using gitLab ci/cd

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

One command for multiple deployments

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.

How to run malloDroid script?

I want to check SSL verification in my application. I downloaded on my santoku malloDroid.py and try use it (of course earlier I have read that script is an extansion of Androguard). I simply run mallo app: ./malloroid.py -f test.apk and i got import error that there is no androguard module. How to run malloDroid script to verify ssl?

In order to use MalloDroid, you need to have AndroGuard. Setting up Androguard is quite straight forward. Read more about installation here .
Once you have Androguard set up along with the proper environment variables, you can use Mallodroid as follows :
./mallodroid.py -f test.apk -x
This will most likely work!

android build release apk on jenkins, without storing my password in plain text

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.