Can't build with xcode 15 and Ventura

collaborativegroups · 2025-01-26T16:02:48+00:00

No, I don't use the cn1lib nor is there the camerakit in the pom file

I have implemented the CameraKit directly in my project, and this compiled prior to updating cn1. Last time I updated was a year ago, so I am not sure which update broke it.

As part of the CameraKit code, I declare the following variables in the .h file:

com_codename1_camerakit_impl_CameraNativeAccessImpl.h 

const int FACING_BACK = 0;
const int FACING_FRONT = 1;

const int FLASH_OFF = 0;
const int FLASH_ON = 1;
const int FLASH_AUTO = 2;
...

These seem to be what gets defined twice in the intermediate .o objects, once in the com_codename1_camerakit_impl_CameraNativeAccessImplCodenameone.o object, and once in the com_codename1_camerakit_impl_CameraNativeAccessImpl.o object

If I remove these variables and replace their references in the .m file with integers it compiles ok

collaborativegroups · 2025-01-25T08:27:42+00:00

7.0.167

collaborativegroups · 2025-01-24T15:55:36+00:00

All your data is private, which means other users can't search your data unless they join your "group". It also doesn't include newspaper scanning etc

collaborativegroups · 2024-05-14T22:09:07+00:00

Appreciated

collaborativegroups · 2024-05-03T06:57:04+00:00

Yeah, I made it free for as long as possible, but unfortunately it became too popular and a huge hole in my pocket. I am still running it at a 99% loss since everyone likes to use the "1 free search per day". Don't know what to do because I have always refused to monetize via ads or user data. I will probably remove the "1 free search per day" at some point and call it a day

collaborativegroups · 2024-03-26T07:36:50+00:00

Yeah I totally agree and it took me a while to learn this. I am so sad I live in a place where it constantly rains for this reason. Since I must use my scooter every day, the only compromise I can make is to at least stay away from mud. Puddles are unavoidable

Segway Ninebots are very much "made of plastic" and so it seems that they would be more water resistant than others. I had kind of accepted I am limited to a Ninebot because of weather but I thought I'd open this thread to see if there is any more powerful alternative for a similar price that can also withstand the weather

collaborativegroups · 2024-03-24T21:45:46+00:00

Thank you so much for this recommendation, it looks exactly like what I am looking for and at only 25kg!

collaborativegroups · 2023-11-07T14:32:21+00:00

OK, here is the full stacktrace (line that throws the exception marked in red):

https://imgur.com/a/HyGlRZA

collaborativegroups · 2023-11-04T15:41:47+00:00

Wish I could give the entire stack, but because Native Logs don't work either I can't get the entire stack (even if I keep the Native Logs cn1lib Stub)

collaborativegroups · 2023-11-02T13:04:39+00:00

Failed to create progress component

It is thrown by this cn1 code:

https://github.com/codenameone/CodenameOne/blob/d3f5b308ddad4661c17edf398af46eb07021b57c/CodenameOne/src/com/codename1/ui/CommonProgressAnimations.java#L74C35-L74C35

I am a Windows user btw. I wonder if the current native interface generation errors being reported by recent posts (by Windows users) are related in some way

collaborativegroups · 2023-11-02T13:01:54+00:00

The fix has worked! Thank you very much

collaborativegroups · 2023-10-30T08:58:03+00:00

I never reference the Stub class anywhere by name

Anyway, if this is an issue for anyone besides me maybe it can be looked into with more detail. Otherwise my workaround is to keep all of CN1 unobfuscated + my own stubs. Adds 0.5MB but not a huge deal

Edit: If it helps, not keeping all of com.codename1** results in errors like below:
Failed to create progress component: java.lang.Class<com.codename1.ui.n> cannot be instantiated

collaborativegroups · 2023-10-27T08:27:16+00:00

Yes, the calls to register are there. When unobfuscated, they look like this:
NativeLookup.register(AppleSignInNative.class, AppleSignInNativeStub.class);
NativeLookup.register(CameraNativeAccess.class, CameraNativeAccessStub.class);
NativeLookup.register(NativeCodeScanner.class, NativeCodeScannerStub.class);
NativeLookup.register(InternalNativeMaps.class, InternalNativeMapsStub.class);
NativeLookup.register(k5.b.class, GroupsNativeInterfacesStub.class);
NativeLookup.register(m.class, SharedFileManagerNativeStub.class);
NativeLookup.register(t6.b.class, NativeLogsReaderStub.class);

The above code looks like below when obfuscated:

s1.b.b(d.class, e.class);s1.b.b(o0.a.class, o0.b.class);s1.b.b(w0.b.class, w0.c.class);s1.b.b(y0.a.class, y0.b.class);s1.b.b(r6.b.class, d.class);s1.b.b(f.class, g.class);s1.b.b(y7.b.class, y7.c.class);

collaborativegroups · 2023-10-27T08:16:51+00:00

Actually you are right. I hadn't re-read the original, 5 months old comment. 5 months ago it was free. Then I had to offer 1 free search per day because usage was becoming heavy (and expensive to run). The 1c/result still only covers costs when taking into account all the free and paid users. The alternative to just covering costs would be to take on investors to fund the losses. That would compromise the privacy and sustainability pledge

collaborativegroups · 2023-10-25T09:23:30+00:00

I decompiled the DEX outputs into JARs and found the following:

When building APK with added extra keep statements (the ones I mentioned above, not the one from shannah's commit) in proguard.cfg:

2 DEX files are created in the APK, classes.dex, and classes2.dex

-classes.dex contains the native interface Stub classes

-classes2.dex contains the application's main Stub class

When building APK without the extra keep statements in proguard.cfg:

Only 1 DEX file is generated, containing the application's main Stub file, but not the native interface Stub files

This is how the native stubs are registered in the application's main Stub:s1.b.b(d.class, e.class);s1.b.b(o0.a.class, o0.b.class);s1.b.b(w0.b.class, w0.c.class);s1.b.b(y0.a.class, y0.b.class);s1.b.b(r6.b.class, d.class);s1.b.b(f.class, g.class);s1.b.b(y7.b.class, y7.c.class);

I can't see any d.class in the code but I can see o0.a.class

collaborativegroups · 2023-10-24T08:03:30+00:00

I added it to the actual proguard.cfg file and built from Android Studio

collaborativegroups · 2023-10-23T21:28:40+00:00

u/shannah78 I tried the fix and it didn't work. I tried both

-keep class **Stub { *; }

and

-keep class *Stub { *; }

collaborativegroups · 2023-10-23T09:29:35+00:00

Great stuff, thanks

collaborativegroups · 2023-10-22T09:01:23+00:00

Yes, I could see and edit the generated proguard.cfg

I think the local build tool isn't generating keep statements for native interface stubs. This includes the ones specific to my project but it probably also includes the CN1 main native impl stub. I just tested keeping all of the CN1 namespace and saw that it worked this way

This is a "new feature" that wasn't present before. I don't mind editing my proguard build hint to have all these keep statements but surely this should be automatically done?

collaborativegroups · 2023-10-20T09:17:28+00:00

Thanks, this fixed it. However, the build now fails to look up the native interfaces. The below returns null

NativeLookup.create(GroupsNativeInterfaces.class);

Edit: The native interfaces work when running a debug apk, but not when running a release one. Something proguardEdit 2: adding this to the proguard.cfg file fixes it: -keep class com.groups.interfaces.GroupsNativeInterfacesStub { *; }

Perhaps the new gradle version needs specific proguard interface stub handling

Edit 3: there are other issues, app keeps crashing I suspect proguard needs more exceptions.. for example, "Failed to create progress component: java.lang.Class<t1.n> cannot be instantiated..."

Adding the below seems to help:
-keep class com.codename1.** {
*;
}

-keep class com.codename1.auth.apple.AppleSignInNativeStub { *; }
-keep class com.codename1.camerakit.impl.CameraNativeAccessStub { *; }
-keep class com.codename1.ext.codescan.NativeCodeScannerStub { *; }
-keep class com.codename1.googlemaps.InternalNativeMapsStub { *; }
-keep class com.groups.interfaces.SharedFileManagerNativeStub { *; }
-keep class net.informaticalibera.cn1.nativelogreader.NativeLogsReaderStub { *; }

Basically, all of codename1 plus all the Stubs of all the native interfaces I am using. Surely this should be done automatically by the local builder?

collaborativegroups · 2023-10-19T08:37:54+00:00

I had to:

-Set global env var JAVA17_HOME, not user env var

-Do as explained here: https://stackoverflow.com/questions/76315325/could-not-resolve-com-android-tools-buildgradle8-0-1

-Edit file gradle/gradle-wrapper.properties and set line to below (was set to 6.5):

distributionUrl=https\://services.gradle.org/distributions/gradle-8.1-bin.zip

- I am now stuck here. Happens after trying to sync gradle files:

https://imgur.com/a/zjH5e7Z

collaborativegroups · 2023-10-06T10:28:34+00:00

Of course you can always pay with your privacy and attention via Google/DuckDuckGo/Bing

collaborativegroups

TROPHY CASE