yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] ab1702:
[MENTION=4292729]SpeedFire-[/MENTION] this did fix that issue, thanks.

Something I see occasionally though which is similar to what the other guy has mentioned that has got you the logs is that the players still don’t always autostart, but not very often.

It’s as if fcc forgets about the players after a long period of not using the unit or something in the system forgets them so then you have to manually start them. Not a big problem though as most of the time it does work.

I’m using hal9k Android 8 on a px5 but fcc is not whitelisted.
[Android Head-Units] okij:
[MENTION=4292729]SpeedFire-[/MENTION]:

I tested both possibilities (see 1st and 2nd screenshot of the according Tasker profiles) and both work reliable, i.e. I see a "Resume" toast message flashing when I wake the head unit from standby. So I can confirm that using the android.intent.action.SCREEN_ON intent works fine with Tasker. [MENTION=2550900]surfer63[/MENTION]: This proves that it does not only work with system apps, but with user apps too. I don't know if Tasker uses root for it, but I don't think so because I haven't seen a "root access granted" message popping up. Could you as a developer have a further look into this?

I tried to send an intent with these settings (see 3rd to 5th screenshot), but it doesn't do anything (so the last used player doesn't resume playing and I also don't see anything else being triggered by it.) As you can see in the 3rd screenshot, before sending this intent Tasker flashes a "Resume" toast message, which is shown every time that I wake the unit from standby. Only "ru.speedfire.flycontrolcenter.ACTION_ACC_ON" doesn't work yet. :(

Am I doing something wrong in Tasker or is FCC not responding to "ru.speedfire.flycontrolcenter.ACTION_ACC_ON" for some other reason?
[Android Head-Units] SpeedFire-:
Please send the log
[Android Head-Units] okij:
Of course. :) Logfile is attached.

On 16:08 I woke the unit from standby and repeated this at 16:09 and 16:10. Tasker was activated the whole time and the "Resume" toast message was shown each time.

If you see in the logfile that DAB-Z was started, it's just because I did this manually.

BTW, I just saw that for some reason the screenshots haven't been attached to my previous post, so I re-attached them and now it seems to be OK.
[Android Head-Units] surfer63:
I am not really a developer and my programming skills are perhaps 10% of Speedfire's. I'm just a techical user doing "something" here and there if it's not available and I need it.

After your testing I think you are right. It could indeed be some new android permission that tasker already tests for and requests for during install or activation, and FCC not yet. But to make sure I should download both tasker and FCC and compare their AndroidManifests and requiested permissions in code. Speedfire can do that much faster ;)
[Android Head-Units] realzoulou:
Maybe you are also impacted by this:

https://developer.android.com/guide/components/broadcasts#android_80

Following is a code snippet I added to DAB-Z to address the issue when users reported that the steering wheel controls don't work in Android 8 after I changed my compileSdkVersion to 28 (=Android 8.0)

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
if (!mMediaButtonReceiverRegistered) {
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction(Intent.ACTION_MEDIA_BUTTON);
registerReceiver(mMediaButtonReceiver, intentFilter);
mMediaButtonReceiverRegistered = true;
}
}
[Android Head-Units] SpeedFire-:
Can you add a Toast to your Tasker task so you can see if it was triggered or not. I don't see that ACC_ON action was triggered in your log.
[Android Head-Units] okij:
I already did so, as you can see in the 3rd screenshot that I attached to post #5150. A toast with the text "Resume" is shown each time that I wake the unit from standby. So yes, the task gets triggered.
[Android Head-Units] SpeedFire-:
OK. Please try this version: FCC 3.352 v2
[Android Head-Units] okij:
Thanks for the test version, I got a partial success with it. :good:

I got the following results:

