yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] jhony benitez:
Very happy with fcc launcher, congratulations

[MENTION=4292729]SpeedFire-[/MENTION]

As a suggestion, and although the launcher is already the most complete, it would be great if FCC could calculate range, and same odb2 widget could change showing odb2 information in the same way weather widget works by clicking on it.

It is just an idea and not a petition, just a suggestion to be considered.

Thanks [emoji6]

Enviado desde mi SM-G975F mediante Tapatalk
[Android Head-Units] Scopesys:
Will do -- any specific size ?
[Android Head-Units] SpeedFire-:
Nothing specific. But the image size in KB should be small enough because of widget update restrictions - I would say less than 100 KB.
[Android Head-Units] surfer63:
Do you mean phone calls made directly via a 4G module with sim card?

Or also for calls via a BT connected phone?

And do you have them for the newer SC9853i Intel Airmont systems? And more specifically: the FYT based systems from Joying, Zhan, some Witsons, etc.
[Android Head-Units] SpeedFire-:
FCC Beta 3.346:

- [New] Compass widget added (early beta)

- [New] Night style added to MapBox (inspired by night mode in Apple maps)

- Trip Combined widget fixed (wrong data for 5th indicator)

- Map themes are now remembered when minimap provider is changed.
[Android Head-Units] reganEZ:
Hello SpeedFire,

I tried the skin, maybe i am not doing it right but it doesnt fit the FCC launcher well. looks untidy. Let me uninstall AGAMA install FCC and see where it takes me.

i really like the center widget implementation of AGAMA. It changes as the situation and it looks good imo. However your implementation of screen swapping is great as well.

The major difference between your app and agama is that agama is just plug and play. install it, choose a skin and you are done. your app is extremely customizable(and I love the autoplay music feature with any app, agama doesnt support my HU default music player). Maybe, if i could as for one thing, it would be an easy mode( like on some samsung phones, where I install it and i am good to go)

I have a free day today so I will fiddle around with it and see where it takes me. Kudos to you for taking time to respond to queries such as these. You truly care as a developer. That alone makes your app superior to others. Thank you for that.
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Thanks for starting on the Compass Widget I installed beta 3.346 and placed the widget on a blank page, but it did not show anything except it's background.

My original suggestion was to add the Compass feature to the Speedometer widget as an Option, rather than try to create another widget that would take up significant Page space.

The space around the circumference of the Speed Widget would be the ideal place to put the compass,

Then one gets both Speed and direction in the same widget / same space, without need extra page space.

By setting the colors of the speed part, and the compass part, the widget can be configured to display all combinations

ie

Just Speed

Just Compass

Both Speed & Compass

See Photoshopped image below.

If this is not going to be the direction you are going in (excuse Pun), what are you ideas on how a Compass widget should look ?

If I can help with any artwork, I would be more than willing to try creating something.
[Android Head-Units] SpeedFire-:
You need to start moving - then the compass widget will rotate.

Your idea with static compass and moving arrow is also very nice - I will add it as a second option.

I know about your idea to make a one speedometer/compass widget. That's why this compass widget is based on a speedometer widget. I will add an option to add speed data to the center of it later. No problem here.

Now we need to test how rotation works and to create a nice graphics for the widget.
[Android Head-Units] Scopesys:
No tried moving yet .. so when stationary, the current widget just displays a Background ? That's good, better than displaying incorrect GPS jitter.

The static compass might consist of a number of overlays. ?

(1) The Outer Circle, with breaks in it for the compass letters, ie N, E S W

(2) The Compass Letters. Are N, E, S, W international, or do different countries have different letters for different languages ?

If they vary with country, then maybe they might be user configurable ?

(3) Then a Pointer ... either as a center rotating image overlay , or drawn dynamically .
[Android Head-Units] SpeedFire-:
Yes. several layers can be used.
[Android Head-Units] rigattoni:
I just used it stationary with mocked GPS location.

The compass does not do anything. Even if I use a route to south it doesn´t do anything.

As you can see in the movie, the speed widget works and I switch between TomTom and main screen.

