Support for Android SDK v30

[marpstar]

Our app uses this plugin and we recently ran into issues trying to upgrade our Android Target SDK from 29 to 30. After further investigation, we found that this issue has been addressed in the cordova-sqlite-storage plugin, but those changes to not appear to have been merged into this one.

storesafe/cordova-sqlite-storage#954

Is this something on the road map, or is there a general timeline for when such fixes will be ported to the -ext version of the plugin?

[guv3n]

Hi
Is it something that will be fixed in a near future ?
It is already mandatory for new apps and will be mandatory for existing apps to target the API level 30 in November this year
By August 2021, new apps must target at least Android 11 (API level 30).
By November 2021, all apps that are being updated must target at least Android 11 (API level 30)

[ekrapfl]

@brodybits I am also wondering if this is something that you intend to fix in this version of the plugin. Very soon, this will start affecting people trying to submit new apps (if it has not already). Just curious if it is planned to be fixed in the near future.

Thanks!

[ndinhphi]

@marpstar I have the same problem as you

[Thiagors2015]

estou com o mesmo problema

[RomuloPBenedetti]

cannot submit my new app.

[ekrapfl]

@brodybits do you have any update for us on this issue? We are quickly approaching the November deadline when this is going to be a MAJOR issue for those of us with existing apps that use this plugin extensively.

[HarelM]

Has anyone created a branch of this plugin by any chance? I'll be happy to use it until this issue is fixed.
I'm facing the same issue on a oneplus device.
I don't mind creating a PR, but I guess copying the solution from the other repos can be easier for the maintainer...?
@brodybits any way I can help push this forward?

[HarelM]

I've created a fork here:
https://github.com/IsraelHikingMap/cordova-sqlite-ext
I tried some dirty hacking to get the two jars from the storage plugin where the issue should be solved, but it doesn't seem to work...
I don't have the device so I need to ask a friend to test it. Is there a simulator where this reproduces?
@luissilvaos if you have any recommendation it world be great.

[guv3n]

Hey guys, if you don't use the extra features of cordova-sqlite-ext, you might want to switch to cordova-sqlite-storage which works with Android SDK version 30.

That's what we did, it this can help...

[HarelM]

I wish I could. I need the ability to read a pre populated db... :-(

[HarelM]

Seems like the fork I did allows opening the database, it removed the BASE64 support which is not so cool as I needed that, but I'll handle without it...

[ekrapfl]

@HarelM, that is a no-go for us because it also removes JSON1 support. And Idk if it would be a good idea to mix and match the dependency files for the main fork with this fork's code. At that point, you may want to switch to the main fork, as @guv3n suggested.

[HarelM]

@ekrapfl I don't think the hack I did is a proper solution to this issue :-) it's just a hack to better understand what's wrong and maybe have a workaround until I fully understand everything that's going on here.
From what I gather, there are two project that are used as dependencies to the main two plugins (might be more, but I'm looking only on these two right now).
These projects have jar files committed into them.
I don't know how to generate those jar files yet, but I guess I'll need to learn in order to fully solve this.
Once the jar files are regenerated with the fix (in the c code) they can be committed to the deps npm package and then consumed in this plugin.
That's a lot to understand and do, and a lot of assumptions I made just now which might not be correct at all...
To be honest, I'm not sure I understand why there are different versions of the connector and adapter and even the plugin itself, why not incorporate all the functionality and reduce fragmentation, maintenance effort etc, but that's not the scope of this issue.

As I already said in a previous comment, I can't use the "main" fork as it lack the pre-populate database functionality (as far as I understand from the documentation, I haven't tried using it though).
Any help would be appreciated. :-)
My main concern is that I will invest all the effort in fully fixing this "properly" and it won't be merged and released to npm. Which can be a huge waste of my time as it seems I currently have a working (ugly) workaround to this issue...

[ekrapfl]

Yep, I am totally in the same boat @HarelM.
I am not entirely sure what all the differences are between the different forks (other than JSON1 support), and I have no clue how to build the .jar files for those dependency repos. I would like to help, but I am not entirely sure where to start. Ironically, I had also found that the dependencies for this repo are behind the current version in the deps repo, and I had made the exact same change as you hoping that it would work. :(

[HarelM]

Turns out that I can use the androidDatabaseProvider = "system" which also solved this issue, I'm not sure what support it lacks in terms of capabilities, but if it helps someone who will read it in the future that fine too. :-)

[jarrodkoch]

@HarelM did you do this by forking the repository? If so, where are you making changes?

[HarelM]

I created a fork and hacked some stuff, but the db provider configuration already exists in current version so I ended up not using my fork.
My fork is linked in my comments above in case you are interested.

[jarrodkoch]

So are you calling openDatabase exactly as in the readme?

[HarelM]

I'm using ionic wrapper as can be seen here:
https://github.com/IsraelHikingMap/Site/blob/f33bb6c4b1bf4b76af1e1d43cd234b8f6c23f86d/IsraelHiking.Web/src/application/services/database.service.ts#L231
But in general, yes:

var db = window.sqlitePlugin.openDatabase({
  name: 'my.db',
  location: 'default',
  androidDatabaseProvider: 'system'
});

[brodycj]

Should be solved now

[HarelM]

@brodybits Thanks for fixing this!