DAB-Z resumes playback after waking the unit from standby when I turned off the car for less than ~10 seconds, so the unit still got power by the ACC power connection (in this case the interior lighting of my car doesn't turn off).

DAB-Z does not resume playback after waking the unit from standby when I turned off the car for more than ~10 seconds, so the unit only got power by the BATT connection (so the interior lighting of my car did turn off). I assume that the DAB USB dongle gets totally switched off in this case and therefore has to establish the USB connection again after the unit has been woken from standby (that's why [MENTION=7838245]realzoulou[/MENTION] implemented a delay before DAB-Z can start to play audio.)

FM Radio doesn't resume playback, no matter if I had turned off the car for less or more than 10 seconds.

Also GoneMAD Music Player doesn't resume playback, no matter if I had turned off the car for less or more than 10 seconds.

I added a CatLog from my tests with FCC 3.352 v2, during which I tried the standby behaviour about a dozend of times with the different audio players.

Edit: Thinking about my result, I'm not sure if it's maybe just DAB-Z which is continuing to play after standby when the ACC power supply hasn't been turned off. :confused:
[Android Head-Units] SpeedFire-:
I don't see that AccOnOffServiceReceiver was started even once :(

Your Tasker task looks correct but for some reason it doesn't start the Service. Please check that it is enabled and try to start it manually:

In this version I've added a Toast with confirmation of AccOn action started or cancelled.

FCC 3.352 v3
[Android Head-Units] okij:
Unfortunately this assumption was right: I did one more test with FCC 3.352 v2, having Tasker disabled and thus not reacting to the android.intent.action.SCREEN_ON intent, but still DAB-Z resumed playback after standby when the ACC power hadn't been turned off.

I just did some tests with FCC 3.352 v3, but I didn't see your toast with confirmation of AccOn. :(

First I tried it as before, with my Tasker profile enabled, and didn't see your toast confirmation. I even turned off my "Resume" toast in case that the toast messages interfere with each other.

Then I also tried to trigger ru.speedfire.flycontrolcenter.ACTION_ACC_ON manually by pressing the Play button in Tasker to start the according task, but to no avail.

Couldn't you make FCC react to a normal sendBroadcast intent for resuming audio playback instead of using the startService intent? This would allow us to rule out that something in the Tasker profile to trigger startService is wrong.
[Android Head-Units] SpeedFire-:
FCC is not a player and shouldn't become a fake player. This will introduce a lot of new bugs.

I've made a task in Tasker similar to yours and it runs AccOn action just fine. So maybe you need to recreate it from scratch and copy/paste all names from my Intent to avoid misspellings?
[Android Head-Units] okij:
I suggested this only for testing purposes, not for permanent integration. :)

And of course I want to use Tasker only as a workaround until FCC properly reacts to android.intent.action.SCREEN_ON on its own.

OK, I will try recreating the task for sending the sendBroadcast intent, but I will do this tomorrow. Actually I already used copy/paste for the names, so they should be OK.

Please post some screenshots of your task settings, so that I can compare them with my task settings.
[Android Head-Units] SpeedFire-:
OK, there were issues with both Toast not showed and Music not started. Please check this one: FCC 3.352 v5
[Android Head-Units] SpeedFire-:
Regarding MTK (8227) integration.

This seems to be extremely hard to integrate it. After many hours of investigation I've found some theoretical way to connect to MCU and to control it but... MTK checks the calling app (or for some other unknown parameters) and prohibits such control with "permission denied" and "unauthorized app" errors.

So they really tried to close their system from third party integrations as much as they can.

I will make some more attempts but chances are not very good :(
[Android Head-Units] okij:
To cheer you up, I've something very positiv to report about your FCC 3.352 v5 test release. :)

I get a "AccOn action started" (respectively "cancelled") toast every single time that I wake my head unit from standby, without using Tasker, so SCREEN_ON (or ACC_ON) now seems to be correctly recognized by FCC itself. :victory:

I'm not sure when exactly "started" and when "cancelled" is shown, but one of each (sometimes both successively) is shown shortly after the screen goes on.

What doesn't work yet is the automatic resume of audio (no matter if I use DAB-Z, FM Radio or GMMP). I think that you might have to use the same code here as when FCC gets freshly started.

Also I observed that the MiniMap display isn't working anymore when resuming FCC after standby. This issue was introduced with a code change from FCC 3.352 to FCC 3.352 v2 (as I just tested by re-installing these older versions), so should be easy to revert.
[Android Head-Units] SpeedFire-:
Please record a log
[Android Head-Units] okij:
I already took one this morning which I now attach to this post.
[Android Head-Units] SpeedFire-:
Thanks. But for some reason this log doesn't include AccOn events. So it would be nice if you could record a new one when you have time.
[Android Head-Units] okij:
So FCC must have reacted to ScreenOn events. This morning I mainly (or always?) turned off the screen of the head unit and not the ACC power.

I'll try to make some more tests, including ACC off, and fetch a log after my lunch break.
[Android Head-Units] okij:
OK, here is the new log. I did these actions:

~ 13:40 Cold boot

~ 13:41 Restart from standby without switching ACC off. When the screen turned on I saw the toasts "... STARTED" and some seconds later "... CANCELLED" flashing.

~ 13:42 or 13:43 Restart from standby with switching ACC off. When the screen turned on I saw the toast "... CANCELLED" flashing.

I hope that you can make something out it, since I can't do further tests in the next 3 or 4 hours.
[Android Head-Units] bossman4:
Thanks for working on this issue. If it does not work in the end, at least it was tried.

Eventually, I think there is a "changing" list of auto radio/audio configurations, manufacturers and sellers who have units that do (or don't) allow customization's to improve the look and feel of the units. These units should be preferred to be purchased by users that want something more than stock performance. The unfortunate situation is that most buyers don't know what "stock performance" really means. In a lot of cases, newer does not mean better.

Personally, I would have stuck with a PX5 type unit (e.g. GA2171S) for my second unit, but my configuration was strange and the market thin. Putting in a single DIN unit with flip screen (Android 9? 1024*600) in a 1989 Alfa Romeo that could look semi-stock when closed appeared to be the solution. That is why I chose the Pumpkin unit (AA0341B). Over time, I am finding some things that are less than optimal. (both unit and seller)

Complete integration with FCC is now one of my needs now.......

Clearly there is a list of "good" players and anticipated "good" players. My EONON PX5 appears to be good......
[Android Head-Units] bossman4:
This new EONON unit (attached picture) does not appear to be a good unit for integration with FCC.
[Android Head-Units] bossman4:
Looks like there are these basic FCC integration categories of Chinese auto units on the market these days

1) PX series (3,5,6)

2) MTK (8227L)

3) Airmont units (Joying)

