Test of Android GLES Alpha Version
  • 246 Comments sorted by
  • @mdx and @lubos: I mentioned the issue with the speed limit setting set incorrectly on the motorway in England. That started with this post in this thread and subsequently a few others, also by @jd417
    Could this incorrect speed setting on the display have anything to do with this "urban speed trigger" instead of (gles) rendering? So that in my mentioned case MNF did not detect that I have left the city (urban speed)?
  • MFN now starts on my ASUS K004 with hardware rendering as exspected and I am now "on the road" (see above post, where I was in the wild). But a simulation crashes after one to two kilometers on a trip of 481 km whereas I stopped simulation of the same trip on software mode after about 20km because it ran without any problems until then.

    On my Xperia Active street names are too small to read on hardware rendering.
  • @Oldie Please adjust the font setting under settings -> Map -> first entry
  • Today I used the GLES version again in hardware mode on a 157 km trip. It didn't crash, but it "stuttered" 3 times.
    Normally when driving you see the map progress with little steps. Today 3 times it "stuttered". It progresses, jumps back, progresses again, jumps back and that 10-15 times after each other (best guess. I had to pay attention to the road with dense traffic). After this 10-15 forward-backward hitches it suddenly jumps 100-200 meters (or so) further and continues where my gps position is at that time. As mentioned: it did that 3 times within 10 minutes on a trip of about 1 hr 40 min. I never had that in software mode.

    Edit: I remember that I had this in earliers versions as well.
  • @hvdwolf

    I've also experienced this. The navigation cursor changes to 4 grey arrows from the usual single red arrow (I think to indicate loss of GPS) & the map "freezes". After 5 - 10 seconds the red arrow re-appears & the map jumps to the current position. I believe this was mentioned earlier in this post.

    As for the earlier crashes I reported I installed GLES 2.0.13+ from google apps testing onto a Sony Xperia Z3 compact & to date no crashes in hardware render. I've yet to try this version on the Moto G but I'll report when I get a chance.
  • @jdk417: The "loss of GPS" is a different bug (and one I have never seen b.t.w.). In my case of "stuttering" the GPS signal is not lost at all.
  • @chattiewoman Thanks. Fonts are bigger now.

    Although street names are flashing on hardware rendering, while there are shown constantly on software rendering on my Xperia Active.

    Interestingly hardware rendering seem to be much more stable on my old Xperia Active rather than on my (in comparison to the Xperia Active) more modern Asus tablet K004.
  • One question for @mdx
    Why android project was removed from crowdin? I think that if project is more available, than translations will have more time for fixes.
  • there was no activity
  • @tomas I invested many hours for the German translation until it was finished, and you seriously call it "no activity" ...? Thanks.
  • first thanks Natalie
    we did look at crowdin and there was some activity at the beginning, but after that it died off
    we are examining other possibilities
  • @tomas
    There is no activity because probably no one knows about it. I found information about translations by chance in this topic. Shame that currently I cannot correct some text after first android alpha release.
  • please understand that crowdin is not free
    we looked at activity and, considering price, it was decided that it was not worth the price
    we are looking at alternatives
    please note that we all appreciate your help
  • @tomas
    I thought that crowdin is for free. Thanks for clarification.

  • @lubos - A quick update re "... it should hopefully fix problem with several waypoints and route recalucation " .

    Tested today GLES 2.0.16 (OSM maps) and V1.6.20 (OSM maps) using same route that have shown a consistent failure. 

    GLES completed route with no failure ... :)>-
    V1.6.20 surprisingly passed my "dodgy" waypoint but failed on a different waypoint.

    but before deleting my trusted v1.4.24 I will perform more tests with both devices ( using V1.6.20 device as my confirmation device :-)   )

    Very promising result - many thanks and really appreciate the work you put into this - you are good!!!. 
  • "Navigator v2.0.16-DEVELOP.apk"

    Following exception caused application crash:

    08-21 09:03:12.561 E/AndroidRuntime(20420): FATAL EXCEPTION: main
    08-21 09:03:12.561 E/AndroidRuntime(20420): java.lang.NoSuchMethodError: android.widget.ImageView.setX
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at com.mapfactor.navigator.map.MapFragment$1.onSingleTapConfirmed(MapFragment.java:214)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at android.view.GestureDetector$GestureHandler.handleMessage(GestureDetector.java:271)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at android.os.Handler.dispatchMessage(Handler.java:99)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at android.os.Looper.loop(Looper.java:130)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at android.app.ActivityThread.main(ActivityThread.java:3806)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at java.lang.reflect.Method.invokeNative(Native Method)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at java.lang.reflect.Method.invoke(Method.java:507)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
    08-21 09:03:12.561 E/AndroidRuntime(20420):     at dalvik.system.NativeStart.main(Native Method)
    08-21 09:03:12.595 W/ActivityManager( 8694):   Force finishing activity com.mapfactor.navigator/.map.MapActivity


    also I see some error message in log (not related to crash)

    08-21 09:20:33.640 I/dalvikvm( 2304): Failed resolving Lcom/mapfactor/navigator/NavigatorApplication$MpfcActivityLifecycleCallbacks; interface 22 'Landroid/app/Application$ActivityLifecycleCallbacks;'
    08-21 09:20:33.640 W/dalvikvm( 2304): Link of class 'Lcom/mapfactor/navigator/NavigatorApplication$MpfcActivityLifecycleCallbacks;' failed
    08-21 09:20:33.640 E/dalvikvm( 2304): Could not find class 'com.mapfactor.navigator.NavigatorApplication$MpfcActivityLifecycleCallbacks', referenced from method com.mapfactor.navigator.NavigatorApplication.onCreate

  • On my Motorola Defy+ (Android 2.3.6) hardware renderer is veeeeeeery slow.
  • Some points of my productiv testing of hardware renderer on my Xperia Active (ICS).

    A couple of days ago I had sound output at the speeker of the device as well as on the car audio connected via bluetooth, while the car audio was approx. one second behind the speaker ...

    Reaction to tapping the screen or hardware (volume) buttons takes often many seconds (this may be due to the old hardware of the phone).

    Hardware renderings look is nice (beginning with the more modern position arrow), I like it much more than the software rendering. On the other hand look should not do it over functionality.

    Crossing streets are shown the same way as the street is shown on which I am driving. If the street name is set to a crossing, I do not know, if the name shows to the crossing street or the street I am on. May be MFN could indicate crossing streets within arrows as <streetname> and not |streetname|.
  • Crash during map downloading on BlueStacks App Player.
    logcat: https://yadi.sk/d/PJmYggaCidQVD

  • Two more observations for 2.0.19 and most probably earlier versions:
    When playing with icon zoom levels and then zooming in/out on the map, the app crashes frequently.

    The Info button not always picks up the POI info from imported POIs.
  • hvdwolf: You can install logcat application and save log to file after Navigator crashed. Log may contain callstack of the crash.
  • Hi Dmytrio and hvdwolf,
    thanks for reports - the easy one should be fixed. It is hard to say if "playing with icon zoom levels" is related to memory, imports, or some other bug :(. In meantime there is version 2.0.21:
    - fixed show route on map from itinerary
    - fixed toolbar timing for click on map
    - other bugfixes
    thanks
       Martin
  • @Dmytro_Ovdiienko: I know the logcat application and in fact it is not even necessary as you can do the same with ADB.

    @mdx: Coming to those logs. MNF also logs to disk and you can even set the loglevel. Are these logs (partial) excerpts from the android log or copies? 
    And further: do you indeed need android logs via logcat or are the MNF logs sufficient? Or if the need arises you will ask for separate logcat logs?
  • logcat has stacktrace of C++ crashes(this is missing in navigator logs because it needs extra permissions). Logcat has same level as debug level in navigator settings. I personaly prefer reading our logs on high level(there are missing important things on medium level)
  • @hvdwolf

    Yeah... adb logcat is easier to use, but logcat application is easier to explain :)
  • Could you please add opening hours to POI
  • Up to now I‘ve tested the GLES-version with a Nexus 7, today I tried it the first time with a Moto G (4,5"). After a short while I switched to software rendering mode because I could hardly see the highlighted route. The route is too small / too narrow for me or too far zoomed out, especially in areas with buildings ot lots of roads. Configurable zoomfactors as suggested by hvdwolf could be a good way to handle different tastes.

    The speed limit symbol even on the smalI 4,5“ display is in a perfect size now, but I am having difficulties reading the displayed informations like distance to next event, speed info etc, no matter which rendering method (no problem on Nexus 7).

  • I had a terrible navigation last weekend with hardware rendering on my Xperia Active (with ICS). I just wanted to travel to a village near Zschopau, which is about 17 km from Chemnitz. The map zoomed out and out and out, so there was Chomutov at one point indicated on the map, which is approx. 60 km away beeline and at a second point, there was Usti nad Labem indicated, which is approx. 80 km beeline. The full route was compressed to a couple of millimeters length on normal navigation view (not tapping show the full route on the display). Every tap on the screen took approx. 30 seconds to be answered from the phone.

    A day or two later I navigated with the next GLES version (I think that was 2.x.20) and problems seemed to be gone.
  • Navigator 2.00.21 on my Asus K004 still crashes after less than one km simulation with hardware rendering. Simulation seems okay on software rendering on the same device though (I did not check to the finish, just stopped simulation after a couple of minutes).
  • @lubos , @tomas 

    Just to say thank you to lubos for resolving an old going issue. 

    Thank you for your hard work - greatly appreciated! 

    This is with ref to "... it should hopefully fix problem with several waypoints and route recalucation " .

    I have tested it extensively and GLES kept going on every v1.6.20 crash.
  • Thanks!
    Does it mean we are not talking about alpha testing anymore? Do you we need another topic? :)
  • yes, feel free to start some new topic like "Test of Android version 2.0.x"
    thanks
  • p.s. version 2.0.22:
    - better ferry routing
    - stability improvements

  • p.p.s.s. 2.0.24
    Fixes:
    - Several bugs
    - multilanguage search
    - stop navigation when destination is deleted
    - click on map
  • this was edited just 18 days ago, please wait for October maps
  • Node: 3658512164
    Lift gate on the service road.
    Edited 2 months ago by Sparrowbe
  • Cannot find "Staniątki, 735, Poland".
    Nominatim returns http://www.openstreetmap.org/way/241012414
  • Aaaah... I had to press "Town house numbers"...
  • There is one not obvious case in Lanes Assistant. Following is example of route:

    http://www.openstreetmap.org/directions?engine=osrm_car&amp;route=50.04401,19.97047;50.04620,19.97212#map=17/50.04512/19.97205

    Road before turn has turn:lanes="left|left;through|through|right" and if you want to turn left Navigator suggests "left;through" and "trough" lanes however correct lanes are "left" and "left;through". The reason of issue is road on which you cannot drive, because it is opposite lane. That is should be considered by Navigator.
  • This is a very long running bug by now. MNF does indeed not consider "separate roads". In all of these cases MNF wants you to go straight on and then (almost immediately) go left.
    I assume in left-driving countries it is the opposite way. I can't remember I noticed that last holiday.
    A couple of other nav-apps do this correct. 
  • Fix should be easy. When Lane Assistance determines lanes, it should discard lanes which are forbidden by Turn restrictions or have opposite direction.

    Also road with "turn:lanes" tag can be split into several parts (like in the case I provided).
  • I agree with you that "it should be easy" :) , but I'm not a programmer. What seems easy for the non-programmer, might not be so easy for the programmer. 
    Is there a relation between the split roads? 
    How far are they apart? does 30 meter means that it is a totally different road, like you have in cities?

    The fact that some other nav apps do it correctly, means that is is solvable.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Tagged