"Safe mode" greyed out and always enabled

[Nelson A. de Oliveira]

With the latest nightly (OsmAnd-arm-default) I am seeing one problem:
"Safe mode" is greyed out and the app seems much slower than before.
It's like safe mode is always enabled but can't be changed its status.

Is anybody else seeing this?

[Rodolfo]

Confirmed, this option seems to be disabled and according to several posts, it causes (performance) problems, so I guess the change is OK, but in the greyed out option, you can still see its setting (checked or unchecked), so I'm wondering if this checkmark still reflects the real setting?

[Victor Shcherb]

When it is greyed out, there are no native library!!!

Please don't use OsmAnd-arm-default, use old-master & old builds.

We just fixed builds but not whole infrastructure :)

Victor

--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Hardy]

I have an old Adnroid 2.1 device, which shows a very similar behavior: Using the old-master build of Aug , 6, it starts ok and works ok, but shoiws the "Safe mode" setting greyed out.

 

Using the Aug. 7 build on that same deivice, the first and every other startup,resuls i n it never leaving the "installing native library" toast in the startup screen. Cancellation of that screen and subsequent re-start results in "native library not supported".

 

The build of Aug 3 (and early Aug 4) works flawlessly on that device.

 

[Victor Shcherb]

Are we talking about these files

http://download.osmand.net/night-builds/OsmAnd-old-master-nb-2013-08-07.apk

http://download.osmand.net/latest-night-build/OsmAnd-nightly.apk

http://download.osmand.net/latest-night-build/OsmAnd-r1.5-default.apk

 

--

[Hardy]

I have to correct my previous specifications:

- OsmAnd-old-master-nb-2013-08-07.apk produces the  'alternate'  "natiove library not-supported" toast

- OsmAnd-old-master-nb-2013-08-06.apk has the SAME behavior

- OsmAnd-old-master-nb-2013-08-03.apk still works!

- I also think that early-day versions of OsmAnd-old-master-nb-2013-08-04.apk still worked, but the (late-day) version still online now already fails

- The "greyed-out" behavior I had reported for 08-06 came from master, not old-master, hence should be disregarded.

 

Best, Hardy

[Victor Shcherb]

Tried this one http://download.osmand.net/latest-night-build/OsmAnd-nightly.apk, everything works ok. Didn't find anything suspicious (similar to OsmAnd-old-master-nb)

Victor 

--

[Max]

Hi Victor,

I can confirm this bug using #5048D on Android 2.3.6.
Native lib is not used and option is greyed out.

Regards,
Max

[Max]

logcat output:

D/net.osmand(12894): NativeOsmandLibrary Loading native gnustl_shared...
D/dalvikvm(12894): Trying to load lib /data/data/net.osmand.plus/lib/libgnustl_shared.so 0x4051e328
D/dalvikvm(12894): Added shared lib /data/data/net.osmand.plus/lib/libgnustl_shared.so 0x4051e328
D/dalvikvm(12894): No JNI_OnLoad found in /data/data/net.osmand.plus/lib/libgnustl_shared.so 0x4051e328, skipping init
D/net.osmand(12894): NativeOsmandLibrary Loading native cpufeatures_proxy...
E/net.osmand(12894): NativeOsmandLibrary Failed to load native library
E/net.osmand(12894): java.lang.UnsatisfiedLinkError: Couldn't load cpufeatures_proxy: findLibrary returned null
E/net.osmand(12894):    at java.lang.Runtime.loadLibrary(Runtime.java:429)
E/net.osmand(12894):    at java.lang.System.loadLibrary(System.java:554)
E/net.osmand(12894):    at net.osmand.plus.render.NativeOsmandLibrary.getLibrary(NativeOsmandLibrary.java:36)
E/net.osmand(12894):    at net.osmand.plus.OsmandApplication.startApplicationBackground(OsmandApplication.java:513)
E/net.osmand(12894):    at net.osmand.plus.OsmandApplication.access$300(OsmandApplication.java:68)
E/net.osmand(12894):    at net.osmand.plus.OsmandApplication$6.run(OsmandApplication.java:477)
E/net.osmand(12894):    at java.lang.Thread.run(Thread.java:1019)
I/net.osmand(12894): OsmandApplication Native library could not be loaded!

...

D/StrictMode(12894): StrictMode policy violation; ~duration=1584 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=23 violation=2
D/StrictMode(12894):    at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:745)
D/StrictMode(12894):    at dalvik.system.BlockGuard$WrappedFileSystem.open(BlockGuard.java:228)
D/StrictMode(12894):    at java.io.FileInputStream.<init>(FileInputStream.java:80)
D/StrictMode(12894):    at android.app.ContextImpl.getSharedPreferences(ContextImpl.java:411)
D/StrictMode(12894):    at android.content.ContextWrapper.getSharedPreferences(ContextWrapper.java:146)
D/StrictMode(12894):    at net.osmand.plus.api.SettingsAPIImpl.getPreferenceObject(SettingsAPIImpl.java:18)
D/StrictMode(12894):    at net.osmand.plus.OsmandSettings.<init>(OsmandSettings.java:106)
D/StrictMode(12894):    at net.osmand.plus.OsmandApplication.createOsmandSettingsInstance(OsmandApplication.java:184)
D/StrictMode(12894):    at net.osmand.plus.OsmandApplication.onCreate(OsmandApplication.java:125)
D/StrictMode(12894):    at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:972)
D/StrictMode(12894):    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3280)
D/StrictMode(12894):    at android.app.ActivityThread.access$2200(ActivityThread.java:117)
D/StrictMode(12894):    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:973)
D/StrictMode(12894):    at android.os.Handler.dispatchMessage(Handler.java:99)
D/StrictMode(12894):    at android.os.Looper.loop(Looper.java:130)
D/StrictMode(12894):    at android.app.ActivityThread.main(ActivityThread.java:3691)
D/StrictMode(12894):    at java.lang.reflect.Method.invokeNative(Native Method)
D/StrictMode(12894):    at java.lang.reflect.Method.invoke(Method.java:507)
D/StrictMode(12894):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
D/StrictMode(12894):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:670)
D/StrictMode(12894):    at dalvik.system.NativeStart.main(Native Method)

Regards,
Max

[Victor Shcherb]

This is really strange, because the package is there.

I also got some problems on 2.3.6, trying to investigate it.

Regards,

Victor

--

[Victor Shcherb]

Fixed,  by reverting to NDK 8

[Victor Shcherb]

Let's try to revert to NDK 9, but include cpu_features.so to neon library. Very weird...

Victor

[Harry van der Wolf]

I built it this morning with ndk9 and I do have the libs in place and OsmAnd works in native mode. My phone is on 4.0.4

For other "home" builders: You need gcc 4.7 or newer or your native libs will not build (I had 4.6 first on my Ubuntu 12.04.2 LTS server). They are compiled with the "-std=c++11" CPP flag (in android/OsmAnd/jni/Application.mk for repo builders, in Osmand/OsmAnd/jni/Application.mk for straight-out git builds).
That CPP flag is only available as of gcc 4.7

Harry

2013/8/10 Victor Shcherb <victor....@gmail.com>

[Nelson A. de Oliveira]

Should this be fixed with the last OsmAnd-arm-default versions?

[Max]

No, AFAIK.
OsmAnd-arm-default is new core, not old core.

Regards,
Max

[Harry van der Wolf]

I did indeed mention the 1.5 default build from the nightly builds when I said it was successful.
These latest-nights builds are confusing. I thought that now as we approach a release of the 1.5 build, that we were discussing the 1.5 build.
I see from Nelson's first and today’s post that he meant the arm build, so I should have read it better, but it's still confusing.

Harry

2013/8/12 Max <openstre...@nurfuerspam.de>

--

[Max]

All old core builds are working:
http://download.osmand.net/latest-night-build/OsmAnd-nightly.apk
http://download.osmand.net/latest-night-build/OsmAnd-default.apk (same as OsmAnd-r1.5-default.apk)

Regards,
Max

[Max]

@Harry

For other "home" builders: You need gcc 4.7 or newer or your native libs will not build (I had 4.6 first on my Ubuntu 12.04.2 LTS server). They are compiled with the "-std=c++11" CPP flag (in android/OsmAnd/jni/Application.mk for repo builders, in Osmand/OsmAnd/jni/Application.mk for straight-out git builds).
That CPP flag is only available as of gcc 4.7

This is really confusing me.
The native libs of the Android app should be build by the Android NDK cross compiler:
android-ndk-r9-x86_64/toolchains/x86-4.8/prebuilt/linux-x86_64/bin/
android-ndk-r9-x86_64/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/
android-ndk-r9-x86_64/toolchains/mipsel-linux-android-4.8/prebuilt/linux-x86_64/bin/

gcc and g++ of your Ubuntu installation should not be used at all.
To be really sure, I removed every gcc and g++ from my Ubuntu system (except Android NDK) and the native libs are building fine.

Regards,
Max

[Harry van der Wolf]

Thanks again for pointing me in the right direction.
As victor mentioned the back and forth switching between ndk-r9 and
ndk-r8 I had both installed. The r8 comes with an older gcc version.
The r9 comes with 4.6 and 4.8.
The 4.8 (or actually 4.7 or newer) is necessary for the -std=c++11 CPP-flag.
I assumed the system gcc was used, but it wasn't.
Anyway I think it means that reverting to ndk-r8 will not solve the
current problem.

Harry


2013/8/14 Max <openstre...@nurfuerspam.de>