I am still relatively new to Android development using Android Studio.
I understand there are three common scenarios when designing an Android application:
everyday debugging (using 'Debug' variant): no special configuration is needed in the build.gradle file. The application can be debugged right away, out of the box. No signingConfig declaration is required, the default gradle file can be used. Somehow, Android Studio takes care of everything by signing the app under the hood.
testing the 'Release' variant: the application MUST be signed explicitly to run on the device.
The following can be specified in build.gradle to assign the debug-variant signing file to the release variant:
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.debug // this line
}
}
Once this is done, the Release variant can be run (and tested) on the device.
App-bundle (.aab) deployment to the Google Play Store (in my case).
Although I am obviously using the release variant for deployment, I noticed that the signingConfig line highlighted above does not need to be present in the gradle.file when doing Build > Generate Signed Bundle / APK... and then typing my keystore's passwords. The AAB file generation works with or without this line.
My questions are:
is this line really ignored during AAB generation? I don't want to have my AAB generated with a debug signature! Can I safely keep it uncommented in my gradle file? So as to be able to test my Release variant on a regular basis on the device before deploying.
is it useful to sign my Release variant in my build.gradle file with any other certificate than signingConfigs.debug, such as something derived from my upload-keystores.jks file, that I already created?
Related
I have an app where I need to be able to build apk files for testing, and aab files for uploading to the play store. The apk and aab files should be signed with different keys.
How can I specify different signingConfig blocks depending on whether the build is run with assembleRelease vs. bundleRelease? It seems like this should be a flavor-like thing but I can't figure out how.
You can create a new build type say "store" in addition to "debug" and "release", and give the store build type the required signing config:
android {
buildTypes {
register("store") {
initWith(buildTypes["release"])
matchingFallbacks.add("release")
signingConfig = signingConfigs.create("store") {
...
}
}
}
}
Then:
./gradlew :app:assembleRelease :app:bundleStore
From https://developer.android.com/studio/build/build-variants (emphasis mine):
For example, a "demo" product flavor can specify different features and device requirements, such as custom source code, resources, and minimum API levels, while the "debug" build type applies different build and packaging settings, such as debug options and signing keys.
I have read all of the threads about SonarLint not being in synch with SonarQube, but it's just not clicking.
I created a simple Maven project to test SonarLint & SonarQube. I added the sonar-maven-plugin to the project and then ran mvn sonar:sonar.
The project was uploaded to SonarQube. When I looked in SonarQube, I see that it shows squid:S2699 (junit test doesn't have an assertion) as a blocker.
However, in eclipse, there is no such issue shown by SonarLint.
I purposely chose this one as it's not a PMD/FindBugs/Checkstyle issue.
I have verified that squid:S2699 is active on the server. Obviously it is, because SonarQube displayed it.
There is only 1 Quality Profile: SonarWay.
Edit: I am in connected mode.
Does anyone have any idea why?
I am using:
Eclipse Neon.3 Release (4.6.3)
sonar-maven-plugin 3.0.2
maven 3.3.9 (the one embedded in eclipse)
SonarLint 3.2.0.201706271328
SonarQube 6.3 (build 19869)
Here are the screenshots as proof.
It seems your test file is not treated as a test file, but as a source file. I say this based on the kind of errors that are reported (remove unused variable) and the kind of errors that are not reported (no assertions).
As you might know, different rules are applied to sources and tests.
SonarLint decides whether a file is a test file or not based on the Test file regular expressions preference, which you can find in Window / Preferences / SonarLint. The default value is **/*Test.*,**/test/**/*,
this seems to work well in a wide range of cases, and looking at your screenshot, it should work for yours too.
So first of all verify this setting.
If the value is different from the default,
I suggest to change it back to the default as a sanity check.
Then you can tweak the value according to your needs.
It's also good to verify that my theory is correct about SonarLint treating the file as test instead of source, by inspecting the SonarLint Console:
In the Console view, click on the Open Console dropdown, select SonarLint Console
In the Configure logs dropdown enable Verbose output
Trigger an analysis of the test file (make a change and save the file)
You should see output like this:
[
baseDir: ...
workDir: ...
extraProperties: ...
inputFiles: [
/path/to/your/test/SonarProofTest.java [test]
]
]
The [test] at the end of the filename indicates the file is treated as a test file. If it's not there, then the file is treated as a source file.
one of my teamcity builds generates an xml file and I am wondering if there is a plugin to display the file generated against the build.
This file happens to be the android lint results of my android application project but I couldn't find an android lint specific plugin to handle the whole process so I am trying to make the same thing on my own by running the mvn android:lint command of the android maven plugin and then access the xml file somehow.
UPDATE: with regards to the android lint stuff, Teamcity has integrated the Intellij inspections that include lint checks (i think) so I think I should be ok with that.
Overall though, and mostly just out of plain curiosity do you reckon there is a way to display generated files against a build, rather than manually accessing the folder where they got generated?
You can use Build Artifacts or you can use the Teamcity Reporting feature.
It seems that XCode always builds both Debug anŠ² Release configurations (see screenshot attached). I can't untoggle "Profile" option. I need to build Debug version only in 95% of my time. How can I save time by not building Release version every time I press "Build"?
By default, XCode practically always build for Debug, in Release XCode build only when you select from menu Archive or to Profile (shortcut cmd+I) and you see this because when selected you see XCode build your project.
The tab you selected just shows the target(s) (MagicCards1 here) that will be built for each action (Run, Profile, Archive...).
Only one build will be made with the appropriate build configuration (Debug, Release, ...) for any given action: your screenshot shows that the 'Debug' configuration will be used to build your target when you run your project, leading me to think that Xcode already does what you're expecting (and that it'll only compile the source files that changed since the last build).
You can try to compare Debug and Release builds made from scratch by cleaning (Shift+Cmd+K) and building (Cmd+R) with different build configurations in the scheme's Run settings.
You should also check if 'Build Active Architecture Only' is set to Yes and if 'Analyze during Build' is set to No in your Build Settings:
You may also want to watch this WWDC 2013 video: Xcode Core Concepts 401. Schemes are covered around the 44'-mark.
https://developer.apple.com/videos/wwdc/2013/?include=401#401
I have a set of apps which are basically white labels of one app. The basic app has a web backend. With ant, when I ran the debug build of a white label app, the library project was compiled as debug with dev_server parameters and when I compiled a release build, the live_server parameters were used. Other parameters (and resources) were overridden by the white label app and it all worked pretty well.
So basically, if I compiled a white label for app 1 and debug build, the app was compiled for <dev_server>/1 as the basic service address and so on.
With gradle, I've tried different strategies but can't get it to work quite as conveniently without setting each parameter in each app's build.gradle.
The basic problem seems to be that a library project with gradle always builds in release so I can really change backend parameters based on what build I'm using.
Any ideas how to set up the project structure to make it work that way?
Instead of library project, try going for the productFlavour concept as mentioned here http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors