How to remap the 2 keys on the cover of the Nova Air with SDS100 Keymapper?

[Renate]

Originally Posted by CrazyCoder

W : Unable to add /system/hello, skipped

Oops, my fault. I've been caught on that too and forgot about it.

Your patched framework is in the PM.

This mod shouldn't be a problem, but be careful adding more things to your module. If you do something bad, it might be difficult to undo it.

Do you get ADB before/during the ~10 seconds of boot animation?
That means that your ADB is only dependent on "Linux" and not Android.
If ADB bongs only at the end of the animation that's not as desirable.
If you do something bad, then ADB won't start and you can't easily delete the badness in your module.
Since /data (userdata) is encrypted recovery won't be any help.

[CrazyCoder]

Thanks, I tried the patched framework you sent me. adb appears as soon as the animation starts.

Buttons now work on down as they should.

However, I'm getting a lot of crashes from Media Storage, ksync and other apps. Even KOReader crashes with this patched framework. Will have to revert, unfortunately.

Related logs: https://pastebin.com/raw/GuKPaFLm.

I guess it happens because you removed framework.jar\res\debian.mime.types and other resources from the jar.

UPDATE: I restored res and android folders in the framework.jar and now everything works. I only removed provider and telephony from android subdirectory.

[Renate]

Originally Posted by CrazyCoder

I guess it happens because you removed framework.jar\res\debian.mime.types and other resources from the jar.

Well, it's like you bought a new car and you're driving along and you hear a loud "Moo!"
And you say to yourself, "That can't be a cow, because this is a car and cows do not belong in cars under any circumstances."
And you turn around and there is a cow.

But like fitting a cow in a car, apparently you can put resources in a jar. It is uncomfortable, it is unexpected and you have to jump through some hoops to do it.
ClassLoader.getResourceAsStream() is your key to being an annoying software generator.

Ok, so download the new version at the same URL, the size is 31,045,046 (double check).

[CrazyCoder]

I already figured and fixed the issue by adding back the resources to the jar, thanks!

[Renate]

@CrazyCoder Did you just add the three mime.types or did you add in all the junk?
You should only need the three mime files. The rest is detritus from the build.

@csdvrx You have the same problem.
I've updated yours and it is available at the same URL, size 30,920,854

In my defence, the Poke3 framework.jar does not have those mime.types files in it.

[CrazyCoder]

Originally Posted by Renate

@CrazyCoder Did you just add the three mime.types or did you add in all the junk?
You should only need the three mime files. The rest is detritus from the build.

I added everything back except provider and telephony. I don't see any harm in adding XML resources that affect compatibility with older Android apps which may not work properly on Android 11 if these settings are missing.

[Renate]

All the xml came in with Android 11, so there's no sign of it on my Android 10 Poke3 3.2.4
I don't believe all those xml files are supposed to be there.
Do you see anything in /data/misc/appcompat ? Maybe the same files?

[CrazyCoder]

Originally Posted by Renate

Do you see anything in /data/misc/appcompat ? Maybe the same files?

I don't have this folder.

[csdvrx]

@csdvrx You have the same problem.
I've updated yours and it is available at the same URL, size 30,920,854

tysm!

For now I'm still working on the early adb part: I don't want to take any risks until I understand exactly what's happening and why, since there're a lot of seemingly weird things and not just in the Onyx builds but in Android in general.

We have the same desire to remove useless cruft, but some of it seem present for good reasons we don't understand yet (here: pre Android 11 compatibility) maybe because these reasons are very obscure!

So our natural hacker tendency to simplify/streamline/improve (whatever you want to call it!) may play against us, as it did play against me during the initial problems I had with fastboot (the ones that I first emailed you about).

FYI, I've found similar oddities in the ADB part: based on my limited knowledge of Android, adb used to have a special mode that allowed adbd to be started early in boot, with full root etc given the possible limitations (ex: no auth during early boot) to maximize the chance you will be able to connect and regain control of your system if you did something bad.

Based on my limited understanding, that was gutted by google for security reasons, and some kernels may have removed support for some important flags so it's uncertain whether it can be brough back as it was before.

