FORUMS

 View Poll Results: Did you find this thread useful?

Yes, it was very helpful to me.
 
1,625 Vote(s)
64.03%
No, I didn't feel it helped me.
 
421 Vote(s)
16.59%
I don't know.
 
492 Vote(s)
19.39%

[HELP THREAD] Ask ANY Question. Noob Friendly.

4,428 posts
Thanks Meter: 1,933
 
Post Reply Email Thread
29th June 2020, 02:26 AM |#45121  
Quote:
Originally Posted by SubwayChamp

Try RootDim (root) in Play Store.

Do you think might be some set prop commands might work? Seems like they should have some kind of .prop, config, .xml or some kind of manifest they can edit. There is some kind of file/files somewhere they haven't discovered that is setting the minimum to 10 that needs to be edited. I don't think it should be necessary to edit anything in the bootloader itself, should it? It shouldn't be necessary do anything at the compiling level, should it. Unlocked bootloader, root binaries/permissions, dm-verity, and permissive kernel/mode should be enough to modify whatever they want. There is probably something I'm not seeing in their issue that I'm missing that probably should be ridiculously obvious but isn't from my perspective, lol.

Sent from my SM-S767VL using Tapatalk
The Following User Says Thank You to Droidriven For This Useful Post: [ View ] Gift Droidriven Ad-Free
29th June 2020, 04:25 AM |#45122  
SubwayChamp's Avatar
Senior Member
Thanks Meter: 911
 
More
Quote:
Originally Posted by Droidriven

Do you think might be some set prop commands might work? Seems like they should have some kind of .prop, config, .xml or some kind of manifest they can edit. There is some kind of file/files somewhere they haven't discovered that is setting the minimum to 10 that needs to be edited. I don't think it should be necessary to edit anything in the bootloader itself, should it? It shouldn't be necessary do anything at the compiling level, should it. Unlocked bootloader, root binaries/permissions, dm-verity, and permissive kernel mode should be enough to modify whatever they want. There is probably something I'm not seeing in their issue that I'm missing that probably should be ridiculously obvious but isn't from my perspective, lol.

Sent from my SM-S767VL using Tapatalk

I think that the wide-system brightness values are set in system itself (no kernel nor bootloader related), in Android 10 Google changed some things in the API like where the props are placed; the directory was changed apparently and the adb commands might change too.
It's up every OEM to set a minimal to be accessed to the final user not a restriction from Google itself like the user did think.
May I'm wrong but probably since newer Android versions, it seems that now we need to root the device in order to change that since probably it's not enough with write_secure_settings permissions otherwise an app without root should do it with the interaction of the user and I don't know of any that do that by now (in a quick search)
I didn't try this command on Android 10 since I'm currently on oreo:
Code:
adb shell settings put system screen_brightness "value"
, my device (MZD) doesn't allow less than 3% (0/255) and this way I set to 0.
29th June 2020, 05:06 AM |#45123  
Quote:
Originally Posted by SubwayChamp

I think that the wide-system brightness values are set in system itself (no kernel nor bootloader related), in Android 10 Google changed some things in the API like where the props are placed; the directory was changed apparently and the adb commands might change too.

It's up every OEM to set a minimal to be accessed to the final user not a restriction from Google itself like the user did think.

May I'm wrong but probably since newer Android versions, it seems that now we need to root the device in order to change that since probably it's not enough with write_secure_settings permissions otherwise an app without root should do it with the interaction of the user and I don't know of any that do that by now (in a quick search)

I didn't try this command on Android 10 since I'm currently on oreo:

Code:
adb shell settings put system screen_brightness "value"
, my device (MZD) doesn't allow less than 3% (0/255) and this way I set to 0.

Running the

adb shell ls

command via adb shell would be a good start, from there, chase through the directories/folders/files until the culprit is found and edited.
@Partha Dip, are you reading this?



Sent from my SM-S767VL using Tapatalk
29th June 2020, 06:20 AM |#45124  
Quote:
Originally Posted by Droidriven

Do you think might be some set prop commands might work? Seems like they should have some kind of .prop, config, .xml or some kind of manifest they can edit. There is some kind of file/files somewhere they haven't discovered that is setting the minimum to 10 that needs to be edited. I don't think it should be necessary to edit anything in the bootloader itself, should it? It shouldn't be necessary do anything at the compiling level, should it. Unlocked bootloader, root binaries/permissions, dm-verity, and permissive kernel/mode should be enough to modify whatever they want. There is probably something I'm not seeing in their issue that I'm missing that probably should be ridiculously obvious but isn't from my perspective, lol.


Quote:
Originally Posted by SubwayChamp

I think that the wide-system brightness values are set in system itself (no kernel nor bootloader related), in Android 10 Google changed some things in the API like where the props are placed; the directory was changed apparently and the adb commands might change too.
It's up every OEM to set a minimal to be accessed to the final user not a restriction from Google itself like the user did think.
May I'm wrong but probably since newer Android versions, it seems that now we need to root the device in order to change that since probably it's not enough with write_secure_settings permissions otherwise an app without root should do it with the interaction of the user and I don't know of any that do that by now (in a quick search)
I didn't try this command on Android 10 since I'm currently on oreo: , my device (MZD) doesn't allow less than 3% (0/255) and this way I set to 0.

If you guys are talking about brightness levels or automatic brightness, they are set in the framework-res.apk. however you have to go around the back door in order to get them to work. Since most OEMs preset the values themselves, they are done in an overlay before the ROM is built. so you have to use apktool to decompile the framework APK, and locate the array file in res/values. if you look up the source code you can see some examples for other devices on what they set for automatic brightness and you can tweak those settings based on your likings. There are other things you can use like LUX auto brightness, and gravity box also has settings for auto brightness. but if you're not careful with those types of applications making your screen too bright or too dark will make it seem like your screen has died or your device is turned off when it actually isn't. so far as I know there are no brightness settings in the colonel for most devices at least based on my experience.

PS. I can decompile, edit and recompile most framework on most of the devices I own with no problem.the auto-brightness configurations was one of my specialties for several devices that appear to not have any auto brightness controls, but there is ambient lighting which can be used for the same thing. However with all of this being said so far as I know the only way 2 modify permanently, the brightness settings a through the framework-res.
The Following User Says Thank You to DragonFire1024 For This Useful Post: [ View ] Gift DragonFire1024 Ad-Free
29th June 2020, 06:23 AM |#45125  
Quote:
Originally Posted by DragonFire1024

If you guys are talking about brightness levels or automatic brightness, they are set in the framework-res.apk. however you have to go around the back door in order to get them to work. Since most OEMs preset the values themselves, they are done in an overlay before the ROM is built. so you have to use apktool to decompile the framework APK, and locate the array file in res/values. if you look up the source code you can see some examples for other devices on what they set for automatic brightness and you can tweak those settings based on your likings. There are other things you can use like LUX auto brightness, and gravity box also has settings for auto brightness. but if you're not careful with those types of applications making your screen too bright or too dark will make it seem like your screen has died or your device is turned off when it actually isn't. so far as I know there are no brightness settings in the colonel for most devices at least based on my experience.

I don't think the member that is trying to do this is rooted.

Sent from my SM-S767VL using Tapatalk
29th June 2020, 09:55 AM |#45126  
Quote:
Originally Posted by Droidriven

I don't think the member that is trying to do this is rooted.

Then that would be a tough one. There are ways the sort of get around it. Trying to use lighter backgrounds lighter icons and so on I know that sounds cheesy and dumb but without Root there is not much more you can do and in fact I think a lot of those LUX apps require root access as well.
29th June 2020, 05:57 PM |#45127  
SubwayChamp's Avatar
Senior Member
Thanks Meter: 911
 
More
Quote:
Originally Posted by Droidriven

I don't think the member that is trying to do this is rooted.

Sent from my SM-S767VL using Tapatalk

I guess the user is rooted so referred that even in Orange Fox recovery the minimum brightness can't be set lower than 10. In this case with the app that I provided might do the work for they.