It does not appear that the Android version (6,7,8,9) makes an enormous difference in the difficulty of FCC integration.

Thoughts?
[Android Head-Units] SpeedFire-:
We need to identify the most popular manufacturers of MTK devices. Because I have some apks from someone like com.ulc.radio which looks quite capable for integration.

Maybe such devices are popular enough.
[Android Head-Units] ric69:
Hello ,

I tried 352.v5 on my px30, its not better with FCC starter.apk installed. Worse, automatics apps are restarted several time each ignition ON and FCC launcher at the end

Edit sorry I can't log (partial root)
[Android Head-Units] SpeedFire-:
By the way, what is the expected behavior for autostarting the apps? They should be started:

1) Once a day

2) On cold boots only

3) On every wake up

4) Start only when it is checked that they are not currently running in the background

?
[Android Head-Units] rigattoni:
I think this test version seems not to be related to CSN2 units, but on my CSN2 the toast "doSwitchOn..". is shown on wakeup from sleep... and at least tested DAB-z and Poweramp played immediately.
[Android Head-Units] okij:
For using FCC on custom ROMs (like from Hal9k or Malaysk) it should be possible to configure FCC in a way that it doesn't autostart apps by itself, because this can better be handled by the ROM and FCC shouldn't interfere with this. The user can configure in the ROM which apps to autostart and he can whitelist apps which should not be closed during standby (so it's not necessary to restart them after standby.) So in this case FCC should only resume playing the last used audio source and restart its own program parts (like the MiniMap display or the player widget) if this should be necessary for stable and reliable operation.

For using FCC on non-custom ROMs IMHO a combination of 3) and 4) should be used, i.e. apps that are configured to autostart should be started on every wake up (and with this also on cold boot), as long as they are not already (or still) running in the background.