https://www.dropbox.com/s/e6nc83d8rtysswb/20191226_114737.mp4?dl=0
[Android Head-Units] ab1702:
[MENTION=4292729]SpeedFire-[/MENTION] this autostart last player used feature still isn’t working which you and [MENTION=7838245]realzoulou[/MENTION] tried to fix with the dab-z app.

I think I noticed something earlier though, when the unit comes out of sleep(which is how i have it set up), this is when it doesn’t restart the last player used. When I was listening to dab-z and I once restarted the unit then it did restart my last player used (which was dab-z). So like I say it looks like it doesn’t restart the last player used (which for me is dab-z or Apple Music) when the unit comes out of sleep.

I have updated to the latest dab-z version also.
[Android Head-Units] surfer63:
I think you exactly mention why it is not functioning. After boot is completed the event BOOT_COMPLETED is sent by the Android system. This starts FFC and FFC on its turn starts the configured apps. FCC is of course also started as it is the default launcher (I assume).

When your unit comes out of deep sleep, it is not booting, does not send this BOOT_COMPLETED and therefore FCC can't react on that.

Even more: the fact that your apps are killed when going into deep sleep also means that FCC is killed. However, due to the fact that it is the default launcher it is started anyway.

The only thing to overcome this, especially on Android 7.x and newer, "might" be to check for USB connect (android.hardware.usb.action.USB_DEVICE_ATTACHED). All those units coming out of deep sleep connect their usb devices again. That event can also be used to start apps by FCC.

Only disadvantage of this is when a user connects another USB-device when the unit is in function. FCC should use some testing to see whether it just came out of deep sleep or not.
[Android Head-Units] Scopesys:
Strange -- this time the Compass displayed .. maybe it needed a re-start.

In any case, even when I drove, I confirm it still kept pointing North.

https://drive.google.com/file/d/1GoCzOxN_FpUXzRmZSWGTev0Xtmu5q1rU/view?usp=sharing

Comparing this with the TORQUE Compass

https://drive.google.com/file/d/1HBwcPCd1Ynzn-tHRi24JaHZSHYwmdL49/view?usp=sharing

I know it a very subjective & personal choice, but I find the Simpler, less complex, Torque one to be much easier to glace at an get the direction.