Quote:
Originally Posted by DragonFire1024

Then that would be a tough one. There are ways the sort of get around it. Trying to use lighter backgrounds lighter icons and so on I know that sounds cheesy and dumb but without Root there is not much more you can do and in fact I think a lot of those LUX apps require root access as well.

Thanks for the info, specially interesting the part of provide automatic brightness to devices that doesn't have it.
This is what I thought first; that without root can't be done as now but part of the discussion was that specially since Android 10 things changed so before there were some commands to achieve it cause the user referred that those commands didn't work anymore on Android 10, I didn't further needed but an app theoretically could do it with the interaction of the user granting write_permissions through adb in the same way that the order of a nav bar can be inverted through an app although they're different things.
1st July 2020, 01:26 AM |#45128  
Quote:
Originally Posted by Droidriven

Status check, any progress?

Looks like more work to do at least until I check the latest build tomorrow. But I placed/replaced and edited the files I thought I would need, and added to BoardConfig.mk USE_CAMERA_STUB := true. That last part should have directed the process to build the software camera from the files I placed and edited while creating a 'dummy' platform camera to fill the void. Now assuming I had done everything correctly the module should have built. So far I've got nothing.

Edit: I decided to add to the booted tablet a couple of library files from another device that also has SecCamera. I rebooted the recovery wiped all the normal cache and dalvik, and for about a minute or two after rebooting the camera icon did appear in the app drawer and it was the only time I was able to get it to appear. However when I click on the icon it kept telling me "application not installed" before disappeared and I haven't been able to get it to reappear since.
1st July 2020, 04:06 PM |#45129  
Quote:
Originally Posted by Droidriven

Status check, any progress?