---------- Post added at 07:52 PM ---------- Previous post was at 07:34 PM ----------

That's interesting, because DAB-Z etc. did not resume playing on my MTCE unit, even though the toast was shown on wakeup.

Maybe you should also provide some logs to [MENTION=4292729]SpeedFire-[/MENTION], so that he can compare them with my logs.

Edit:

Two questions about your test:

Did you have FCC whitelisted, so that it doesn't get closed during standby?

Did you turn off the ACC power completely, so that the power for the USB DAB adapter gets switched off? I guess not, because you wrote "DAB-z ... played immediately". This also works on my unit, but the crucial part is that the playback also has to be resumed after ACC had been turned off.
[Android Head-Units] Scopesys:
Yes, I think I lucked out when I picked my EONON Px5 unit, which was before I even knew about FCC.

It might not have the brightest, highest contrast screen, but it does do well with FCC, which is now my primary criteria for picking a head Unit.
[Android Head-Units] Roerbakeitje:
So please report about any bugs which still exist.[/QUOTE]

Ok tanks for awnser .

Than I whant report bug :laugh:

Most of the widgets I can not set the hight only Wight . Is there a reason for?
[Android Head-Units] TT_Vert:
OOOh, what is this volume widget? I'm so sick of my joying radio knob stopping function and making me use the volume dropdown and touch controls.

Dave
[Android Head-Units] TT_Vert:
I'll look into nextsong, no idea what it is or what it does.

Speedfire- the volume widget does nothing for me. I logged pressing the widget volume buttons and then using the knob. Then pressing volume widget buttons again.

