Jump to content

[DEV][ROM][5.2.] LineageOS 13 (Android 6.0.1) for ZTE Open C / Kis 3


Guest KonstaT

Recommended Posts

Guest vellow
18 hours ago, KonstaT said:

Patch you posted isn't much different from that. It only sets two additional properties but I'm quite sure we don't need them anyway (persist.radio.dont_use_dsd=true was already present in KitKat blobs but it wasn't set in dual-SIM stock ROM, ro.telephony.ril.config=simactivation shouldn't be needed). Please make a clean installation and test the patch that is in the third post of this thread.

I just comment on both line you told me, then clear dalvik and cache too just to make sure, and still work. Lazy me to make clean install :), cause i need to setup some other tweak again to gain my needs.

This rom is pretty solid, thanks again.

I've read your post how to build from source and other referrences, my plan is to creating it by my self just for hobby.

Edited by vellow
Link to comment
Share on other sites

Guest .:Dante:.
8 hours ago, stadtmobi said:

What did you revert to 2.7 - Doze Service?

 

Can you explain how please

Just installed previous version

Link to comment
Share on other sites

Guest KonstaT
17 hours ago, stadtmobi said:

Thank you.

 

I've installed Droid Hardware Info: The ST3-Axis Accelerometer works correct.

Until now i haven't found a way to reproduce it but i think it is after letting it in standby mode for a while.

It will be the same problem as described in the cm ticket you've linked.

I encounter it with all apps. Newpipe just uses a manual screenrotation when the playback is started. It does not read any sensor data (my good).

My logs do not show anything in particular.

Am i the only one with that issue?

I will make a nandroid backup and remove the doze service to test it.

There's now been few reports of this issue. I wonder if these are devices that also have a ambient light/proximity sensor? What does 'Kis 3 Hardware Info' app say under ambient light/proximity sensor? I just find it strange that I can't reproduce this myself (currently 100+ hours uptime, plenty of standby, and rotation works in every app I've tested). There must be some reason for that. It doesn't make sense that we'd need to change the rotation sensor timestamp format all of the sudden unless there's been some other related change that I've missed.

Can I see those logs, too? Please test downgrading/removeing the DozeService app and report back if it makes any difference.

9 hours ago, vellow said:

I just comment on both line you told me, then clear dalvik and cache too just to make sure, and still work. Lazy me to make clean install :), cause i need to setup some other tweak again to gain my needs.

That's why there's nandroid backups you can create and restore. ;)

That's not quite enough. Persistent properties are stored in the /data partition. You'd need to remove /data/property/persist.radio.dont_use_dsd as well. You can use 'getprop' command in shell to see that those properties are not set.

7 hours ago, vellow said:

About PowerManager* wakelocks, does it related to kernel ?

No, not really. It's something in Android userspace keeping a wakelock (usually apps/service finishing some task).

Edited by KonstaT
Link to comment
Share on other sites

hallo,

i installed cm13 on my open c device. it seems to be running stable.
i noticed 2 issues:
- the above mentioned problems when rotating the device
- when using the navit gps navigation app:
  the app is not showing the maps, while stored geo locations are shown in the menu
  i used the same storage locations as before for the configuration files and maps (the external sd card),
  but there is no map shown.
  one thing i recognized is that the external sd card naming follows another scheme then in cm 12.1
i temporarily switched back to cm 12.1 where all is running perfectly.
Thank you for your great work, konstat!

 

Link to comment
Share on other sites

Guest stadtmobi
23 hours ago, KonstaT said:

There's now been few reports of this issue. I wonder if these are devices that also have a ambient light/proximity sensor? What does 'Kis 3 Hardware Info' app say under ambient light/proximity sensor? I just find it strange that I can't reproduce this myself (currently 100+ hours uptime, plenty of standby, and rotation works in every app I've tested). There must be some reason for that. It doesn't make sense that we'd need to change the rotation sensor timestamp format all of the sudden unless there's been some other related change that I've missed.

Can I see those logs, too? Please test downgrading/removeing the DozeService app and report back if it makes any difference.

No ambient light/proximity sensor on my device.

If i revert to the cm13 build befor your latest, rotation works correct.

For the logs: I get no log activity while rotating the phone after the problem appears. Hereby the log after a fresh reboot when rotating still works:

 

03-15 13:52:17.175   633   668 I ActivityManager: Config changes=480 {1.0 262mcc7mnc de_DE ldltr sw320dp w533dp h296dp 240dpi nrml long land finger -keyb/v/h -nav/h s.6 themeResource=null}
03-15 13:52:17.185   633   834 I InputReader: Reconfiguring input devices.  changes=0x00000004
03-15 13:52:17.186   633   834 I InputReader: Device reconfigured: id=3, name='goodix_touchscreen', size 480x800, orientation 3, mode 1, display id 0
03-15 13:52:17.313  1594  1594 D PullToRefresh: Setting Padding. L: 0, T: 0, R: 0, B: 0

 

Edited by stadtmobi
Link to comment
Share on other sites

Guest KonstaT
On 3/15/2016 at 2:49 PM, stadtmobi said:

No ambient light/proximity sensor on my device.

If i revert to the cm13 build befor your latest, rotation works correct.

For the logs: I get no log activity while rotating the phone after the problem appears. Hereby the log after a fresh reboot when rotating still works:

OK, I can also reproduce the rotation issue on a clean installation. It doesn't happen with my 'dirty' data for some reason. Switching the rotation timestamp seems to fix it but then you'd need to do clean installation or it's broken otherwise (device freezes waking from sleep). Not quite sure what's going on. :o (Edit. Nevermind, something else wrong with yesterday's build. Still not sure if this is the right 'fix' or not.) At lest it's not due to some device specific change (DozeService, SELinux). Something must have changed upstream CM that makes this now required all of the sudden. It's a pain in the ass to figure out because I haven't done any builds for this device between those builds I've released. Also long gone are times when I still read practically every line of code that was merged...

I've put the 7.2. build back to the OP. I'd recommend using that until I figure something out.

Edited by KonstaT
Link to comment
Share on other sites

Guest KonstaT
7 hours ago, stadtmobi said:

Thank you for your effort.

By clean install do you mean i cannot install it and apply afterwards a nandroid backup?

Restoring a nandroid backup always puts your device back to the point when the backup was created (Android system and your data). So, I can't quite understand what you're asking. ;)

Link to comment
Share on other sites

Guest vellow

KonstaT,

If i want to play with kernel, do i have to download cm source too?

I have already setup the environment. My plan is to add some governor to kernel.

And if i want to try to build other custom rom, like paranoid maybe, is there anything else i should take care off beside adding its source?

Edited by vellow
Link to comment
Share on other sites

Guest KonstaT
6 hours ago, vellow said:

KonstaT,

If i want to play with kernel, do i have to download cm source too?

I have already setup the environment. My plan is to add some governor to kernel.

And if i want to try to build other custom rom, like paranoid maybe, is there anything else i should take care off beside adding its source?

No, not necessarily. You'll just need the kernel source and a toolchain to cross compile (gcc-4.9 for Marshmallow and gcc-4.8 for previous versions). Then of course some tools to unpack/repack boot.img (unpackbootimg, mkbootimg). If you also want to compile dt.img, you'll need some tools for that, too (dtbTool). IMO it's just so much easier to build it as a part of Android build (I always have some Android source laying around).

Other ROMs should be pretty easy to bring up depending on how much they're based on CM. There could be some minor things you need to change in the device tree to adapt the build to the other ROM (cm.mk -> foobar.mk, some makefile inheritance, etc). If you want to build CM13 yourself, you'll need one patch at the moment.

Link to comment
Share on other sites

Guest vellow
13 hours ago, KonstaT said:

No, not necessarily. You'll just need the kernel source and a toolchain to cross compile (gcc-4.9 for Marshmallow and gcc-4.8 for previous versions). Then of course some tools to unpack/repack boot.img (unpackbootimg, mkbootimg). If you also want to compile dt.img, you'll need some tools for that, too (dtbTool). IMO it's just so much easier to build it as a part of Android build (I always have some Android source laying around).

Other ROMs should be pretty easy to bring up depending on how much they're based on CM. There could be some minor things you need to change in the device tree to adapt the build to the other ROM (cm.mk -> foobar.mk, some makefile inheritance, etc). If you want to build CM13 yourself, you'll need one patch at the moment.

Thank you very much, i learn a lot from you.

For unpack/repack boot.img, I already got used to with it. ;).

Btw, in init.cm.rc, i see that sysinit is called during boot process, but seems like script in init.d doesnt properly run. Do you know how to make it run?

I already edit init.rc and init.cm.rc in ramdisk to get it to work, but still it wont work.

PS: i put init.d script to test if its properly run by creating log in /data.

Link to comment
Share on other sites

Guest KonstaT
2 hours ago, vellow said:

Thank you very much, i learn a lot from you.

For unpack/repack boot.img, I already got used to with it. ;).

Btw, in init.cm.rc, i see that sysinit is called during boot process, but seems like script in init.d doesnt properly run. Do you know how to make it run?

I already edit init.rc and init.cm.rc in ramdisk to get it to work, but still it wont work.

PS: i put init.d script to test if its properly run by creating log in /data.

Is your script executable (755)? Running scripts from init.d works just fine, you don't need to edit anything (e.g. you can see the CM banner in log).

02-26 01:56:56.372   264   264 I sysinit : Running /system/etc/init.d/00banner 
02-26 01:56:56.412   270   270 I cm      : ____ _   _ ____ _  _ ____ ____ ____ _  _ _  _ ____ ___ 
02-26 01:56:56.433   273   273 I cm      : |     \_/  |__| |\ | |  | | __ |___ |\ | |\/| |  | |  \ 
02-26 01:56:56.454   276   276 I cm      : |___   |   |  | | \| |__| |__] |___ | \| |  | |__| |__/ 
02-26 01:56:56.539   296   296 I cm      : Welcome to Android 6.0.1 / CyanogenMod-13.0-20160316-UNOFFICIAL-KonstaKANG-kis3 
02-26 01:56:56.563   302   302 I sysinit : Running /system/etc/init.d/90userinit

 

Link to comment
Share on other sites

Guest vellow
3 hours ago, KonstaT said:

Is your script executable (755)? Running scripts from init.d works just fine, you don't need to edit anything (e.g. you can see the CM banner in log).

Yes, the permissions is fine. i've checked it several times.

Hmm.. I must screwed up somewhere. Its time to do clean install.... again.

Update : After doing clean install, i got error with SELinux policy ?

02-04 16:59:13.169   141   141 I auditd  : type=1403 audit(0.0:2): policy loaded auid=4294967295 ses=4294967295
02-04 16:59:13.179   141   141 I auditd  : type=1404 audit(0.0:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
02-04 16:59:16.079   172   172 I auditd  : type=1400 audit(0.0:4): avc: denied { remount } for comm="busybox" scontext=u:r:sysinit:s0 tcontext=u:object_r:labeledfs:s0 tclass=filesystem permissive=0
02-04 16:59:16.079   172   172 I auditd  : type=1400 audit(0.0:5): avc: denied { remount } for comm="busybox" scontext=u:r:sysinit:s0 tcontext=u:object_r:labeledfs:s0 tclass=filesystem permissive=0
02-04 16:59:16.089   175   175 I auditd  : type=1400 audit(0.0:6): avc: denied { remount } for comm="busybox" scontext=u:r:sysinit:s0 tcontext=u:object_r:labeledfs:s0 tclass=filesystem permissive=0
02-04 16:59:16.089   175   175 I auditd  : type=1400 audit(0.0:7): avc: denied { remount } for comm="busybox" scontext=u:r:sysinit:s0 tcontext=u:object_r:labeledfs:s0 tclass=filesystem permissive=0
02-04 16:59:16.089   169   169 I auditd  : type=1400 audit(0.0:8): avc: denied { write } for comm="00test" name="/" dev="mmcblk0p13" ino=2 scontext=u:r:sysinit:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
03-17 18:38:58.323   205   205 I boot_progress_start: 11741
03-17 18:38:59.132   205   205 I boot_progress_preload_start: 12550
03-17 18:39:03.795   205   205 I boot_progress_preload_end: 17213
03-17 18:39:04.236   717   717 I boot_progress_system_run: 17653
03-17 18:39:04.802   717   717 I boot_progress_pms_start: 18220
03-17 18:39:05.361   717   717 I boot_progress_pms_system_scan_start: 18780
03-17 18:39:13.095   717   717 I boot_progress_pms_data_scan_start: 26514
03-17 18:39:20.982   717   717 I boot_progress_pms_scan_end: 34400
03-17 18:39:21.147   717   717 I boot_progress_pms_ready: 34565

 

Edited by vellow
Link to comment
Share on other sites

Guest KonstaT
9 hours ago, vellow said:

Update : After doing clean install, i got error with SELinux policy ?

Yeah, you just can't go writing stuff to /data. SELinux is wonderful. :P You could put SELinux to permissive mode with kernel cmdline parameter (androidboot.selinux=permissive) for testing purposes.

Is that from CM13? Why does your script need to remount anything and why are you using busybox (it was replaced by toybox in CM13)?

Link to comment
Share on other sites

Guest vellow
20 hours ago, KonstaT said:

Yeah, you just can't go writing stuff to /data. SELinux is wonderful. :P You could put SELinux to permissive mode with kernel cmdline parameter (androidboot.selinux=permissive) for testing purposes.

Is that from CM13? Why does your script need to remount anything and why are you using busybox (it was replaced by toybox in CM13)?

Done changing to permissive. Now its good, at least for me.

And yes, it was from your CM13 build. I was confuse about tweaking this build and using toybox, since i got used with busybox, so i was forcing this rom to use busybox, my purpose is making it more battery friendly. I have made some adjusment for scheduler ( you are using bfq which is more power consume from my experience ) so i changed it to noop and add some other performance tweak i found in other forum for balancing. And also doing other governor tweak... etc, ( you must be more expert on this one ).

Now, i found this rom more suitable for me. Consume 0.2% per hr. :). 

Btw, git clone from your source is really make me to be more patience, i dont have a fast data connection. ;). So the option for me now is tweaking this rom. I will try again when my router got fixed.

Yay, new build..... Thanks.

Edited by vellow
Link to comment
Share on other sites

Guest stadtmobi

Thank you KonstaT!

The new build works great.

By the way: I've remarked also that the live display day/night switch did also not work on the last build 20160308. It works now too.

Time for another donation :)

 

Link to comment
Share on other sites

Guest KonstaT
14 hours ago, vellow said:

Done changing to permissive. Now its good, at least for me.

And yes, it was from your CM13 build. I was confuse about tweaking this build and using toybox, since i got used with busybox, so i was forcing this rom to use busybox, my purpose is making it more battery friendly. I have made some adjusment for scheduler ( you are using bfq which is more power consume from my experience ) so i changed it to noop and add some other performance tweak i found in other forum for balancing. And also doing other governor tweak... etc, ( you must be more expert on this one ).

Now, i found this rom more suitable for me. Consume 0.2% per hr. :). 

Keeping SELinux permissive is of course not a proper long term solution. I doubt that you even need that if your script is only writing to sysfs nodes. You don't necessarily even need any init.d scripts. E.g. Kernel Adiutor is a great app for tuning parameters for cpu governors and i/o schedulers.

Link to comment
Share on other sites

Guest vellow
19 hours ago, KonstaT said:

Keeping SELinux permissive is of course not a proper long term solution. I doubt that you even need that if your script is only writing to sysfs nodes. You don't necessarily even need any init.d scripts. E.g. Kernel Adiutor is a great app for tuning parameters for cpu governors and i/o schedulers.

Looking some advice from you. ;).

Im thinking, is it worth write it all directly in to kernel?

If it does, which stage should i put it ? 

I already try a few line, and how do i check it, if it does really work?

I dont wanna use kernel adiutor, set cpu or other apps, if i could implement it through script.

Link to comment
Share on other sites

Guest KonstaT
5 hours ago, vellow said:

Looking some advice from you. ;).

Im thinking, is it worth write it all directly in to kernel?

If it does, which stage should i put it ? 

I already try a few line, and how do i check it, if it does really work?

I dont wanna use kernel adiutor, set cpu or other apps, if i could implement it through script.

IMO no, not worth it. Why make things too difficult (maintaining that between updates is also going to be a pain).

CPU governor parameters are set in /system/etc/init.qcom.post_boot.sh and if you want to change i/o scheduler you need to remove/change the related property from build.prop, too.

Simply cat the sysfs nodes you've written your values to verify (or use an app like Kernel Adiutor ;)).

Edited by KonstaT
Link to comment
Share on other sites

Guest KonstaT
1 hour ago, Muhlis said:

flash custom rom cm13 and cm13 dual data .zip btw sim card not detected .How to bug fix sim card not detected ??

What is dual data zip? Read FAQ, third post of this thread!

Link to comment
Share on other sites

Guest vellow
On 3/20/2016 at 2:15 PM, KonstaT said:

IMO no, not worth it. Why make things too difficult (maintaining that between updates is also going to be a pain).

CPU governor parameters are set in /system/etc/init.qcom.post_boot.sh and if you want to change i/o scheduler you need to remove/change the related property from build.prop, too.

Simply cat the sysfs nodes you've written your values to verify (or use an app like Kernel Adiutor ;)).

Ok, i had change the way I implement the tweak. You turned on another light bulbs in my head. :).

Edited by vellow
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.