CODEWITHSUNDEEP
javaandroidandroid-studioaar
topher217
topher217

Reputation: 1377

Unexpected results from implementing an AAR library compared to source library in Android Projects

Summary

Current Behavior

Unexpected results from implementing an AAR library compared to source library in Android Projects.

Both issues only exist when using a compiled AAR of library, i.e. problem does not exist when implementing same project using library source code.

Expected Behavior

Working App

I have an Android Application based in package com.example.sourceapp

This uses and manages the source code for a separate library located in com.example.sourcelibrary, in which is a class we'll call ParentClass.

In ParentClass I have two members of interest.

In my com.example.sourceapp.MainActivity I do two things.

Not Working App

In a different Android Project com.example.compiledapp.MainActivity instead of depending on the source library com.example.sourcelibrary, I depend on a compiled (debug) AAR file made from the same library.

I import the needed class from the AAR package at the top of com.example.compiledapp.MainActivity with import com.example.sourcelibrary.ParentClass without any resolution issue.

Later in com.example.compiledapp.MainActivity I use the same code as before to 

super.myBool = true;
super.onCreate()

but Android Studio indicates that it cannot resolve myBool in super.myBool = true;.

Furthermore, the 2nd line seems to resolve just fine, but upon closer inspection when I hover over it, Android Studio indicates that onCreate resolves to being a member of the grandparent class com.example.someotherlibrary.GrandparentClass instead of the parent class com.example.sourcelibrary.ParentClass.

Looking a few lines up, as I hover over the onCreate override, Android Studio indicates that I am overriding the onCreate from the grandparent class, not the parent class.

Why/How would onCreate skip the parent method and override the grandparent class?

Also it looks like the super keyword is resolving to the grandparent class rather than to the parent class. That is the only explanation I can think of that would result in onCreate resolving to the GrandparentClass and myBool not being resolvable. I didn't think this was how super worked.

Is this normal and I simply am misunderstanding something fundamental about inheritance? Maybe I am doing something wrong when compiling to AAR such that the parent variables/methods become inaccessible despite being declared public? Or maybe Android Studio gives preference to one package over another based on some rules I am unaware of?

Working Code

package com.example.sourceapp;

import android.os.Bundle;

import com.example.sourcelibrary.ParentClass;

public class MainActivity extends ParentClass {

    // Shows to Override onCreate in ParentClass
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState); // super resolves to ParentClass
        super.myBool = true; // super resolves to ParentClass
    }

}

Not Working Code

package com.example.compiledapp;

import android.os.Bundle;

import com.example.sourcelibrary.ParentClass;

public class MainActivity extends ParentClass {

    // Shows to Override onCreate in GrandparentClass
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState); // super resolves to Grandparent
        super.myBool = true; // does not resolve
    }

}

Upvotes: 1

Views: 193

Answers (1)

topher217
topher217

Reputation: 1377

I ended up tracking down the error. It turns out when building my com.example.sourceapp, which included the library module com.example.sourcelibrary, the build process was not updating the AAR file, and there was apparently something wrong/old in the outdated sourcelibrary code (maybe it was missing the onCreate method and myBool. Not sure really as I don't recall where in my git history it would have been since I only briefly noted the modified date was old, then rebuilt and the old timestamp is now gone.

Regardless, what helped was going to the gradle menu in Android Studio for the com.example.sourceapp and navigating to the sourcelibrary-->Tasks-->build-->build. Attempting to build the library directly threw an error related to SDK versions, so I fixed this and rebuilt, reimported to the compiledapp and it worked as expected.

The thing others may learn from this, is that if something strange is occurring with your AAR dependency, check that the source code you are building the AAR from is actually building and updating the AAR file, as Android Studio apparently doesn't throw an error when building the app that surrounds the library.

Maybe the SDK settings in the app level gradle overrode the library level gradle settings and allowed it to build the app without errors, and the updated library was actually built, but only within the APK? Not sure, exactly why, but at least an overall lesson was learned.

Upvotes: 1

Related Questions