On top of that, they also moved the adb binary quite a few times (next to last in /system/bin/adbd, currently it's standing somewhere in /apex)

To make things worse, onyx still has init scripts that will use any adbd binary found in /system/bin/, which lead me to funny yet interesting problems. Yesterday I lost a lot of time chasing weird bugs because I wanted to provide CrazyCoder a robust early adbd solution in case they wanted to deploy the patched framework, because I was afraid of potential problems it may cause.

Right now I'm trying to understand why I have adbd started twice, once during the boot animation (by the time the 5th square get painted on my Air C) then closed and started again when android stards. Then I want to isolate what is causing each of the starts.

My goal is to have the "early" adbd be a root with no auth, then have the normal adbd be the normal one: this way, if you do something bad and your android can't start, you'll have full root access to fix things. But if your android can start normally, you won't leave a security hole (to my dismay, I've learned there's a load of malware aimed at rooted devices!)

But right now I have a weird problem where 2 adbd "coexist", which shouldn't happen... I'll have to make them use different ports, with different sysprop so back to square one and designing a solution!

All this to say I think we have to be extremely careful about our interventions: we should make them as surgical as possible, at least until we know the precise role of all the involved parts and therefore the potential consequences (and thus the tradeoffs) of the things we do.

That may cause some apparently needless complexity (ex: my initial desire to have the adbd in a chroot etc) but Android seems to be a pile of poor decisions with weird retrofitting for compatibility reasons, which makes the whole thing very brittle, and requires complex solutions for apparently simple problem to avoid problems (ex: if android can't start and adbd would only be started after android start... oopsies)

The example of apps crashing because mime types were removed from a jar IN WHICH THEY SHOULDN'T BE IN THE FIRST PLACE (!!!) is a wonderful illustration of the issues that run deep within Android.

Anyway, if you know more about how adbd and started and by what, please tell me: I'm currently focusing my attention on /system/etc/init/hw/init.usb.rc and the content of /apex/com.android.adbd/etc/

[Renate]

Originally Posted by csdvrx

We have the same desire to remove useless cruft, but some of it seem present for good reasons we don't understand yet (here: pre Android 11 compatibility) maybe because these reasons are very obscure!

Yes, you can find (poor) documentation of how compat_config.xml files get generated, but no indication of where they are supposed to go. In any case it seem to only be for debugging applications: https://developer.android.com/guide/...ity/test-debug
I do not believe these files have anything to do with compatibility of older apps for general users or even that they are in the right place. Look at that maven stuff. What is that doing there?

From https://android.googlesource.com/too...Processor.java we can see

/**
 * Annotation processor for ChangeId annotations.
 *
 * This processor outputs an XML file containing all the changeIds defined by this
 * annotation. The file is bundled into the pratform image and used by the system server.
 * Design doc: go/gating-and-logging.
 */

Oh, so it goes in the "pratform"?

[csdvrx]

Originally Posted by Renate

Oh, so it goes in the "pratform"?

lolol

I think that's a good indicator for the """quality""" of Android, but we've got to do with what we have, so I'll keep working on adb and do my best to understand wtf is going on.

[csdvrx]

BTW @Renate we talked about the super partition, I've started reading more about it and this seems relevant: https://forum.xda-developers.com/t/g...again.4483933/

Tools on https://forum.xda-developers.com/t/g...npack.4041843/ may be necessary since google default ext4 may prevent altering the RO feature according to https://android.stackexchange.com/qu...-in-android-10

There're scripts on https://forum.xda-developers.com/t/s...id-10.4240703/ and https://forum.xda-developers.com/t/s...id-10.4240703/ but I haven't tested that yet.

[Renate]

All that super stuff is a big can of worms.
Even my Android 10 system partition is supposed to be incapable of rw mount according to some.
I don't have any problems, although I did have to remove the FEC.

Impediments to Sanity

• Possible? read-only partitions
• Shared blocks in partitions, EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS
• FEC
• AVB
• vbmeta
• super partitions

[csdvrx]

I've just started to explore the issue of the super partition, but it doesn't seem unsolvable. Complicated, yes (since there's at least EOFS and EXT4 DEDUP) but there are already scripts for that so I think people are learning about it.

BTW I now have adb running as root quite early, but not as early as I want, also it could be vulnerable to bugs since something kills it.

There's something funny going on at boot: adbd get started early, then restarted.

I'm trying to leverage that oddity to have the first adbd be run as root then the second as a normal shell (but only if boot succeed) for the 99% of the times when everything will work normally and the boot succeed, to avoid leaving a gaping security hole only required to fix problems 1% of the times during devel.

Right now I still don't understand why exactly this situation happens: I've read the very few pieces of documentation on android init.rc I could find, my initial impression is that it pales in comparison to systemd.

My findings so far:

1) the adbd socket that's required to run adbd is created twice, meaning it's run from some script

dmesg |grep adbd |grep 1000
[    8.653049] init: Created socket '/dev/socket/adbd', mode 660, user 1000, group 1000
[   19.553223] init: Created socket '/dev/socket/adbd', mode 660, user 1000, group 1000

2) The adbd at 8 seconds mean we could have a good and reliable way to connect, even if framework.jar is very bad and get the boot stuck.

I'm concerned about introducing problems for end users, something which could easily happen as we need to match the patched framework to the running one. Right now I'm thinking about using md5 to select which one to use in the magisk module.

@Renate or @CrazyCoder could you put your framework.jar and the patched version somewhere, so I can do its md5 and have a simple branching statement to use the correct framework.jar in the magisk module?

3) The adb restart is caused by some init.rc script.

