Office Hours Transcript: 2021-05-08

Tad joined

hello, Tad!

Hey Mark

Notifications permission granted.

how can I help you today?

I’ve been having a few issues since upgraded from AS 4.1.3 to 4.2

It’s super annoying.

I have held off on that upgrade so far

It must be some setting in my project that isn’t compatible, because I actually uninstalled the upgraded version, installed 4.2 from scratch, and I am still seeing it.

But I don’t know what to look for, and SO searching hasn’t yielded much

any ideas?

what version of Kotlin are you using?

That’s the thing - I’m not using Kotlin at all!

Pure Java project

do you get the same problem with a brand-new scrap project?

And a full build always works

just incremental fails

Haven’t tried that, one sec

It’s got to be some gradle setting somewhere I would guess, but darned if I can figure out what

OK it’s building

so, if the scrap project works, then I agree that it’s something in your project setup

OK that did not throw the error

have you tried doing a command-line build? sometimes those give me more info to work with

no - never have done that.

What do I need to do?

assuming that you have a typical Android Studio project, then from a command prompt/terminal, go to the project root directory and run ./gradlew app:assembleDebug, where app is the name of your app module

that will compile, but not install, the debug build of that module

if you have product flavors, you would need to mangle those into the Gradle task name as well (e.g., assembleVanillaDebug for a debug build of a vanilla product flavor)

I don’t

where is gradlew housed? I’m on a Windows box and it must not be in the path

ah, try gradlew.bat or gradlew.cmd

it should be a file in the root directory of the project

Duh. I was in the wrong spot

one sec

That is working - got passed the task that was throwing the error

let me make another change, and try it again.

past

build successful

what’s interesting is that Android Studio itself uses Gradle, so I am not certain what would be different about the command-line build that is causing it to work

I had it work once or twice from Android also, then it would flip back to giving that error

OK it failed this time from the command line

Task :app:compileDebugJavaWithJavac FAILED
Note: Version 10.5.0 of Realm is now available: https://static.realm.io/downloads/java/latest
Note: Processing module DefaultRealmModule
Note: Processing module DefaultRealmModuleMediator
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

FAILURE: Build failed with an exception.

  • What went wrong:
    Execution failed for task ':app:compileDebugJavaWithJavac’.

kotlin.KotlinNullPointerException

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

  • Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '–warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.7.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 4s
29 actionable tasks: 1 executed, 28 up-to-date

C:\BLD\AndroidStudioProjects\InTouch>

you could try adding --stacktrace, as it suggests, to get more information about specifically where it is failing

does that argument go before or after the app: argument?

ummm… I usually put it before, though it might work in either spot

Build successful.

So weird

Now I change one line and try it again and it fails:

did you get more info from the stack trace of where it is failing?

yes

I can’t send the full stack trace - your chat software says I’m being rate-limited or blocked :)

yeah, sorry, I don’t know the limits here

Caused by: java.lang.RuntimeException: kotlin.KotlinNullPointerException
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:163)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
at org.gradle.internal.compiler.java.IncrementalCompileTask.call(IncrementalCompileTask.java:74)
at org.gradle.api.internal.tasks.compile.AnnotationProcessingCompileTask.call(AnnotationProcessingCompileTask.java:94)
at org.gradle.api.internal.tasks.compile.ResourceCleaningCompilationTask.call(ResourceCleaningCompilationTask.java:57)

I saw one post from a year or so ago saying their problem that caused what looked like a similar issue was the annotation processor being used, and I notice that in this trace.

But I’ve got the most recent one in my gradle file

implementation 'androidx.annotation:annotation:1.2.0'

that’s not an annotation processor – that’s a source of annotations

Sorry, right

annotationProcessor 'androidx.annotation:annotation:1.2.0'

could you perhaps paste the whole stack trace into pastebin.com or something?

I don’t know what pastbin.com is

it’s a Web site for pasting arbitrary chunks of text, giving you a URL to use to hand that text to others

Caused by: kotlin.KotlinNullPointerException
        at io.realm.processor.ModuleMetaData.getClassListFromModule(ModuleMetaData.kt:337)
        at io.realm.processor.ModuleMetaData.validateNamingPolicies(ModuleMetaData.kt:170)
        at io.realm.processor.ModuleMetaData.preProcess(ModuleMetaData.kt:113)
        at io.realm.processor.RealmProcessor.preProcessModules(RealmProcessor.kt:241)
        at io.realm.processor.RealmProcessor.process(RealmProcessor.kt:178)

it’s coming from Realm

Running the exact same gradlew command a second time works

OK let me see if they have an update for 4.2

I have the latest

So I’ll post a note to them

yeah, they may have some suggestions, at least in terms of how to try to create a project that can reproduce the problem, so they can check it out

Same result now within AS as command line - if I run the incremental build a second time and make no code changes, it works.

well, it’s nice to be consistent… 😁

I have another question for you - I have a preference in my settings that is supposed to give the user the ability to open the details screen for my app in their Android settings on their device.

This was working for a while, and now all of a sudden it is crashing with an error that indicates no app can satisfy the intent.

So I changed the setup to no longer have the intent in the XML definition of the preferences, and instead handle it in the app like this:

            Preference systemPreference = findPreference(InTouch.getInstance().getString(R.string.pref_system_settings_key));
            if ( systemPreference != null ) {
                systemPreference.setOnPreferenceClickListener( preference -> {
                    Intent i = new Intent(ACTION_APPLICATION_DETAILS_SETTINGS);
                    try {
                        startActivity(i);
                        return true;
                    } catch (Exception e) {
                        // Try the generic application settings, and if that fails, show message
                        // and punt.
                        i = new Intent(ACTION_APPLICATION_SETTINGS);
                        try {
                            startActivity(i);
                            return true;
                        } catch (Exception exception) {
                            InTouchDialogUtils.showAlertDialog(getString(R.string.pref_system_settings_error_title),
                                    getString(R.string.pref_system_settings_error_message, getString(R.string.app_name_full)),
                                    requireActivity());
                            return false;
                        }
                    }
                });
            }

you seem to be missing the Uri

"Input: The Intent’s data URI specifies the application package name to be shown, with the "package" scheme. That is "package:com.my.app". "

I totally missed that when looking at the list of intents. Duh.

I am not sure I understand where this goes

so, adding something like:

i.setData(Uri.parse("package:" + BuildConfig.APPLICATION_ID));

should work

that would be after you create the Intent and before you call startActivity() using the Intent

Oh, of course.

Geez sometimes I wonder if I ever actually got out of bed…

well, it’s Saturday, so…

that’s a wrap for today’s chat!

the next one is at an unusual time: Monday at 7:30pm US Eastern

(as I am getting my "sequel injection" on Tuesday and may not be feeling great by 7:30pm that evening…)

have a pleasant day!

You too!

Tad left