The import things (to me are the N, S E W and the Pointer - especially the pointer. All the fancy lattiice work in the beta FCC one, just adds to a cluttered image, and make sit even more difficult to see the POINTER... In fact. even with the image as big as it is in my Screenshot, it is very difficult to actually see the red pointer, without some considerable starting at the display.

But at this time in the beta, it's must be more important to get the image to rotate and display the correct direction, before worrying about graphic details.
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Here are some PNG images that may be of use while developing the Compass widget.

A background png , and a Pointer png which should rotate on top of the background

Also, a Composite of what the final widget might look like, using the above png

Note: They were made in layers in "Paint Shop Pro", so any layer can be individually edited.

"Compass_Full.zip" contains the originating Photoshop PSP file
[Android Head-Units] SpeedFire-:
Here is the updated version:

FCC 3.346b
[Android Head-Units] Scopesys:
Looks Great ... Installed it .. Good match to the Speed Limit Widget.

I assume in 3.346b, the movement is not yet running .. ( It did not move from N when I drove around the block)
[Android Head-Units] SpeedFire-:
Hm.. It should work. The animation in my previous post is from emulator.
[Android Head-Units] rigattoni:
Hmmm... No it doesn´t work at least on my unit.

Another issue found in this version, that the compass is not constant, please see video:

https://www.dropbox.com/s/79e4k3ymdixtu8f/20191226_230623.mp4?dl=0
[Android Head-Units] SpeedFire-:
Yes, there was a bug.

Now it should work: FCC 3.346c
[Android Head-Units] SpeedFire-:
Speedometer is added:

Download: FCC Launcher 3.346d
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Looks FANTASTIC - updated from 3.346b to 3.346d, and the pointer moved .. A little twitchy when the car was still, but that is ok.

UNFORTUNATELY - looks like a bug has been introduced ... :(

Went to try to edit the Compass widget, and FCC always crashes when trying to enter the actual edit screen of the widget.

Reset, restarted -- still cannot edit.

DELETED widget .. Restarted -- rebooted .

Now, when I go to add the Compass widget, FCC crashes as soon as the Widget is placed (ie when it is going to go into it's initial Edit mode)

Other Widgets, like Speedometer widget still load and edit fine ... just the COMPASS one seems to have this issue

see Video of this happening :- ( have to see it to believe it --- very strange)

Note: Older version 3.346b, had no issues going into Compass Widget edit mode, although the various color selections etc, did not work in that version.

https://drive.google.com/file/d/1HigWjBZzPfikNHUoe8XbYZeKFr9uJNn3/view?usp=sharing
[Android Head-Units] SpeedFire-:
Crash is fixed: FCC Launcher 3.346e
[Android Head-Units] rigattoni:
Gave it a try this morning with mocked route and yes, the compass is stable and working now. :good::highfive:
[Android Head-Units] Th0m4s88:
In version 3.345 DAB Z is still not always starting when the headunit is done booting up and it was the last program running before. Media players like black player or Poweramp are always starting correctly but DAB Z only starts like 50% of the time.
[Android Head-Units] rigattoni:
Be more precise... What so you mean with "booting"?

Cold boot, or wake up from deep sleep?
[Android Head-Units] ab1702:
It’s both but mainly deep sleep. I reported it and described it further up the thread.
[Android Head-Units] Th0m4s88:
Sry I meant cold boot. Wake up from sleep never worked for me. It's really strange. Sometimes the dab app starts like it should and sometimes it doesn't.
[Android Head-Units] SpeedFire-:
Dark style is added:

FCC Launcher 3.346f
[Android Head-Units] rigattoni:
Nice so far.

Just one issue found:

If you adapt both icon styles, only the first text color is stored.

Video:

https://www.dropbox.com/s/0pac4dl1j1sm0fp/20191227_133607.mp4?dl=0
[Android Head-Units] SpeedFire-:
Colors are not stored. I just set them to some predefined values (separate for dark and bright styles).

I assume that user will select some style and adjust its colors and will not switch often between styles.
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Thank you so much for adding the Compass .. very much apprecated, and will greatly add to my driving experience (and having a better idea where I am and in what direction I am going, without having to bring up a GPS map)

It is now working very well, went for a drive this morning, and it was GREAT !!!

However, before you consider this widget completed :-

Please would you consider eliminating the fixed styles for the colors of the Compass part, and instead, make them user adjustable, like the other items in this widget (ie the Speed)

My reason for asking is this :-

On many of the China head units, the screen Contrast is not that great, and often in daytime sunlight, the screens need to be set to maximum brightness, to be seen at all.

When turned Up this much, there are NO TRUE Blacks, Blacks become a dark grey, ( and grey become a very light grey)

Therefore, to be able to see and read the screen well, users will chose High contrasting FULL colors.

With the current style (Preset Colours) that are not High Contrast, the artwork becomes washed out and difficult to read.

Ideally, the Outer N,S.E.W and scale should be one user adjustable, and the Pointer another user adjustable color.

There also seems to be a preset OFF White center filled circle-- that color should also be user adjustable, or just be the same as the widgets background color.

Below is Graphically what I see.

(1) How it really is on a Perfect High Contrast screen

(2) What it looks like on a low contrast screen

(3) What it might look like with custom colors on a Perfect High Contrast Screen

(4) What it might look like with custom colors on a Low Contrast Screen

I would obviously like to achieve look of 4, instead of 2
[Android Head-Units] Jenson_P:
I have the same issue, FM Radio is not playing automatically with 3.345 after the vehicle was turned on.

Went back to 3.320 now, where it works fine.
[Android Head-Units] Tbizzness:
Happy Christmas all.

My small gripe is that since having FCC installed I've been having GPS problems. Not just on my unit but the unit in my wife's car too.
[Android Head-Units] ab1702:
[MENTION=4292729]SpeedFire-[/MENTION] I thought I’d document a few things that I’ve found today using the latest playstore version, all related to the player widget and/or the autostart problem.

1. I use dab-z and Apple Music. Both of these players don’t start again if they were the last player used when the unit comes out of sleep. They sometimes start again if starting the unit from a cold boot, but not always. This is a backwards step as in older versions when starting from sleep or a cold boot Apple Music always started again if it was the last player used but dab-z never did and now both of them don’t start again.

2. While listening to dab-z earlier, the player widget just randomly changed to and started playing Apple Music without me pressing anything. This has happened in older versions of fcc also.

3. On my steering wheel I have the MODE button (through fcc settings) set to change between upto 3 apps in the background and I have these as dab-z and Apple Music. If Dab-z hasn’t been started if I press the mode button to switch to dab-z then it will start dab-z and keep it open, it doesn’t put it in the background. However if I have already opened dab-z and then switch to Apple Music and then later I switch back to dab-z it will then start dab-z and put it in the background. Again this problem wasn’t seen in older versions of fcc.

4. (Not sure if this is an fcc bug or the Hal9k rom I use). On my steering wheel MODE button if I press it twice it is set to go to ‘home’. If I’m using Apple Music and press MODE twice it doesn’t register the second press so straight away it changes the player to dab-z(because of what I said in point 3 about the mode button setting). However if I’m listening to dab-z and need to get to ‘home’ by pressing MODE twice then it works perfectly. This problem wasn’t seen in older versions of fcc but I have also updated the Hal9k rom at some point so I don’t know which has caused the problem. I would guess it is fcc as the double press setting is within fcc.

If there’s anything else I could provide to help you then please let me know.
[Android Head-Units] TYourdog:
I've been having an issue when the unit has booted it goes through its normal start up with FCC (it always reloads from start - guess its normal.. whether its been off for 1 minute or a few hours it makes no difference) but my biggest issue is when I press the home button when I am on a different screen other than FCC like my bluetooth, apps tray, etc. it always restarts FCC. It does not affect the app when I press the home button while on FCC main screen. I have tried clicking on the Restart FCC app, restarting the head unit, and resetting FCC. Sometimes the restart app helps but is not reliable.

I have the ATOTO A6Y version. I've tried some older versions, beta versions, alpha versions and none of them seem to fix the issue. I have ATOTO selected as head unit type, but I've also tried the others just to see if it would make a difference.

As you'll see in the video I have some apps that autostart, I have tried turning off autostart to see if that would correct the issue as well. This is a much shorter video than I originally recorded to help pass boredom to show only the issue. It shows how it restarts and how it also sometimes works flawlessly. Please help since it is a hassle having to wait for the app to restarts everytime I leave another program like my Bluetooth screen, or Music player.. Thanks!

https://www.dropbox.com/s/eblvpflbpftt0jx/FCCissue.mp4?dl=0
[Android Head-Units] Shadow128:
After a long time I tried FCC Car Launcher again on my PX5 Erisin (actual beta version) and it seems to run very good.

But one thing I found...

I'm using Poweramp almost the whole time and now it runs good (pausing and resuming after switch off/on).

But I've seen, that there is a difference from round about 20 seconds during switch off and on.

For example - I switched off the unit at playing time 01:00 and after switching on it's resuming at 01:20.

Is there a way to optimize FCC/reduce this time?
[Android Head-Units] SpeedFire-:
FCC Launcher 3.347 (also sent to a Release channel):

- Added contrast dark and bright styles to Compass widget.

- A non-working link to purchase Premium in About menu is fixed
[Android Head-Units] Scopesys:
The High Contrast styles are great -- enormous improvement for low contrast displays -- THANK YOU

but ..

The Pointer is still a pastel Pink color, and is therefore not very visible.

One last thing then -- could you make the High Contrast styles have a High contrast pointer -- ie 100% RED ( 0% Green , 0% BLUE)

Then its "Perfect" :)
[Android Head-Units] SpeedFire-:
I need your help with finding a bug.

I see this crash report in my online tracking:

android.preference.ListPreference.onDialogClosed (ListPreference.java:281)

But I don't see any hint where exactly this happens. And I can't reproduce it. If you've seen a crash when you closed some dialog / list - please tell me where is this dialog.
[Android Head-Units] SpeedFire-:
Fixed here: FCC Launcher 3.347b
[Android Head-Units] rigattoni:
Yup, it´s better to see, but...

Another idea for the compass and I think it would be better readable:

Instead of turning the compass needle, it would be easier to read if the compass rose would turn and the needle would stay stable on top. The "North" marker could be a bit bigger and colored.

What do you think guys?
[Android Head-Units] ric69:
I would like to buy your great launcher on playstore , do we have to be beta tester to have your last version ?
[Android Head-Units] rigattoni:
You can buy the version on playstore and download the newest version always out of this thread without being beta tester.
[Android Head-Units] SpeedFire-:
You will always have Premium. You can install alpha, beta or release - it doesn't matter. You can switch between release and beta and will still have your Premium activated. So you can install any version.
[Android Head-Units] SpeedFire-:
This was my initial idea, but.. it is very expensive in terms of device resources. Rotating a compass in a widget means that we need to "send" a new picture (an actual bitmap) to the widget for every frame. So if we want more or less smooth animation we need to calculate a rotated image which is then sent to the widget at least 10 times per second. Images should be crisp enough therefore each should be like 100-200 kb at least. This doesn't look like a lot of data but... app widget subsystem is not the most effective in terms of data transmission. And we can't just send a command to rotate an image. It is not available for app widgets.

Therefore, the idea to have a static compass image which is set once with a rotated small arrow (in our case just 4kb) was the great idea! It should work very well even on the slowest devices.
[Android Head-Units] ric69:
Perfect I bought it now, I will try to help with French translation now tkxs
[Android Head-Units] rigattoni:
Makes sense...

What about another idea...

Would you be able to move a PNG side-wards under a half transparent background?

Some years ago I did something like that in "C" for a self made home screen for Windows CE... which was more restricted in RAM and CPU.

Could look somehow like the attached photoshop´d pic...

View attachment 4913355
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Many thanks for updating the Pointer :) "PERFECT"

I must admit, I am very pleased that you designed the compass with a static Rose, and a moving pointer. ( ie NORTH UP).

This is the way I also set any GPS, or read any map-- rotating a map around (to me) is not the way to read a map, and becomes most disorienting wrt the real world.

Just the way my brain seems to like to work -- I do appreciated that others are more comfortable with DIRECTION UP.

Also, with a quick glance at the Compass, it is far easier to read where the Pointer is, and then remember that image, than to have to read the text N, S, E W and then visualize that when looking back at the road.

If DIRECTION UP is to be attempted, please make it an option, and not a replacement for the current NORTH UP compass :)

On a side note: taking about Image Processing :-

I took a peek at the Compass Rose and Pointer png files.

I was surprised to see that they had different image sizes, so there must be different scaling of those images to make them fit when the widget is being edited. (but not a big deal)

But both are square. Does the Pointer image really have to be square ? I assume you are rotating the Pointer Image around it's center, to move the pointer around the rose.

Could the Pointer Image not be Rectangular - ie same height, with pointer at top center, but the image only as wide as the pointer width.

Would this then require less processing to do the rotation, or is this really not an issue. ?
[Android Head-Units] SpeedFire-:
For me current implementation (with static compass) is also a lot easier to understand! So you're not alone :)

Regarding the arrow. I do not rotate and move the "small" arrow picture. I rotate the whole large image with arrow (which is mostly blank and with a small arrow directing to north) around the image center. This requires less resources.
[Android Head-Units] Scopesys:
I had though of that design as well.. which is very much like the horizontal moving card compass displays use in aircraft.

If it was an available option in FCC, I might use it on some screens,( because it can take up less page space) but I still think the current North Up design is optimum.

The trouble with the above side-wards display is, if the need to read moving Text, when the direction is changing, with a quick causal glance.

Also the need for a very high update rate, so the image does not appear to spear.

With the current moving pointer, the only thing you have to read is the Position of the pointer, and once you have that visualized, you can process that position without further looking at the display, to determine your Direction in terms of N, S E W etc. - or visualize that direction on your imagined North Up map.
[Android Head-Units] Scopesys:
Understood: you do not want to MOVE, just rotate. But maybe rotating a smaller" Rectangular" image is more efficient...

Both rotate only, about their Center point.

Note: I had to change the background color for these examples, so the image shape would display on the forum.
[Android Head-Units] SpeedFire-:
This should be possible. I'll try.