Given the consistent timestamps across reboots, the restart seems to be due to sys.usb.configfs=0 being send by something which maybe shouldn't send it?

Check that:

# dmesg |grep sys.config.usb
[    8.647572] init: processing action (sys.usb.config=adb && sys.usb.configfs=0) from (/system/etc/init/hw/init.usb.rc:37)
[    8.648356] init: Command 'write /sys/class/android_usb/android0/enable 0' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:38) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/enable': open() failed: Permission denied
[    8.648931] init: Command 'write /sys/class/android_usb/android0/idVendor 18d1' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:39) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/idVendor': open() failed: Permission denied
[    8.649463] init: Command 'write /sys/class/android_usb/android0/idProduct 4EE7' action=sys.usb.config=adb && sys.usb.
configfs=0 (/system/etc/init/hw/init.usb.rc:40) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/idProduct': open() failed: Permission denied
[    8.649998] init: Command 'write /sys/class/android_usb/android0/functions ${sys.usb.config}' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:41) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/functions': open() failed: Permission denied
[    8.650650] init: Command 'write /sys/class/android_usb/android0/enable 1' action=sys.usb.config=adb && sys.usb.configfs=0 (/system/etc/init/hw/init.usb.rc:42) took 0ms and failed: Unable to write to file '/sys/class/android_usb/android0/e
nable': open() failed: Permission denied
[    9.217858] init: processing action (sys.usb.config=adb && sys.usb.configfs=1) from (/vendor/etc/init/hw/init.qcom.usb.rc:1633)
[    9.228277] init: processing action (sys.usb.config=adb && sys.usb.configfs=1) from (/system/etc/init/hw/init.usb.configfs.rc:17)
[    9.228340] init: processing action (sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1) from (/system/etc/init/hw/init.usb.configfs.rc:20)
[    9.294637] init: Command 'write /config/usb_gadget/g1/UDC ${sys.usb.controller}' action=sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1 (/system/etc/init/hw/init.usb.configfs.rc:23) took 65ms and succeeded
[    9.301022] init: processing action (sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1) from (/system/etc/init/hw/init.usb.configfs.rc:20)
[    9.305453] init: Command 'symlink /config/usb_gadget/g1/functions/ffs.adb /config/usb_gadget/g1/configs/b.1/f1' action=sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1 (/system/etc/init/hw/init.usb.configfs.rc:22) took 3ms

Given the permission errors that happen for weird (and currently unknown) reasons, I think /system/etc/init/hw/init.usb.rc is the root cause of the problem.

/system/etc/init/hw/init.usb.configfs.rc seems to have no permission problem, but /system/etc/init/hw/init.usb.rc does accoding to dmesg.

/system/etc/init/hw/init.usb.rc interestingly contains a service line for /system/bin/adbd (where I can put an adbd), and a default value that could be the cause of the adbd restart.

I've tried playing with selinux perms but it didn't help:

service adbd /system/bin/adbd --root_seclabel u:r:magisk:s0
#--root_seclabel=u:r:su:s0
    class core
    socket adbd seqpacket 660 system system
    updatable
    seclabel u:r:magisk:s0
#   seclabel u:r:adbd:s0

# Set default value on sys.usb.configfs early in boot sequence. It will be
# overridden in `on boot` action of init.hardware.rc.
on init
    setprop sys.usb.configfs 0

I think I'm very close to figure what happens during early boot.

I'll keep exploring the issue and see if I can fix Onyx permissions for them lol

[Renate]

There are two ways to configure a Linux USB gadget: the older sysfs and the newer configfs.
So Android decided to use both.

Since both are activated by triggers, the property sys.usb.configfs is used to select.

/dev/socket/adbd is for communication to the framework. That's how the confirm dialog pops up.

If you look at all the triggers for sys.usb.config, you'll see that many start/stop adbd. That's what's happening. The Java UsbManager is setting the USB mode when the Android subsystem boots.