Alright I think I found the source of the issue. And I was again was looking in the wrong spot. It does appear, the issue lies within the kernel. I will post some screenshots later on but I wanted to give you an update before I forgot about anyting. So within the kernel you are able to choose between the V4L platform camera (I am assuming this is the unknown title camera likely SecCamera) and Exynos Camera Interface (ExynoxCameraHAL2 and 1.0 [camera 2.0 and camera 1.0). Here is where the problem begins. You cannot unselect the exynos camera therefore you also cannot set the platform camera while exynos camera is set. At least you cannot make that configuration while manually configuring the kernel using menuconfig. The option just is not there. Then when you select the option to Bill both cameras the build process errors out. Now here's where I think the edit to the kernel came in early on during KitKat, when I posted the link to the email discussion within the Linux kernel community. The only such piece of evidence I have found were they were able to get the camera to work. They were able to manually configure the kernel .config file to manually delete or switch the values to turn on the software camera (camera 2.0). Now I'm going to have to go back and look at the kernel source. Before I was looking at the wrong version and assuming that the settings were same in both the kernel for 6.0 and the one for 7.0 and it appears that is not the case at all and it's quite a significant difference. Time to go into the .config and take a look around.

Edit: here is where lineage and aosp won't work. If I use menuconfig to select any options, i can't build inline with the ROM or it forces me to do a make mrproper and a make clean. So would I even be able to edit the .config myself or will I get yelled at again?

Sent from my Samsung Nexus 10 using XDA Labs
The Following User Says Thank You to DragonFire1024 For This Useful Post: [ View ] Gift DragonFire1024 Ad-Free
2nd July 2020, 07:25 AM |#45130  
Quote:
Originally Posted by DragonFire1024

Alright I think I found the source of the issue. And I was again was looking in the wrong spot. It does appear, the issue lies within the kernel. I will post some screenshots later on but I wanted to give you an update before I forgot about anyting. So within the kernel you are able to choose between the V4L platform camera (I am assuming this is the unknown title camera likely SecCamera) and Exynos Camera Interface (ExynoxCameraHAL2 and 1.0 [camera 2.0 and camera 1.0). Here is where the problem begins. You cannot unselect the exynos camera therefore you also cannot set the platform camera while exynos camera is set. At least you cannot make that configuration while manually configuring the kernel using menuconfig. The option just is not there. Then when you select the option to Bill both cameras the build process errors out. Now here's where I think the edit to the kernel came in early on during KitKat, when I posted the link to the email discussion within the Linux kernel community. The only such piece of evidence I have found were they were able to get the camera to work. They were able to manually configure the kernel .config file to manually delete or switch the values to turn on the software camera (camera 2.0). Now I'm going to have to go back and look at the kernel source. Before I was looking at the wrong version and assuming that the settings were same in both the kernel for 6.0 and the one for 7.0 and it appears that is not the case at all and it's quite a significant difference. Time to go into the .config and take a look around.

Edit: here is where lineage and aosp won't work. If I use menuconfig to select any options, i can't build inline with the ROM or it forces me to do a make mrproper and a make clean. So would I even be able to edit the .config myself or will I get yelled at again?

Sent from my Samsung Nexus 10 using XDA Labs

It seems you need to find some decent kernel developers on Github and take a look through some repositories/commits/edits for similar devices and/or at least similar situations where configs and replacements were required at that level.


It seems you need a "shim" like discussed in the link that I posted. A shim that takes effect when the call is issued to start the preconfigured action and replaces the call/action with your preferred response instead of the preconfigured call/action. Something that you can insert to make it ignore its "normal" call/action process for camera and start/load your "preferred" call/action process for camera. Something that tricks it into thinking that it's normal call/action is what happens while at the same time making it do what you actually want it to do as if its preconfigured call/action was never interrupted in the first place.

A perspective of trying to find a way to get the desired intent "after the fact" instead of "before the fact". Instead of trying to "beat it to the punch", try to direct the punch where you want it to go after the punch has been thrown.

Just hypothesizing, not that it's actually do-able.



Sent from my SM-S767VL using Tapatalk
The Following User Says Thank You to Droidriven For This Useful Post: [ View ] Gift Droidriven Ad-Free
3rd July 2020, 11:57 AM |#45131  
Quote:
Originally Posted by Droidriven

It seems you need to find some decent kernel developers on Github and take a look through some repositories/commits/edits for similar devices and/or at least similar situations where configs and replacements were required at that level.


It seems you need a "shim" like discussed in the link that I posted. A shim that takes effect when the call is issued to start the preconfigured action and replaces the call/action with your preferred response instead of the preconfigured call/action. Something that you can insert to make it ignore its "normal" call/action process for camera and start/load your "preferred" call/action process for camera. Something that tricks it into thinking that it's normal call/action is what happens while at the same time making it do what you actually want it to do as if its preconfigured call/action was never interrupted in the first place.

A perspective of trying to find a way to get the desired intent "after the fact" instead of "before the fact". Instead of trying to "beat it to the punch", try to direct the punch where you want it to go after the punch has been thrown.

Just hypothesizing, not that it's actually do-able.

Well I've been able to see that any of the configurations I added to the defconfig, from the link I posted earlier to the email, did indeed appear in menuconfig. I can see all of the options and select ones that aren't pre-configured. But still no luck. There are a lot of options for Samsung camera though. Some are and aren't selected. It appears the camera drivers are for 's3c' (I'm going to assume sec here) and everything related is just 'samsung'. The kernel build and runs, even though (I think) the platform camera is still there (probably why the warning "can't connect to camera" appears) and probably causes the device to think the camera is being used (from what I understand generally that warning pops up when the camera is being used and can't connect to the device through its stock application). I was even able to build the kernel inline with a ROM build, but I didn't flash the ROM, just the boot.img. so I guess the next step aside from your hypothesis, is to freely install everything again and see if that makes a difference. A second possibility is not all the configurations are set properly yet.

Sent from my Samsung Nexus 10 using XDA Labs
The Following User Says Thank You to DragonFire1024 For This Useful Post: [ View ] Gift DragonFire1024 Ad-Free
Post Reply Subscribe to Thread

Tags
ask any question, beginner, confused, guidance, help needed, help thread, lost, newbie, noob, questions and answers

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes