I have a problem with running Appium on my Android app. On release build, everything works fine. I'm able to run some basic test cases etc. The problem is when I switch from release to debug build. For debug, Appium is not able to open the app, there is a black screen and then error:
Exception in thread "main" org.openqa.selenium.NoSuchElementException: An element could not be located on the page using the given search parameters.
....
On emulator app is opened but this error still occurring with the same stack-trace (and again, release build works just fine)
I've tried already running my tests on different android versions (API 23, 24, 28) and results always the same.
I'm using AndroidDriver to find elements by id and click on them.
Is any reason why release builds works but debug not. Is there something I can do in order to run my tests on debug build?
Edit 1. My application is a Native Android app.
I'm not able to open the debug app with the Appium desktop (I just see the Android home screen because Appium is not able to run the app).
According to differences between debug and release:
release build (exact opposite for the debug build):
debuggable disabled
minify enabled
shrink resources enabled
proguard enabled
Plus release build is signed
Related
Iam using Android Studio, and generated APK with build generate signed bundle / APK. In some Android phone it's works, but in other phone it could be cannot installed or install with can't execute properly some function.
My APK :
https://github.com/budim12/TPGAPK/blob/master/tpg-v0.3.2.2.1.apk
How i can check it / trace it / solve the problem, in phone with error function when i run this app. I test with usb mode, but nothing error pop up, but when i use APK, it got error function.
Add Note for broken app but success install :
Could show login menu, could check if its empty input box or not
But fail when get data json from API web services
Build Gradle link (remove space) :
https://pastebin .com/UkTSLcp5
Signed APK :
Thanks.
Comment this line for future use
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
in release mode , you enabled proguard .it should be enabled in production .keep in mind, if you are in test mode it's better to disable or remove it but in production mode you should configure it .
Sory, for some apps that can't install is cz unmarshalling i see in debug usb mode, more spesific in mode No debuggable processess, so i check all output, and found that word.
Then found this link..
Cannot update the app after updating SDK (app not installed)
So, this is my mistake, i need to check in V1 (Jar Signature) and V2 (Full APK Signature) and it works.
But, it solve only this partial case, for other android case, which is could install but got error function still unsolved..
I am attempting to build a signed Android APK from my React Native application. I have followed the official documentation and numerous third party sources to get code signing set up properly, and it comes down to running this command to generate the signed APK...
$ cd android/
$ ./gradlew assembleRelease
The APK is signed properly and placed at app/build/outputs/apk/app-release.apk. I've even managed to successfully upload this APK to the Play Store through an internal testing track.
The problem is that when the app first launches, it asks the user to grant overlay permissions and displays a message in a toast explaining that the permissions are required for React Native's debugging tools to function. Fixes for this are documented in a few places, but those fixes don't seem to work because the app doesn't seem to understand that it's not in development mode.
The app also displays a stack trace in the traditional React Native "big red error" box whenever a runtime error occurs in the app, rather than crashing or swallowing the error which is the behavior I see when building the app on iOS in production mode. When this happens the error mentions being unable to connect to the packager.
Pressing Cmd + M or shaking the device opens the React Native debug menu. process.env.NODE_ENV also has a value of development.
When investigating, I've found that BuildConfig.DEBUG is false, as expected. The app does use a packaged bundle generated at build time, and operates independently from the React Native packager.
I've attempted to manually create the index.android.bundle using react-native bundle as described here, but the bundle file seems to get recreated and replaced when running ./gradlew assembleRelease. It's as if the --dev flag isn't getting set to false when react-native bundle is being ran.
Here are my Node, React, and React Native versions...
Node: v8.11.3
React: v16.2.0
React Native: v0.51
My best guess is that despite the fact that it's being built in production mode, React is not getting the memo and is instead operating in development mode. Where should I look to see if everything is configured properly? Are there React Native bundle generation settings that might have gotten messed up?
It is possible the override for getUseDeveloperSupport in your MainApplication.java is incorrect.
The issue here indicates that this may be hard-coded to true. If that is the case, change the return value to BuildConfig.DEBUG instead.
I used to test my Android apps (min API 21, target 25) in an API 21 AVD. After clicking the "run app" button in Android Studio, a debug APK was built in {project}/app/build/outputs/apk/. I then copied that APK to my physical API 25 device for further testing.
Since upgrading Android Studio from 2.2.3.0.145.3537739 to 2.3.0.8.162.3764568 on Gentoo Linux, those autogenerated APKs no longer run on the physical device. The apps crash instantly upon startup and the log shows a "java.lang.RuntimeException: Unable to instantiate activity" caused by a "java.lang.ClassNotFoundException: Didn't find class {my main activity class}".
When I build a debug APK manually by clicking on "Build > Build APK", the generated APK has a different file size than the autogenerated one, plus it runs on the physical device without any complaints.
So, there are actually two questions:
1. Why does the manually generated debug APK differ from the autogenerated one?
2. What is causing the autogenerated one to fail on my physical device since Android Studio 2.3? It worked fine with all Studio versions before.
Hoping for some insight, even though USB debugging exists and the process of copying the debug APK to the device is actually pretty pointless. :-)
As a recap of the comments to the question, if Instant Run is enabled then generated debug apk will contain device API specific code hence rendering it not usable on other APIs that it was not built for. Turning off the Instant Run would solve that.
I have Xamarin.Forms (v2.2.0.31) targeting Android that uses ADAL 3.13.1 in Visual Studio 2015.
When I load the app using Debug configuration it works as expected. After signing on once the Active Directory Authentication Library (ADAL) uses the Token Cache even if I close the app out completely and go back into it.
However, when I open the exact same project in Release mode it prompts me for credentials again.
When I attached Log Cat it shows the following when I access my Web API in DEBUG mode...
CacheType: Microsoft.IdentityModel.Clients.Activedirectory.TokenCache (1 items)
Log Cat shows the following when I access my Web API in RELEASE mode...
CacheType: Microsoft.IdentityModel.Clients.Activedirectory.TokenCache (0 items)
...then it prompts for credentials again.
This happens only after closing the app out completely otherwise it must keep it in memory. Do I have to enable special permissions in the Android Manifest for persistent token caching to work in Release mode?
EDIT: Ok, the problem has to do with Linking Behavior in the Android Project Properties > Android Options > Linker Tab. In release mode I was Linking SDK Assemblies Only to reduce space but apparently ADAL uses reflection and it's excluding some needed files. So I changed it to None and it work (but it bloated my app pretty good). Is there anyway to make this work and still link SDK Assemblies?
More information on linking behavior here...
https://developer.xamarin.com/guides/android/advanced_topics/linking/
There has been issues with linking libs. Seems it's not fixed.
Try skip linking these:
Microsoft.IdentityModel.Clients.ActiveDirectory;Microsoft.IdentityModel.Clients.ActiveDirectory.Platform;System.Runtime.Serialization;
Especially, I think just skip System.Runtime.Serialization would work.
Cheers,
Max
This is a known issue with DataContractSerialization. When ADAL fails to write the cache blob, it simply swallows the exception. https://bugzilla.xamarin.com/show_bug.cgi?id=37491
I've been developing an app for a while and now I want to hand it out to friends for testing. The app works perfectly when debugging to my device but when I build and sign the apk and move it to my device I can install it without any errors but it will not run (I don't even get any error messages). Sometimes the screen goes black as if the app is about to start but then it just reverts back to the previous screen (One time the Monogame splash screen appeared before it reverted to the previous screen).
Here is what I have done so far and any specific details:
I'm using Visual Studio Professional 2014 with Xamarin.Android 4.20.
I'm creating my app using MonoGame.
I have cleaned and built my app in Release mode.
These are my packaging options:
These are my linker options:
(I believe choosing "None" only means my apk will be larger).
I created a keystore using Java's keytool.
I created and signed the apk using Xamarin's Visual Studio "Publish" command.
After all of this the apk will still not run.
So it turns out this was nothing to do with the signing or building of the release mode apk, it was actually down to an exception which was only being thrown when the app was built in release mode (I have no idea why this was the case).
The thing that was throwing the exception was the DotNetZip library, I'd post an issue on it's page but it looks like the project is dead anyway (Also, they don't explicitly support Xamarin Android).
My solution was to use ZipStorer alongside Mono's .Net compression implementation. Everything works nicely now.