Log included (Had to zip it as sit wouldn't upload the txt file)
[Android Head-Units] B3rt:
i request again, i hope it can be added as soon as possible.

Please add the stock music player (MTC music) to the music player list for the media widget so it can show media info and control the player from the screen widget.

I am sadly obligated to use other media players then the original stock version which is suplied with the rom.
[Android Head-Units] SpeedFire-:
It is already added and is called 'Standard music player' please try it.

If it doesn't work please send me an apk of your music app.
[Android Head-Units] SpeedFire-:
Here is a new beta with small changes:

- DAB+ player integration (maybe... since I can't test it in emulator - please report what works and what not)

- Brightness widget small changes

2.432 (also uploaded to the market)
[Android Head-Units] jun81:
[MENTION=4292729]SpeedFire-[/MENTION]

2.432

restore settings

-widgets does not function properly after restore, empty widgets, unable to set.

volume adjustment

-more erratic adjustment, after manual adjustment, volume seems to be lower than usual volume.

-i do not mind having a toggle between option 1 and 2 but if you like to work on option 3 i can continue to test this option out.

-log attached

FM radio auto start

- does not auto start

- boots with no players playing

Player Widget

-Player fails to update PC Radio now playing
[Android Head-Units] B3rt:
Already tried it but does not work, no media info and also no music control (next/previous).

Attached the MTCmusic4 apk i got from /sys/apps/mtcmusic (i believe this was the path).
[Android Head-Units] SpeedFire-:
Thank you. This is the required file.

Could you please also send me your stock launcher apk - Launcher2mtc2.apk or something similar.
[Android Head-Units] B3rt:
Cannot find a file what is named that way or what is sumular, what i did find was in the /system/priv-app folder 2 laucher folders etc.

I zipped those files and attached them in this post.

I also can zip the complete the /system/app folder and you can take a look yourself, let me know.
[Android Head-Units] SpeedFire-:
I've tried to integrate it.

Could you please try this beta?

2.433

In this beta I've also added MiniMap shortcut for those who don't like right panel but still want to hide / unhide mini map.
[Android Head-Units] SpeedFire-:
Thanks!

Could you please check which of these bugs were / were not fixed in the latest beta (2.433 - see in the post above).
[Android Head-Units] B3rt:
I will try this afternoon and let you know
[Android Head-Units] B3rt:
Tried it but works only 'half'..

What now works:

- the widget controls next/previous work now work on standard player

- when the short link in widget is pressed, music is started from the standard player

What stil does not work:

- no media info (number, artist, album art etc) shown in widget

- when pressed on the widget the music player is not opened, using poweramp or radio this works but not with standard music player

- player is not resumed on boot

Hope this info helps.
[Android Head-Units] SpeedFire-:
LogCat log would be helpful.

So there is no any title on the widget at all?
[Android Head-Units] B3rt:
no nothing, completely blank
[Android Head-Units] jun81:
[MENTION=4292729]SpeedFire-[/MENTION]

Restore Settings

-widgets still not restored.

-Does not seems to complete restoring. no toast about finish setting up.

-log attached

Player+radio widget

-PCRadio now playing list now updates

-but turns blank after redraw of launcher

Thank you for making effort to nail all the bugs!
[Android Head-Units] SpeedFire-:
Several bugs were fixed in the latest beta. It is uploaded to the market. Please check.
[Android Head-Units] SpeedFire-:
Can you please check this on the latest beta from the Play Market?

If still blank - please send me a Log of switching between songs.
[Android Head-Units] rigattoni:
[MENTION=4292729]SpeedFire-[/MENTION]

There is a toast shown as you can see in the attached trace.

But... What you also can see there is a crash:

01-20 22:32:05.688 806 806 D McuManager: ru.speedfire.flycontrolcenter<<kill:1:100
01-20 22:32:05.689 493 1971 I ActivityManager: Force stopping ru.speedfire.flycontrolcenter appid=10097 user=0: from pid 806
01-20 22:32:05.690 493 1971 I ActivityManager: Killing 1877:ru.speedfire.flycontrolcenter/u0a97 (adj 0): stop ru.speedfire.flycontrolcenter
01-20 22:32:05.693 493 511 I chatty : uid=1000(system) ActivityManager expire 56 lines
01-20 22:32:05.695 493 1971 W ActivityManager: Scheduling restart of crashed service ru.speedfire.flycontrolcenter/.FCC_Service in 1000ms
01-20 22:32:05.695 493 1971 W ActivityManager: Scheduling restart of crashed service ru.speedfire.flycontrolcenter/.assistant_volume.FCCAccessibilityService in 10999ms
01-20 22:32:05.696 493 1971 W ActivityManager: Scheduling restart of crashed service ru.speedfire.flycontrolcenter/.AchievementNotificationService in 20999ms
01-20 22:32:05.698 493 1971 W ActivityManager: Force removing ActivityRecord{1a18c16 u0 ru.speedfire.flycontrolcenter/com.android.fcclauncher.Launcher t781}: app died, no saved state

No, FCC is not whitelisted. This is not yet available in CSN2 units.

Yes, the unit is in deep sleep as I can see (USB Amp-Meter) that the USB is completely shut down and my Amp-Meter at my power supply.

Immediately is a may be a bit too euphoric... ;) , but it starts always playing DAB-z.

May be related to the fact that there are at least some FCC crashes in there and the unit has more time to get the DAB dongle up and running.

This needs to be analyzed I think... ;)
[Android Head-Units] okij:
If your CSN2 unit doesn't have a whitelist - do you know if it maybe even so doesn't kill FCC Launcher during standby?

I'm wondering that you see the v5 test version toast messages, which IMO only get shown if FCC survives standby. Otherwise FCC couldn't react to the SCREEN_ON and/or ACC_ON intents which the system sends immediately after leaving standby.
[Android Head-Units] rigattoni:
You can see all previous apps in the last apps list, but I had to set Tasker as system app to be able to get it working correct.

So each app needs to get started again after sleep mode. Tasker, set as system app, reacts immediately as it should be now and does not "forget" the accessibility rights as before.
[Android Head-Units] SpeedFire-:
According to logs your settings are incorrect:

autostart_last_player = false

You need to enable autostart player on boot in FCC Settings