tdm

Quick update... Got lineage to boot in enforcing mode today. Still need to tweak a few rules to get the fingerprint reader and lights hal to work. I'll probably have that done in a couple days. Then I'll start preparing for official lineage support. And of course, after that it's on to Q. Which should be pretty fast and easy. I'll be trying to get VoLTE working next week. @Hook has sent me a Verizon SIM to use for testing. Thanks!

Of course I can only change that in lineage, stock is another matter.

If you are on Linux, I recommend mounting with jmtpfs and then you can backup and restore however you like. Anything from tar to rsync to a GUI backup utility.

I don't know for sure, but initial code inspection seems to indicate there is no debounce interval set for the power button. This would be trivial to add.

Yes, adb backup will backup your applications. It is not guaranteed to backup all applications, as there is an opt-out for apps. But typically this is only used by sensitive apps (eg. my 2fa app for work opts out). Yes, your internal storage is accessed via MTP/PTP. You should be able to see all your files when you connect to a PC. Things like all your camera photos, music files, and such.

I've not really dived into the keyboard code in Android, but it seems the answer is yes... I think. The setting Settings.Secure.LONG_PRESS_TIMEOUT seems to be what controls the initial repeat delay, but I can't seem to make it work here. So perhaps that's not the proper setting. You can test it: settings get secure long_press_timeout settings put secure long_press_timeout <value> ... where <value> is an integer representing the timeout in milliseconds. Unfortunately the rest of the timing values related to the keyboard seem to be hard coded.

To answer your question directly, Android has its own unique init system (not based on sysvinit or upstart or anything else). The init "language" declares various things, including services (eg. daemons). Services by default are restarted when they crash/exit, infinitely many times. They can be marked "critical", in which case the device reboots when they crash too often (5 per minute, I believe), or "oneshot", in which case they are not restarted at all. Your symptoms could be either software or hardware. Software issues might be a service that continually crashes or even mayb

If it is happening to multiple people (sounds like it is) and arbitrary keys (again, sounds like it is) then it's almost surely a software issue. I'll have to double check, but I believe that userspace (Android) does the key repeat, not the kernel. This is the reasoning for marking it upstream. If that is true, then the issue is most likely related to timing under high workload.

You should be able to dirty flash. I think you need to delete the app signature database first so the lineage key check doesn't fail. But that should be all.

I've never seen or heard of such an issue. Does this happen for just a couple particular keys or for all keys? If it happens for only a few keys, it is most likely a hardware issue. If it happens for all keys, it's more likely to be a software issue. But tracking it down may be a challenge.

You can install and run Lineage at any time. My builds are nearly identical to the official builds.

FYI... Made huge progress on selinux today. I should have an enforcing build by end of week. And I think it can go official after that.

No and yes. Lineage itself does not have GMS (aka. gapps). FxTec could take Lineage as a base and add GMS, but that has some big pitfalls. The biggest is trying to get certified, because nobody really knows if Lineage passes CTS (certification tests). These can be a real pain to get working. The better option is to actually develop the current stock software. Lineage (and many other Android custom ROM projects) are open source and various bug fixes and features can be picked from them. It doesn't take much to make a huge difference in usability. As others have mentioned, my

That's because ... well ... it is. The stock software is not much more than the QCOM BSP (a reference for OEMs to start with) plus a custom launcher and updater.

As stated earlier, Secure Boot is disabled. So no, security can never be "proper" on the Pro1. But stock software and a locked bootloader should be able to pass corp checks since Android cannot "see" the Secure Boot setting. Android does see the bootloader lock state and pretty much any security type software will flag that as unacceptable. So no, you most likely cannot run Lineage with your corp stuff. And then there's selinux which is not fully working in Lineage yet, so that's another issue for corp use. There are workarounds (such as magisk and xposed), but I would never r

Yes, exactly this. Not only is it not my job to support their business model, but (1) their business model costs me money by burning through my limited mobile bandwidth and (2) they let malicious ads that carry malware through, putting my device, my personal reputation, and my financial well being at risk. If the ad ecosystem had stuck with a reasonable number of modestly sized ads and vetted the content appropriately, I would not feel the need to block them.

Thank you for the confirmation that it is fixed. This means the actual DT2W configuration change fixed the issue and the I2C changes were not necessary. I'm mildly interested in the I2C changes, but I have no idea what is wired to i2c_7. I guess as long as it works, I'll just leave it.

The fingerprint storage in /persist is probably full: https://community.fxtec.com/topic/2799-deleted-fingerprints-not-deleted/?do=findComment&comment=45138

Secure Boot is a Qualcomm-specific mechanism that enforces the phone must run signed (trusted) code from power-on to the bootloader. This setting cannot be changed by the user, it is a very low level setting that can only be enabled at the factory (and, once enabled, can never be disabled -- it's a hardware fuse). The "device state" (locked or unlocked) is a bootloader setting that may be toggled by the user with the fastboot tool. As far as I know, the Secure Boot flag is not visible to Android in any way at all. I don't do corporate stuff on my personal device, so I can't say

It is rather common in my experience. For example, ZTE also does this. It is probably not a huge deal to have the sticker showing, as your identity is attached to your SIM card not your phone. But no reason to take any chances that someone could do something nefarious.

I believe Android supports a "free form window mode" that could be workable. I'm too lazy to look up how to enable it right now but I'm sure you can find it. I recall it requires putting a permission file into system.

Reminded me of this... https://twitter.com/21ryujin/status/1272135298873307137?s=19

+1 I would be quite interested in building and installing this. Where's the sources?

Mount /system r/w with "adb remount". Then edit the file /system/etc/prop.default. Change the following properties: ro.adb.secure=0 persist.sys.usb.config=adb Reboot and hopefully logcat will work from early in the boot process.

FYI... Apparently my last few builds have included GMS (Google Play Store, etc.) I've removed that and rebuilt. test16 is exactly test15 without GMS.