Database Info

new binder driver helps your phone run smoother

Hi guys,
I've written a completely new Android binder driver (for IPC), which is targeted to solve some fundamental issues in the existing driver. One main improvement is to make concurrent IPC calls possible. Some background info can be found in my earlier post on Android kernel group:
http: slash slash groups.google.com/group/android-kernel/browse_thread/thread/c57874670e4decb1
(oops external urls are not allowed for new users
There weren't many people interested due to low volume of the group. Now that I have completed the first version, which is back compatible with the existing driver, and fixed a few bugs. I've tested on the ICS emulator and my phone U8150 Froyo. It seems to be running quite well, but I want to see how it runs on other Android devices while I'm getting my new phone. Test results, bug/issue reports, and of course community comments will be very welcomed, which are important for me to determine how the code should further move on.
Although not proven, I'm expecting not only those dual core phones, but single core ones will get an overall smoother response in various parts of the system.
Okay if this still somehow interests you, you can find my project on github
https: slash slash github.com/rong1129/android-binder-ipc
and just dive into the release directory, use the latest version (0.4 so far) to patch your kernel source tree, then upload the new kernel image to your device and see whether it works for you.
Note this is still an early release and has very limited tests so far. Please make sure you understand the risk before you hack your phone and always back up everything before you started. As other disclaims go, I'm not responsible for any damage may be caused by or related to using or in the process of using the driver
Lastly, happy hacking!
Cheers,
Rong

*subscribing to this thread*
Hi Rong,
thank you so much
our phones, tablets, etc.
can't have too much smoothness
I hope that I'll find some time within the next weeks to also give this a test on the Xoom and see whether it works (with ICS; Team Eos kernel)
there at least seem to be issues with ICS on the SGS (galaxys s1)
http://forum.xda-developers.com/showpost.php?p=23937103&postcount=2502

I found this thread . Is this driver the same on all android devices and roms? Or do you have to mod it for every single device/rom?

[DevTOOL][2012-10-01] Fast AAPT (#2) - Speed up Eclipse/apktool/etc

Presenting: Fast AAPT - aka FAAPT
Lately Android development has been getting me down. Slow builds all over the place in many of my app projects, and my PC is blazing fast - it shouldn't all be that slow, even if you're running Eclipse!
Working on DSLR Controller has been driving me mad - testing a minor change in the underlying communications library, then building and launching the app - ugh! So I set out to fix this. I had done all the usual tricks, even gave Eclipse loads more memory (helped with regular performance, but not building) but nothing major seemed to change. Then I figured out most of the time building was spent in AAPT. So I synced my AOSP repo (2012.09.26, took a few minutes), tried to get the Windows SDK to build on my Linux box (took several hours) and finally got to actually mucking with the source.
Found the bottleneck (for my long-build-time projects at least, related to XML file compilation) and fixed it (by introducing a simple cache). "DLSR Controller" build time has gone down from 35 seconds minimum, to 2-3 seconds ( >10 times faster). Hell, I can even turn "Build Automatically" back on without getting constant delays!
Note that my build times quoted only apply to incremental internal builds. If your images still need to be "crushed" (optimized), or you're "exporting" an APK (final build for publication), build time will still be significantly longer. However, during normal development and testing (by far most builds if you're making an app in Eclipse) those stages are not performed, and builds should be lightning fast.
"Fixed" is a big word though, right now it's more of a "hack", and it needs some pollish, so the patch can be submitted to AOSP. I don't want to keep it from you for that long, so my first test build is attached - don't use it in production builds..
Patch code has been submitted to:
AOSP - #1 Cancelled, #2 Review in Progress ... superseded by ctate rewrite
AOKP - #1 Merged, #2 Merged
CM - #1 Cancelled, #2 Merged
Attached ZIP includes Linux, Windows and Mac OS X versions.
The files are drop-in replacement, but I would certainly advise you to backup the originals for your production builds! Also, don't forget to chmod/chown on Linux or it won't work.
Enjoy and leave some feedback
Will this help your project build ?
A quick way to spot if this will have effect on your slow build is as follows:
- In Eclipse, set Build output to Verbose under Window -> Preferences -> Android -> Build.
- Clean and build your project.
- If the build pauses on lines in the "(new resource id <filename> from <filename>)" format, you have the problem FAAPT fixes
(of course, you can also run aapt manually if you know how, you'll get the same output)
In a full framework build the optimizations only affect a very small portion of the actions done during the build, so you won't see any spectaculair speed increases there.
Update (#2)
I have updated the patch code to fix problems with Mac OS X compatibility, I've also included a Mac OS X binary in the new zip file.
-----
( v1: 557 )

So that's what's been killing the speed of my eclipse then. It froze so often I had to switch to AIDE on my phone. Hopefully this'll speed it up a little
Sent from my Galaxy Nexus using Tapatalk 2

Awesome work Chainfire, will play around with this in a few

Thanks brother, gonna give it a try right now on Linux
EDIT:
It works. Gave it three tries. Went consistently around 19.1 sec with FAAPT and 33.9 sec with regular AAPT. This is on the Linux version. Good job

Amazing work. Handles large resources like framework-res a lot faster.

wildstang83 said:
Thanks brother, gonna give it a try right now on Linux
EDIT:
It works. Gave it three tries. Went consistently around 19.1 sec with FAAPT and 33.9 sec with regular AAPT. This is on the Linux version. Good job
Click to expand...
Click to collapse
Glad to hear the Linux version also works! Too bad your increase is not as much as mine, but I guess it depends heavily on the amount and type of assets in your project.

Chainfire said:
Glad to hear the Linux version also works! Too bad your increase is not as much as mine, but I guess it depends heavily on the amount and type of assets in your project.
Click to expand...
Click to collapse
I tested on a theme project of mine, so its heavy in img files. Thats probably why. I'm not complaining one bit. Absolutely love it and can't wait to try it out on my other apps

Chainfire said:
Glad to hear the Linux version also works! Too bad your increase is not as much as mine, but I guess it depends heavily on the amount and type of assets in your project.
Click to expand...
Click to collapse
Indeed, tested the Windows version and yes it gives a very good result with a amount of assets, i got 7 time faster than the normal one on Eclipse, too bad we can't use it for production, we need one for Apktool .

wanam said:
Indeed, tested the Windows version and yes it gives a very good result with a amount of assets, i got 7 time faster than the normal one on Eclipse, too bad we can't use it for production, we need one for Apktool .
Click to expand...
Click to collapse
Actually, I was using it with APKTool.

Thanks CF.
Decompiling recompiling now is so fast

apktool and Maps.apk on Linux.
aapt - 29.2s to compile
faapt - 2.2s to compile
Amazing job, Chainfire!

Tested both in linux and winz....
It works great!
Untested time but noticeble faster.
What's the next step after elite rec dev for chainfire?

Thanks for the great work!
Could you post your tweaked source file(s)?
Would like to compile from source for OS X..

On my projects I see anywhere from 5 to 20x speed increase on build. Thank you for this magic.
I don't get how the google android SDK team did not optimize this (I know they done some crazy optimizations for different stuff).

Yeah, could you post your patch?

berdon said:
Yeah, could you post your patch?
Click to expand...
Click to collapse
He did say in the OP. He had to clean it up for AOSP inclusion, so just wait till you see it on Gerrit
Sent from MIUIAndroid Phone.

That is good stuff. It's gonna save me a whole lot of time. The thanks button was just not enough to thank you!

Thanks for the great work Chainfire.

Whoa! Now I will surely stop cursing while waiting for xenoAmp tu build (just not enough time to say "kurwa!")! Thank you!

I'am using ArchLinux x64 as my normal desktop OS. (Yes, I don't have Windows.) and tried it with Eclipse, but it don't work.

Operation "Tuna Balls" (UNOFFICIAL CyanogenMod 9 from source)

Hello,
I have released a very ugly, hacked up dump of my work from July when I attempted to port CyanogenMod 9 to the Nexus Q. It is incomplete, but compiles still, and functional. Developers might find this of use.
There was a large amount of interest in this work when I released a video of 'proof of concept' that went viral in July, before the consumer launch. This work was all created before Google pulled the launch (July), and many weeks before AOSP or OMAP repos had the source for device/vendor.
I call it "Tuna balls" due to the fact it's a raw rip off of the Tuna/Maguro base from CM9, dated July 2012, when I forked and modified it.
The codenames of the branches may be wrong. A lot of the 'bugs' may be easy to fix. Unfortunately, I never came back to this project after July.
As someone who strives for complete, QA process builds, I kept this private for months. I know it's not complete, please understand things don't work flawlessly. No audio (possibly hard to fix) and crashing System UI (probably easy to fix) can ruin your experience, but this can be hacked into shape
* GIT SOURCE *
https://github.com/kornyone/android_device_google_steelhead
https://github.com/kornyone/android_device_tuna_balls
https://github.com/kornyone/vendor_google_steelhead
https://github.com/kornyone/google-kernel-steelhead
Here are my notes/bug list from Github:
"Operation Tuna Balls"
This is a partially complete attempt at porting CyanogenMod 9 (Android 4.0.4) to the Nexus Q.
At the time of original creation (July), there was no other source available. As such, I used the Tuna/Maguro bases to port to the Steelhead, as there were so many common pieces.
This combination worked well for the majority of things. Known bugs never resolved since this project was orphaned in July include:
* No working audio. Mixers fail to load with tuna audio_hw.c. The OMAP "Steelhead" and AOSP "Phantasm" repositiories online have a -very- hacked up version of this file, but intended for Jellybean (as of writing). Also, OMAP has the audio listed as a known issue in their source releases.
* No working NFC. This could be easy to solve, I did not spend much time on it.
* System UI crashes. This should be a simple matter of finding this conflicting Tablet/Phone System UI layouts being requested (should be an overlay setting, likely).
Most everything else works. This includes:
* Bluetooth pair all the things, no hacks needed.
* Wifi works.
* XHDPI resolution works (when System UI doesn't crash).
* HW Acceleration in games work.
* Google Play Market is open for use.
--------------
While I am a maintainer for CyanogenMod, this work is not official in any way. It is incomplete, and I am more or less abandoning it at this point due to a broken Nexus Q and lack of free time. Please hit me up on Freenode (kornyone) for questions, ##nexusq is still open.
Thanks!

Proof of concept (so people don't have to dig this stuff up):
Video concept -- (Very rough) --
Photo gallery on G+ with screenshots -- https://plus.google.com/100539377198423911977/posts/GRxhSLRnNss

very nice mate
Sent from my Xperia T using tapatalk 2

kornyone. I was wondering where you put this. Thanks for the source release, it will come in use. I have a big move coming up but plan to pick up where you left off and maybe get some other devs in on this. Again, thanks for the xmas present!

how hard would this be to run cm 10 on it?

kornyone,
I was able to build and install your cm9!
Of course I have the same issues as you (systemui crashes, no sound) but hey it's something!
Thanks for everything and I hope there is still some progession on this!

[ROM][UNOFFICIAL][s5neolte][SM-G903F][11.0.0_r49] LineageOS 18.1[28-Nov-2021]

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
LineageOS is a free, community built, aftermarket firmware distribution of Android 11, which is designed to increase performance and reliability over stock Android for your device.
LineageOS is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. Linked below is a package that has come from another Android project that restore the Google parts. LineageOS does still include various hardware-specific code, which is also slowly being open-sourced anyway.
All the source code for LineageOS is available in the LineageOS Github repo. And if you would like to contribute to LineageOS, please visit out Gerrit Code Review.
###########################################################
Note: This is the first time I am building a ROM. My initial plan was to build it just for personal use. But since it is stable, I decided to share it with whoever is interested. I am not sure how often I will be updating it. But, I will try to do it every month. I added LineageOS recovery even though I do not use it at all. It can be downloaded if desired.
What's working:
RIL (Calls, SMS, Data)
Wi-Fi
Bluetooth
NFC
Camera
Video Recording
Video Playback
Audio
Sensors
Flash
GPS
Vibration
Wifi Hotspot
Selinux enforcing
What's not working:
Nothing I am aware of.
Possible issue:
If phone does not connect to network, reset APN.
Go to settings->Mobile Network -> Advanced -> "Access point names" -> "3 dots" -> "Reset to default".
Flashing Instructions:
Copy Lineage zip to phone.
(Optional) Copy bit gapps to phone.
Boot TWRP
Backup things you want to keep.
Tap Install -> Select LineageOS zip (and optionally, gapps)
Swipe to flash
Reboot system now
First boot, especially with Gapps, may take a while.
Downloads:
LineageOS 18.1
Optional: Bit Gapps. This is the only gapps that has 32bit for android 11 AFAIK.
Optional: Lineageos recovery
Sources:
https://github.com/LineageOS
s5neolte lineage-18.1 branches
Fincer branch : android_device_samsung_s5neolte_lineageOS
XDADevDB Information
[ROM][UNOFFICIAL][s5neolte][SM-G903F][11] LineageOS 18.1, ROM for the Samsung Galaxy S5 Neo
Contributors
The authors and maintainers of s5neolte gerrit branch PixelBoot, Stricted, danwood76, Borduni, Fincer
ROM OS Version: Android 11
ROM Kernel: Linux 3.10.x
Based On: LineageOS
Version Information
Status: Testing
Created 2021-06-16
Last Updated 2021-11-28

Changelogs
13-Sep-2021
- September security update
- Update Lineage sources.
11.08.2021
- August security update.
08.07.2021
- July security update
- Update Lineage sources.
- NFC fix applied. Thanks @Fincer
17.06.2021
- Added "Night Light" to display settings.
16.06.2021
- Initial release

Reserved

For now i cant test it cause i had to put back the latest stable official rom from Samsung on this spare phone, but, good work, keep it up. I'll try it for sure soon or later.
Maybe you could even try to reach out / join forces with Stricted and the others if that could simplify all of you guys' work on the roms. Idk, just saying.

Android 11!?!?! I was surprised that the S5 Neo got Android 10 and thought there was now way it would get Android 11, but I guess I was wrong. I wish I could test the rom, but the display on my S5 Neo is completely dead. RIP.

NFC without function, and the ROM feels a bit laggy, Pico GApps installed. Anyways, nice giveaway.

0LDST4R said:
NFC without function, and the ROM feels a bit laggy, Pico GApps installed. Anyways, nice giveaway.
Click to expand...
Click to collapse
NFC issue might be caused by the final 2 commits in the device tree.
s5neolte: build nfc hal from source · LineageOS/[email protected]
Change-Id: Ief7ef8f2a597b1a978ea4b0ec4e41391cec03a99
github.com
s5neolte: remove nfc manifest entry · LineageOS/[email protected]
* its a vintf manifest fragment now Change-Id: Ie81a0a3d7eb690fccb6987f16250d1c57cb1e8cd
github.com
The new NFC HAL doesn't allow updating the firmware. It fails on the A3 and A5.

JMek said:
For now i cant test it cause i had to put back the latest stable official rom from Samsung on this spare phone, but, good work, keep it up. I'll try it for sure soon or later.
Maybe you could even try to reach out / join forces with Stricted and the others if that could simplify all of you guys' work on the roms. Idk, just saying.
Click to expand...
Click to collapse
We have already completed the 11 bringup. This thread is really just a build of that work.
Regards,
Danny

I have got NFC working (s5neolte/Lineage OS 18.1), see my GitHub repository for details. After all, minor tweaks applied to current NFC [email protected] file and SELinux policy seem to be enough.

Fincer said:
I have got NFC working (s5neolte/Lineage OS 18.1), see my GitHub repository for details. After all, minor tweaks applied to current NFC [email protected] file and SELinux policy seem to be enough.
Click to expand...
Click to collapse
Thanks. I built a new version with NFC working. I see there is a commit in that branch that should enable call recording. I can't find the option in my phone though. It is maybe due to regional restrictions.

lallolu said:
Thanks. I built a new version with NFC working. I see there is a commit in that branch that should enable call recording. I can't find the option in my phone though. It is maybe due to regional restrictions.
Click to expand...
Click to collapse
Glad to hear . Call recording option should activate/be visible only during phone calls. Have you tested that?

Fincer said:
Glad to hear . Call recording option should activate/be visible only during phone calls. Have you tested that?
Click to expand...
Click to collapse
Yes, I tested it by initiating and later receiving a call. But recording option did not show up in either case.

lallolu said:
Yes, I tested it by initiating and later receiving a call. But recording option did not show up in either case.
Click to expand...
Click to collapse
Yeah, you are right. There are two relevant Dialer source java files which seem to dictate whether to show or hide the record option. The source code can obviously be patched.
packages/apps/Dialer/java/com/android/incallui/call/CallRecorder.java
- function canRecordInCurrentCountry() (lines 97-109) returns a boolean value
packages/apps/Dialer/java/com/android/incallui/CallButtonPresenter.java
- boolean variable showCallRecordOption, line 565, which gets its value from canRecordInCurrentCountry() function
- I assume showCallRecordOption dictates whether to show or hide recording button
I think one can simply replace lines 565-566 in CallButtonPresenter.java:
Java:
final boolean showCallRecordOption = recorder.canRecordInCurrentCountry()
&& !isVideo && call.getState() == DialerCallState.ACTIVE;
with
Java:
final boolean showCallRecordOption = !isVideo && call.getState() == DialerCallState.ACTIVE;

Bikeboy200 said:
Android 11!?!?! I was surprised that the S5 Neo got Android 10 and thought there was now way it would get Android 11, but I guess I was wrong. I wish I could test the rom, but the display on my S5 Neo is completely dead. RIP.
Click to expand...
Click to collapse
I was also surprised, I thought 10 would be the absolute max for the S5 Neo.

Fincer said:
I have got NFC working (s5neolte/Lineage OS 18.1), see my GitHub repository for details. After all, minor tweaks applied to current NFC [email protected] file and SELinux policy seem to be enough.
Click to expand...
Click to collapse
I have had a quick look over your changes.
The NFC sepolicy stuff doesn't look right to me (it may work but there is probably a simpler/correct way to fix it). I am guessing that an NFC file was incorrectly labelled, what were the original denials you were getting? I could probably fix our SEPolicy properly. It may be that Jan was in permissive when he made the original commits (I have usually taken care of the SEPolicy stuff).
The "patch_tcpsockettracker-crash.patch" fudges round a kernel bug which I should really get round to fixing, I think it is only a few picks (I might take a look at it tomorrow).
BTW running "device/samsung/universal7580-common/extract-files.sh" on an S5NEO stock firmware will probably break stuff, we use the A510F nougat as the source of the common files (our kernel is also based on the A510F). Running the extract scripts from the latest LOS version should work fine but it is actually better to simply use themuppets repo as that has our 18.1 changes already.
As you gathered the call recording feature is disabled in a lot of countries due to legality. For example it is illegal in Germany, Sweden, and lots of other countries.
Also if you fix anything you can always push your changes to gerrit and we can review/merge
Kind regards,
Danny

danwood76 said:
I have had a quick look over your changes.
The NFC sepolicy stuff doesn't look right to me (it may work but there is probably a simpler/correct way to fix it). I am guessing that an NFC file was incorrectly labelled, what were the original denials you were getting? I could probably fix our SEPolicy properly. It may be that Jan was in permissive when he made the original commits (I have usually taken care of the SEPolicy stuff).
The "patch_tcpsockettracker-crash.patch" fudges round a kernel bug which I should really get round to fixing, I think it is only a few picks (I might take a look at it tomorrow).
BTW running "device/samsung/universal7580-common/extract-files.sh" on an S5NEO stock firmware will probably break stuff, we use the A510F nougat as the source of the common files (our kernel is also based on the A510F). Running the extract scripts from the latest LOS version should work fine but it is actually better to simply use themuppets repo as that has our 18.1 changes already.
As you gathered the call recording feature is disabled in a lot of countries due to legality. For example it is illegal in Germany, Sweden, and lots of other countries.
Also if you fix anything you can always push your changes to gerrit and we can review/merge
Kind regards,
Danny
Click to expand...
Click to collapse
To me, looking at @Fincer's commits adding the SELinux rules, they seem like they've just been copied right out of a different device tree.
I'm using the new open source Samsung NFC HAL on my own LineageOS 17.1 builds. To address the SELinux denials that I got with it, I labelled its service in the sepolicy in my commit here: https://github.com/TALUAtGitHub/and...mmit/914f6ec44657732de3562fd1b259d3ad1b8fcf95 ...and so, your guess that a file, which happens to be the NFC HAL service, is incorrectly labelled is correct. Labelling it with the correct label is absolutely all that's necessary.
Speaking of NFC, I've got an issue with my S5 Neo where NFC only works with another phone that I've tested it with. It doesn't work with any of the NFC tags/cards that I've tested, and this issue exists with both the new open source NFC HAL and the old NFC HAL. I don't know if that issue exists on the stock firmware as I never tested NFC on it. Has anyone got similar issues?
On the topic of call recording, to enable it (for whichever regions it's set to be allowed in, of course), all that would be required is this change: https://github.com/TALUAtGitHub/and...mmit/11448569ef5d1358bae1e6abbfce9d37200f6887 I haven't tested it myself yet. Changes outside of device-specific trees, as have been shared for it, should always be avoided if at all possible.

So much technical stuff in this last posts. Very interesting for me to read all these things, and even more interesting how many people are active in development with this device. I'm just only the " typical enduser " with a fraction of all your knowledge, but i'm very happy to benefit from that.
Greetz, respect, and thanks.
_-_-_-_-_
0LDST4R
-_-_-_-_-

Thanks for commenting!
I am pretty sure there's room for fixes in my SEPolicy. What comes to NFC, I haven't copied all SEPolicy rules from "other device trees", although there are some rules used from other device tree sources (I know, rules should be evaluated, simply haven't had time for that). In most NFC rules, however, I simply allowed capabilities which did not cause any avc denials in my logs. I am pretty sure my SEPolicy might be too loose and should be more restrictive, and I am grateful if anyone like to improve it. I don't have list of original denials, but the current NFC SEPolicy rule set is mostly based on those.
Running '"device/samsung/universal7580-common/extract-files.sh" has not caused any issues on my S5 Neo, well, so far.
The patch file for TCP socket tracker crashing was one I found once I analyzed my logcat output and was seeing constant messages of the tracker process crashing. I don't like unnecessary crashes.
My personal opinion for call recording is that anyone who uses patches or workarounds to enable the feature takes legal and personal responsibility of doing so, as well.

TALUAtXDA said:
To me, looking at @Fincer's commits adding the SELinux rules, they seem like they've just been copied right out of a different device tree.
I'm using the new open source Samsung NFC HAL on my own LineageOS 17.1 builds. To address the SELinux denials that I got with it, I labeled it in the sepolicy in my commit here: https://github.com/TALUAtGitHub/and...mmit/7e1325429647c7420e02d106bfdd0477b44888e4 I also have this related commit: https://github.com/TALUAtGitHub/and...mmit/fe5d4e253c5310523e66c4ff2c84424d5beee424 That's absolutely all that's necessary.
Speaking of NFC, I've got an issue with my S5 Neo where NFC only works with another phone that I've tested it with. It doesn't work with any of the NFC tags/cards that I've tested, and this issue exists with both the new open source NFC HAL and the old NFC HAL. I don't know if that issue exists on the stock firmware as I never tested NFC on it. Has anyone got similar issues?
As for call recording, to enable it, all that would be required is this change: https://github.com/TALUAtGitHub/and...mmit/95dfe486a5cca4b5fe3c9721d927de4aca772e7f I haven't tested it myself yet. Whether or not the call recording option becomes available with it would depend on if call recording is marked as being illegal in your country. Changes outside of device-specific trees should always be avoided if at all possible.
Click to expand...
Click to collapse
That sepolicy change looks correct. Are you happy for me to cherry-pick your patch and upload to gerrit? (Or you could do that yourself?)
The moving config to vendor patch isn't quite right for us, I will do a correct version with your authorship if you are happy? (also upload to gerrit). We like to keep the config file names the same as on stock.
To test the NFC I use the android CTS verifier. You can emulate payments and all NFC functions using that.
I will also cherry-pick your call recording overlay patch, not really sure how that got dropped as I remember we had that a few years ago.
Thanks for your input.
Kind regards,
Danny

danwood76 said:
That sepolicy change looks correct. Are you happy for me to cherry-pick your patch and upload to gerrit? (Or you could do that yourself?)
Click to expand...
Click to collapse
Alright. Yes, you can upload it to gerrit. I don't know how to upload patches to gerrit yet, so it would be better for you to do it.
danwood76 said:
The moving config to vendor patch isn't quite right for us, I will do a correct version with your authorship if you are happy? (also upload to gerrit). We like to keep the config file names the same as on stock.
Click to expand...
Click to collapse
I've edited that commit through a rebase myself, and removed the change of the filename: https://github.com/TALUAtGitHub/and...mmit/c98d51d42c92af13bcfb8cb5157fcde077d9bdad
danwood76 said:
To test the NFC I use the android CTS verifier. You can emulate payments and all NFC functions using that.
Click to expand...
Click to collapse
I see. I think the CTS tests for NFC would pass. I just have the issue that I've described on my specific S5 Neo with both the new and old NFC HAL, and it looks like no one else has any similar issues. I think something might just be wrong with the NFC coil in the battery that I'm currently using, which really needs to be replaced, anyway.
danwood76 said:
I will also cherry-pick your call recording overlay patch, not really sure how that got dropped as I remember we had that a few years ago.
Click to expand...
Click to collapse
Okay. By the way, I've also edited that commit through a rebase to remove the call_recording_audio_source overlay, so that the default audio source, 1, is used. With audio source 4 which was set to be used through that overlay, call recording fails, with the following log messages from logcat:
Code:
[...]
07-15 09:48:02.103 3564 6980 E APM::AudioPolicyEngine: getDeviceForInputSource() no default device defined
07-15 09:48:02.103 3564 6980 W APM_AudioPolicyManager: getInputForAttr() could not find device for source 4
07-15 09:48:02.103 3564 6980 E AudioFlinger: createRecord() getInputForAttr return error -22
07-15 09:48:02.103 3594 5636 E IAudioFlinger: createRecord returned error -22
07-15 09:48:02.103 3594 5636 E AudioRecord: createRecord_l(0): AudioFlinger could not create record track, status: -22
07-15 09:48:02.104 3594 5636 E StagefrightRecorder: audio source is not initialized
07-15 09:48:02.104 6728 6746 E MediaRecorder: start failed: -2147483648
07-15 09:48:02.145 6728 6746 W CallRecorderService: Could not start recording
[...]
With audio source 1, it works fine.
danwood76 said:
Thanks for your input.
Kind regards,
Danny
Click to expand...
Click to collapse
You're welcome.

LineageOS 19.1 for s5neolte (SM-G903F, SM-G903W, and SM-G903M)

This is LineageOS 19.1, which is based on Android 12L, for the Samsung Galaxy S5 Neo, codenamed s5neolte, with models SM-G903F, SM-G903W, and SM-G903M.
LineageOS doesn't need much of an introduction - It's a well-known custom firmware/Android distribution.
I've picked up with these builds from @Radplay, as the original maintainer who brought up 19.1 for the S5 Neo.
His builds made use of my sources. Very long ago, I was maintaining for my own personal use, did bringup for 19.1, and was planning to start releasing public builds myself. But then my S5 Neo's screen stopped working, so I couldn't continue, and a few bugs I wanted to look into and fix went unfixed. Now that I've got a new screen, I've fixed those bugs, and can now release my own public builds.
Note on LineageOS 19.1/Android 12 usability - For those needing Google apps: Do not use heavy Google apps packages, as otherwise, you WILL have severe performance issues. Instead, use the most minimal variant of your chosen package. For example, for OpenGapps (no longer maintained officially, with no Android 12L packages, so use @ipdev's latest unofficial build available here), that is the pico variant.
Also, make sure to use 32-bit ARM packages, not 64-bit ARM64 ones, since these devices unfortunately don't run 64-bit Android despite being 64-bit capable.
Build download
From 20230625 with security patch level 20230605: https://drive.google.com/file/d/1KAvGHhp61zUJMAbnaasxrWnSTM2nNqBD/
Recovery to use
Use my unofficial TWRP build:
Image: https://drive.google.com/file/d/1dIgSDgPUBqben7tvylwL7zyhT9HeOAJ3/
Tar for Odin for the AP slot: https://drive.google.com/file/d/1guVj-Ghcneu9SR3ff3clLp9170CfJbNT/
This build is built from newer sources than the official TWRP builds and has a kernel built from the same sources as these LineageOS builds, so using it instead of an official one is preferable.
The official 3.7.0 TWRP build apparently might not work, while this is a working 3.7.0 build.
Folder for builds
Along with the current build, it contains a text file with the SHA256 checksum for it, and a folder which will contain some previous builds: https://drive.google.com/drive/folders/1jvNM__De4VASNoYmf8xjDZEMVmYSlr-3
Changelogs
Build for 20230625 (this changelog picks up from @Radplay's last build):
Latest changes from LineageOS, including the 20230605 Android security updates.
Bluetooth calling has been fixed.
Linaro's new SLSI BSP (Board Support Package, containing sources for HWC and some other stuff) sources are now used - Much more up-to-date than the previously used sources, and there's possibly a small improvement in performance.
Fixed an issue where the speaker would be slightly quieter than expected, and there is possibly slightly distorted audio at full volume from the headphone jack while playing media.
RIL blobs updated from Samsung's T515XXU8CVL1 firmware - Fixes an issue where, after enabling airplane mode, "Service status" under "SIM status" in "About phone" in settings wouldn't report "Radio off", meaning the cellular modem might still have been active in some way.
Some miscellaneous cleanups have been done.
Some security patches have been applied to the kernel.
The Wireguard kernel module has been removed from the kernel as it causes kernel panics. The userspace Wireguard implementation remains usable.
Previous releases
None for now.
Known issues and workarounds/fixes (if any)
Issue 1 - No VoLTE support: VoLTE currently can't work on any Samsung devices due to Samsung's proprietary implementation in stock firmwares not working on AOSP.
Issue 2 - Possible low volume and echoing while calling on speakerphone: There may be low mic volume issues and echoing that can be heard by the person you're calling, both while using the speaker.
These issues are supposed to be fixed by some blobs called "Lifevibes". They were added in official LineageOS 18.1 sources, but I decided to get rid of them as they completely destroy audio quality. As a workaround, the earpiece or headphones should be used instead.
If anyone wants them, I could have a way to bring them back as a compromise without including them in my builds, please do ask if so.
Some additional info if anyone is interested:
The lifevibes blobs apply insanely heavy noise gating, to get around the noisiness of this phone's microphones, and also heavily downsamples recorded audio in some way. Both processes result in horrible sounding recorded audio - The downsampling makes it sound lower fidelity than AM radio, and the noise gating is excessive to the point of annoying audible artifacts, and it may also get rid of audio content that can still be made out but is just above the noise floor of the mics. That ruined a mission-critical recording for me. I'd rather just take the noisiness.
Something notable is that with Android 12, encrypted data can't be decrypted in TWRP recovery. That problem can only be fixed within TWRP, but with the fixes only being in Android 12L TWRP sources, which we can't build our TWRP builds from due to issues, it continues to exist.
To report further issues, get a log from logcat and dmesg. If you're unsure on how to get either, there's good documentation out there for how to do so.
Sources
A manifest containing all of the necessary repositories to make builds is in the repository here on branch lineage-19.1.
Thanks to:
The previous maintainers, Stricted and danwood76, for all of the previous work for these devices.
The Lineage team - for the Android distribution itself.
...and everyone else who has worked on anything that is in use, such as device tree changes.

Some extra stuff:
I've now fixed almost all of the remaining fixable issues that I know of after extensive testing, making my build almost bugless. But if anyone does come across issues besides those I've mentioned in my original post, do report them.
For anyone here who was following @Radplay's thread until the end, on the stuff about credit, while it did end up being given very prominently, I think it's worth mentioning that it wasn't such a big deal. I suppose I overreacted somewhat. Everything is fine at the end of the day.
I'm going to try releasing a new build around every month.
Enjoy.

Nice to see this version released, good job
Just installed over the "other" one

Rocking!
did a clean install, twrp and the rom, all seems to be working well.
Thank you!