java --version: 15.0.2 stackzy version: 1.0.7

Cool app and nice UI! But...

Issue: Created new Google account as suggested but always get BadAuthentication status when trying to login.

Describe the bug

I've downloaded Stackzy-linux-x64-1.0.0.jar from the releases (v1.0.0-beta03) and executed with java -jar Stackzy-linux-x64-1.0.0.jar, but am getting below error

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
	at java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:335)
	at java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:268)
	at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:273)
	at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:230)
	at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:759)
	at java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1038)
	at java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:69)
	at java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:873)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:807)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:719)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:642)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:600)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:427)
	at java.base/sun.launcher.LauncherHelper.loadMainClass(LauncherHelper.java:760)
	at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:655)

To Reproduce Steps to reproduce the behavior:

1. Download any uberjar from here
2. Execute it using java -jar Stackzy-*.jar
3. See error

Expected behavior Should launch Stackzy window

Screenshots

Desktop (please complete the following information):

• OS: Ubuntu 16.04
• Stackzy Version: v1.0.0-beta03

Additional context Add any other context about the problem here.

While testing the app I found two bugs which was related to adb source selection. 1- Wrong cast apk source Steps:

• Connect android device or Launch android emulator
• Select pathway adb
• Select device
• Observe

App is crashing with exception

 class com.theapache64.stackzy.model.AndroidDeviceWrapper cannot be cast to class com.theapache64.stackzy.data.local.AndroidDevice (com.theapache64.stackzy.model.AndroidDeviceWrapper and com.theapache64.stackzy.data.local.AndroidDevice are in unnamed module of loader 'app')

The issue is we are casting to wrong type The fix is in commit: 7c9a7e115d1ff75f27414395825596b250527472

2- AndroidApp with empty package name Steps:

• Fix first bug
• Connect android device or Launch android emulator
• Select pathway adb
• Select device
• Observe

App is crashing with exception

Char sequence is empty.
	at kotlin.text.StringsKt___StringsKt.first(_Strings.kt:71)
	at com.theapache64.stackzy.model.AndroidAppWrapper.getAlphabet(AndroidAppWrapper.kt:28)

The issue is pm list packages is returning string which ends with \n and when we split the string we create a package with empty string. The fix is in commit: 7c9a7e115d1ff75f27414395825596b250527472

Unfortunate I was unable to add test for the SelectAppViewModel because unit test was failing with weird exception

@Composable functions must be marked with the @Composable annotation

Stackzy uses a gloabl caching mechanism, which works as a centralized caching system. Means, if someone decompiled WhatsApp, the next time you try to find the stack, it won't be decompiled and the result will be served from the cache.

• What if the decompilation done was done long back, and the new requests with more recent APKs are also served with stale data.

Desktop (please complete the following information):

• OS: macOS Big Sur
• Version 11.2.3
• I used it on M1 mac.

Additional context Java sdk version is 16.0.1

Describe the bug the build with return: An unexpected error occurred while trying to open file /private/var/****/apk-tool.jar

To Reproduce Steps to reproduce the behavior:

1. Go to 'ADB, SELECT Nexus 5x, '
2. Click on 'Musically, com.zhiliaoapp.musically'
3. Waiting to build with
4. See error: An unexpected error occurred while trying to open file /private/var/****/apk-tool.jar

Expected behavior list all library of Musically app

Actual behavior A clear and concise description of what actually happened.

Screenshots

Desktop (please complete the following information):

• OS: [Mac mini]
• Version [11.4 Big Sur]
• java version: [1.8.0_141]
• Nexus 5x: [Android 10, Pixel Experience OS]
• stackzy version: [1.0.5]

At bottom of decompiled library listing page there is sharp cut at bottom of the recycler view you can put gradient so fade at bottom side it will looks better. Here I am attaching your current page screenhot as well suggested design screenshot.

Is your feature request related to a problem? Please describe. It will solve slow internet related problems

Describe the solution you'd like APK should be downloaded to servers and results should be shared on clients. This will speed up the process and effective caching can help to display results with much ease.

Login When i tried to login, it shows snackbar with message "NeedsBrowser". Then i check the logcat and it shows this log.

Register When i tried to register, the link that i got redirected at gives 404 error.

Additional Info: Tested both with released .msi in version 1.2.3 and the current master branch which built using IntelliJ. I am using Windows 11.

Build fails on macOS + JDK17 with exception:

FAILURE: Build failed with an exception.

* What went wrong:
Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the User Manual chapter on the daemon at https://docs.gradle.org/7.1/userguide/gradle_daemon.html
Process command line: /Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/bin/java -XX:MaxPermSize=1024m -XX:+HeapDumpOnOutOfMemoryError --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx2048m -Dfile.encoding=UTF-8 -Duser.country=UA -Duser.language=en -Duser.variant -cp /Users/artemkalachyan/.gradle/wrapper/dists/gradle-7.1-bin/4pslxx9lrxt5svtz5wbnb6tkz/gradle-7.1/lib/gradle-launcher-7.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 7.1
Please read the following process output to find out more:
-----------------------
Unrecognized VM option 'MaxPermSize=1024m'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

after removing -XX:MaxPermSize=1024m from gradle.properties builds correctly.