Related
So I have been playing with AOSP. I'm interested in toggling the CRT / electron beam screen off animation. After some research, I thought that I could do this in config.xml which gets compiled into framework-res.apk (location in source: /frameworks/base/core/res/values/config.xml).
This is what is is by default:
Code:
<!-- If this is true, the screen will fade off. -->
<bool name="config_animateScreenLights">true</bool>
I've compiled and flashed it with both true and false and didn't notice any changes in the screen off animation.
I found hints elsewhere that the CRT / electron beam animation was controlled by PowerManagerService.java which gets compiled as a part of services.jar, I believe. In /frameworks/base/services/java/com/android/server/PowerManagerService.java, I noticed a few lines:
Code:
175:
// animate screen lights in PowerManager (as opposed to SurfaceFlinger)
boolean mAnimateScreenLights = true;
634:
mAnimateScreenLights = resources.getBoolean(
com.android.internal.R.bool.config_animateScreenLights);
2282:
if (turningOff && !mHeadless && !mAnimateScreenLights) {
int mode = mScreenOffReason == OFF_BECAUSE_OF_PROX_SENSOR
? 0 : mAnimationSetting;
if (mDebugLightAnimation) {
Slog.v(TAG, "Doing power-off anim, mode=" + mode);
}
mScreenBrightnessHandler.obtainMessage(ANIMATE_POWER_OFF, mode, 0)
.sendToTarget();
}
So it seems like it is set to true by default, but it definitely seems to call the value of config_animateScreenLights. However, the line 2282 code seems to be turning off due to proxy sensor, so I don't know if it applies when just timing out or pressing the power button.
I'm fairly a noob and java (I code in MatLab), so any hints or guesstimations would be appreciated.
ok, so the code I was looking at above has nothing to do with the electron beam animation, I think. I don't know what it does. But at least in 4.1.1_r6.1, the electron beam animation is in SurfaceFlinger.cpp (frameworks/native/surfaces). In later iterations of android, it will be in PowerManagerService.java.
I am pretty incompetent when it comes to java and c++, but by commenting out lines 1886-2056 in SurfaceFlinger.cpp I was able to stop the electron beam animation.. basically making the function:"status_t SurfaceFlinger::electronBeamOffAnimationImplLocked()" --- is it actually a function??? --- simply "return NO_ERROR;" without all the animation code in between.
This is probably one of the sloppiest ways to achieve this end...
I tried simply putting "status_t result = PERMISSION_DENIED;" like it is in "status_t SurfaceFlinger::electronBeamOnAnimationImplLocked(), since there is no electron beam on animation by default (and had to remove status_t from line 1894, but that didn't seem to do anything. I really have no idea what the syntax means though...
I thought we could use an organized thread for focusing on getting the camera to work on 4.2-based ROMs for the Galaxy Player 5. Right now, there are three iterations of CM10.1 threads, and discussion is also going on in other ROM threads. I'm basically putting this here so we can all talk about it in one place and not have to dig every time we need to find a piece of information that was previously mentioned.
I'll update the OP as more information surfaces.
Things that we already know
http://forum.xda-developers.com/attachment.php?attachmentid=1988153&d=1369421491 this fixes camcorder for the rear camera. Source
Speculation
The image sizes could be off because our CM10.1 was ported from the other Galaxy S devices. Source
The Galaxy Stellar also uses a 3.2MP camera and has native 4.0.4. This could possibly be of use.
Other things that could be potentially useful
https://sites.google.com/site/jaiprakashgogi/professional this is the website for the person who develops the driver for the s5K5CCGX sensor. We could try contacting him to see if he could help us out.
The developer profile says that he developed for Qualcomm Snapdragon powered devices so the drivers are likely to be incompatible with our Exynos SoC. However, if our front facing camera is 1.3 MP, I think we might be able to use the drivers from the Galaxy Tab
Supermaster34 said:
The developer profile says that he developed for Qualcomm Snapdragon powered devices so the drivers are likely to be incompatible with our Exynos SoC. However, if our front facing camera is 1.3 MP, I think we might be able to use the drivers from the Galaxy Tab
Click to expand...
Click to collapse
Nope, our Front-Facing is a measly 0.3MP VGA cam like the other Galaxy S phones.
halomademeapc said:
Nope, our Front-Facing is a measly 0.3MP VGA cam like the other Galaxy S phones.
Click to expand...
Click to collapse
Well that put a spanner in my plan. I guess the next step from here is to work out why the FFC saves pictures but the RFC doesn't. There must be a difference in the method they use to store the image, but we need to locate where the code specifies the method of saving the image
Supermaster34 said:
Well that put a spanner in my plan. I guess the next step from here is to work out why the FFC saves pictures but the RFC doesn't. There must be a difference in the method they use to store the image, but we need to locate where the code specifies the method of saving the image
Click to expand...
Click to collapse
In cm10 the saving of grey images was fixed by changing the postview sizes in the header[1]. There are also other random places values are hardcoded into the HAL[2]. One interesting thing is that we are using the HAL's from two different sources in jellybean, so they have different problems: crespo on cm10 and p5 on cm10.1 (EDIT: I see JackpotClavin switched to crespo... This is all very confusing), so possibly compare/combine the two to find what is causing each problem.
For video recording (media_profiles.xml) we need to figure out what the actual numbers are for our device, and not just take them from somewhere else. Plus, they have to align with the HAL. The same applies to OpenMAX codec libraries. Last, don't forget that at some point we will need to get the torch working, too.
EDIT: I saw the discussion on the other thread and decided to move it here
Supermaster34 said:
I don't think changing the resolution will fix it. I just tried taking a photo with the resolution set to 1.3 MP, but it didn't work. I think the issue is when the image is being saved as the width and height both come up as 0 and even when the flash is forced on, the image details say no flash. If we look at how the front facing camera saves the image, we could compare it with how the rear facing camera is set to save the image and modify it to match. I'm not entirely sure that this would work, but it might be worth a try
Click to expand...
Click to collapse
Does any EXIF data save? I don't think it does, so that's another item on our todo list (and saving GPS information in the pictures). Our FFC is the 3DFX, which is the exact same as crespo, so it should work perfectly with no modifications. Therefore, any issues are caused by something else, like media_profiles.xml. This is what happens when I talk without checking... I tried the FFC, and everything works perfectly AFAIK: EXIF and location data save (although it was using network location, it should work exactly the same with GPS). So no worries or breakage there.
android1234567 said:
Yeah I just looked at the resolutions and some of them are the same as before. I also noticed that some ISOs that aren't supported by our sensor were added in, so I put my hand in front of the camera to lower the ISO and lo and behold it actually took a picture and made the capture sound instead of hang on taking the picture like it usually does. But after that it just hung and didn't save the picture, so you're right that the camera isn't saving the image correctly.
Click to expand...
Click to collapse
Do we have a definitive list of which ISO's our camera does support? I would assume the only way to know is from a different camera HAL, but the only other device with the S5K5CCGX uses blobs. I guess we could look in the stock app, or use trial and error if there was no other list.
Supermaster34 said:
At least we're making some progress. I think we have the same camera hardware as the Galaxy Tab and I believe it has CM10.1 so it might be worth having a look at their source or just trying to use their drivers as I think they also have the Exynos 3 single SoC
Click to expand...
Click to collapse
zaclimon said:
Depends which gtab you're talking about. The Gtab P1 (original) uses the sony isx005 which we have. I think the galaxy tab 10.1 do have your sensor, it would need to be checked further.
Your back cam is s5k5ccgx
Your front cam is s5ka3dfx
Hope it helps.
EDIT: the galaxy tab 10.1 do use the same sensor as you, you can check there: https://github.com/CyanogenMod/android_kernel_samsung_p4/blob/cm-10.1/arch/arm/configs/pershoot_samsung_p4-jb_defconfig#L1939
EDIT2: Hmm the galaxy tab 10.1 do use tegra chipset so maybe it's not a good choice, but you can look into the p1 drivers and take a look of their s5k5ccgx drivers here: https://github.com/CyanogenMod/android_kernel_samsung_p1/blob/cm-10.1/drivers/media/video/s5k5ccgx.c
Click to expand...
Click to collapse
Yes, they use Tegra blobs. They look self-contained, so I was thinking they might be possibly portable; say, take their blobs and their kernel driver and see if those together work on our camera. What's interesting in looking at all of the different kernel drivers is the different firmwares for different devices, and how some say different megapixel ratings than others, almost as if there were different cameras with the same model, or someone at Samsung was doing a lot of copypasting.
android1234567 said:
Think I found a solution: https://github.com/humberos/android...mmit/5bab5c8c8797f96855b777e6c2328d341187014e
Click to expand...
Click to collapse
Supermaster34 said:
This is the code across a few devices:
Nexus S + 5.0 atm - 4.2
Code:
int SecCamera::interleaveDataSize = 5242880;
GTab - 4.2
Code:
int SecCamera::interleaveDataSize = 0x33F000;
Galaxy S - GB I think
Code:
int SecCamera::interleaveDataSize = 4261248;
I have no idea what these numbers mean, but could 0x33F000 be some sort of memory address location?
Also why is there an 8 thanks per day limit?!
Click to expand...
Click to collapse
Well, 0x33F000 is 3403776 in decimal (for comparison). It is the size of a memory buffer, and its value has to do with a few things: Image resolution, image format (i.e. extra space for metadata or less space because of hardware JPEG compression), and pixel format (i.e. bits per pixel, like YUV, RGB888, RGB565, etc.). So at 2048 by 1536 pixels, that 3MP is exactly 3145728 pixels; I don't see where that number comes from.
android1234567 said:
It'll work! On the Galaxy Tab the number was previously 4261248 then it was changed to 0x33F000! The number is universal across devices as long as they have the same camera Nexus S has a different camera so the number is different.
Click to expand...
Click to collapse
It should be linear relative to image size, but it doesn't seem to be, which is confusing.
android1234567 said:
I'll do that now . I have all the CM10.1 source and device tree on my laptop because I need it to build kernels. I'll also clean up some ISOs and resolutions while I'm at it. If it works then we can merge the video changes that got the camcorder working and have fully functional CM10.1
Click to expand...
Click to collapse
A tip to save lots of disk space and time by building only what you need:
Code:
mmm -B device/samsung/venturi_usa/libcamera
android1234567 said:
I'm going to combine the Galaxy Tab HAL with the current HAL we're using, retaining the FFC code we have right now.
Sent from my HTC Sensation 4G using xda app-developers app
Click to expand...
Click to collapse
Sounds like a good idea. I will see where I can get starting on Tuesday or so.
android1234567 said:
I'm trying to build with my camera changes but I get this error after a little while:
Code:
No rule to make target `/home/sultan/cm10.1/out/target/product/venturi_usa/obj/SHARED_LIBRARIES/libs3cjpeg_intermediates/export_includes'
Anyone know how to fix it?
Click to expand...
Click to collapse
You need the hardware/samsung repo:
Code:
<project name="CyanogenMod/android_hardware_samsung" path="hardware/samsung" remote="github" />
If you already have it, try running
Code:
mmm hardware/samsung/exynos3/s5pc110/libs3cjpeg
P.S. We can't keep the discussion in one place if we aren't keeping it in one place...
[1] https://github.com/Mevordel/android...mmit/1cad68704bcd856638357e0b18118b46c8f198ba
[2] https://github.com/Mevordel/android...mmit/e6f4507fac8768d9a62c54ee375cdfd584aad889
Mevordel said:
In cm10 the saving of grey images was fixed by changing the postview sizes in the header. One interesting thing is that we are using the HAL's from two different sources in jellybean, so they have different problems: crespo on cm10 and p5 on cm10.1, so possibly compare/combine the two to find what is causing each problem.
For video recording (media_profiles.xml) we need to figure out what the actual numbers are for our device, and not just take them from somewhere else. The same applies to OpenMAX codec libraries.
Click to expand...
Click to collapse
A fix has already been found for video recording in CM10.1 and it changes the media profiles file, so we don't have to worry about that
We already have our fix for the camera without even touching the libcamera (for the 3.0 kernel). Here's the commit if ever you want to check it:
https://github.com/bbelos/android_kernel_samsung_aries/commit/ab11000777e4363460ccaebe3221a721252c4f56
@Mevordel
Not going to quote your entire post because that would be ridiculous, but thanks x1000 especially for those 2 commits
it's very reassuring knowing that we have another person helping who has done this before
zaclimon said:
We already have our fix for the camera without even touching the libcamera (for the 3.0 kernel). Here's the commit if ever you want to check it:
https://github.com/bbelos/android_kernel_samsung_aries/commit/ab11000777e4363460ccaebe3221a721252c4f56
Click to expand...
Click to collapse
This pretty much completely confuses me... Is CONFIG_SAMSUNG_GALAXYS defined for your device? A lot of what was added looks to be support for the P1. Is that because you took some of the code from the P1?
android1234567 said:
@Mevordel
Not going to quote your entire post because that would be ridiculous, but thanks x1000 especially for those 2 commits
it's very reassuring knowing that we have another person helping who has done this before
Click to expand...
Click to collapse
Thank you. I still have no idea what much of this does, but I will spend some time this month looking into it.
Final post for the day:
I decided to look into the kernel-side driver for some explanation for a few of these magic numbers, and here's what I found staring us in the face this whole time (drivers/media/video/s5k5ccgx.c):
Code:
/* Default resolution & pixelformat. plz ref s5k5ccgx_platform.h */
#define FORMAT_FLAGS_COMPRESSED 0x3
#define SENSOR_JPEG_SNAPSHOT_MEMSIZE 0x33F000 //3403776 //2216 * 1536 384000 33F000
#define POLL_TIME_MS 10
#define DEFAULT_RES WVGA /* Index of resoultion */
#define DEFAUT_FPS_INDEX S5K5CCGX_15FPS
#define DEFUALT_MCLK 24000000 /* 24MHz default */
#define DEFAULT_FMT V4L2_PIX_FMT_UYVY /* YUV422 */
#define INNER_WINDOW_WIDTH 143
#define INNER_WINDOW_HEIGHT 143
#define OUTER_WINDOW_WIDTH 320
#define OUTER_WINDOW_HEIGHT 266
/*
* Specification
* Parallel : ITU-R. 656/601 YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Serial : MIPI CSI2 (single lane) YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Resolution : 1280 (H) x 1024 (V)
* Image control : Brightness, Contrast, Saturation, Sharpness, Glamour
* Effect : Mono, Negative, Sepia, Aqua, Sketch
* FPS : 15fps [user=366900]@full[/user] resolution, 30fps [user=355664]@vga[/user], 24fps [user=3621271]@720p[/user]
* Max. pixel clock frequency : 48MHz(upto)
* Internal PLL (6MHz to 27MHz input frequency)
*/
So the 0x33F000 is the correct value, and the postview defines in SecCamera.h (not to mention the rest of the values) need to be updated with those here.
The only problem is that some of the information is wrong. The resolution stated in the comment is 1.3MP, the beginning of the file says 2.0MP, but we know (and the resolution list later in the file confirms) that it is a 3.0MP sensor. Meh.
Mevordel said:
Final post for the day:
I decided to look into the kernel-side driver for some explanation for a few of these magic numbers, and here's what I found staring us in the face this whole time (drivers/media/video/s5k5ccgx.c):
Code:
/* Default resolution & pixelformat. plz ref s5k5ccgx_platform.h */
#define FORMAT_FLAGS_COMPRESSED 0x3
#define SENSOR_JPEG_SNAPSHOT_MEMSIZE 0x33F000 //3403776 //2216 * 1536 384000 33F000
#define POLL_TIME_MS 10
#define DEFAULT_RES WVGA /* Index of resoultion */
#define DEFAUT_FPS_INDEX S5K5CCGX_15FPS
#define DEFUALT_MCLK 24000000 /* 24MHz default */
#define DEFAULT_FMT V4L2_PIX_FMT_UYVY /* YUV422 */
#define INNER_WINDOW_WIDTH 143
#define INNER_WINDOW_HEIGHT 143
#define OUTER_WINDOW_WIDTH 320
#define OUTER_WINDOW_HEIGHT 266
/*
* Specification
* Parallel : ITU-R. 656/601 YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Serial : MIPI CSI2 (single lane) YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Resolution : 1280 (H) x 1024 (V)
* Image control : Brightness, Contrast, Saturation, Sharpness, Glamour
* Effect : Mono, Negative, Sepia, Aqua, Sketch
* FPS : 15fps [user=366900]@full[/user] resolution, 30fps [user=355664]@vga[/user], 24fps [user=3621271]@720p[/user]
* Max. pixel clock frequency : 48MHz(upto)
* Internal PLL (6MHz to 27MHz input frequency)
*/
So the 0x33F000 is the correct value, and the postview defines in SecCamera.h (not to mention the rest of the values) need to be updated with those here.
The only problem is that some of the information is wrong. The resolution stated in the comment is 1.3MP, the beginning of the file says 2.0MP, but we know (and the resolution list later in the file confirms) that it is a 3.0MP sensor. Meh.
Click to expand...
Click to collapse
I'm going to do that now
No progress @Mevordel the camera just force closes with the header changes. I think we might need to mess around with the camera driver in the kernel
Or maybe I need to allocate more memory to the camera
I am hell sure that it is not connected to the memory, as aries an crespo with 5mpx use same memory amount as we have set
Wysyłane z mojego Nexus S za pomocą Tapatalk 2
Mevordel said:
This pretty much completely confuses me... Is CONFIG_SAMSUNG_GALAXYS defined for your device? A lot of what was added looks to be support for the P1. Is that because you took some of the code from the P1?
Click to expand...
Click to collapse
What I did was to take the 3.0 p1 drivers, then modify the ifdef to comply with our devices. (config_samsung_galaxys to replace mach_aries and config_samsung_ypg1 to replace config_mach_p1) with the 2.6 drivers , bbelos had completely copied the p1 which is why we have the camera working on it. We're only doing the same thing but with some ugly manners of implementing it. (it's implementation will be different with the cm10.1 kernel.). This is how we got it working.
Also wouldn't be more easier to take your camera drivers from p1?
Envoyé depuis mon Nexus 7 avec Tapatalk
I had always thought that the issue was with the camera.aries library and not the kernel. I flashed back to my old CM9 build from a year or so ago (with the 2.6.35.7 kernel, that worked with Gingerbread and its camera) and used our camera library for 4.2.2 and I got the exact same errors with the rear camera, but the front worked fine as it did with 4.2.2
Sent from my Galaxy Nexus using xda app-developers app
JackpotClavin said:
I had always thought that the issue was with the camera.aries library and not the kernel. I flashed back to my old CM9 build from a year or so ago (with the 2.6.35.7 kernel, that worked with Gingerbread and its camera) and used our camera library for 4.2.2 and I got the exact same errors with the rear camera, but the front worked fine as it did with 4.2.2
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Hmm to get mostly your camera working, you need the camera HAL drivers to fit with the FIMC kernel drivers. So if you want to use the P1 camera HAL, you will need to update your fimc drivers in order to get it working. In your case you would only need to add ifdef CONFIG_MACH_VENTURI.
We can take pictures with Fast Burst Camera (but the quality is poor)...
flouflou said:
We can take pictures with Fast Burst Camera (but the quality is poor)...
Click to expand...
Click to collapse
Fastburst just takes a screenshot; it doesn't take actual photos
android1234567 said:
Fastburst just takes a screenshot; it doesn't take actual photos
Click to expand...
Click to collapse
I know but it's still practice...
It seems that it might be worthwhile to take a look at the code that produces the preview images... I mean that technically is our device producing images from the BFC right?
Sent from my SAMSUNG-SGH-I577 using xda app-developers app
I would like to develop and app, which has the main functionality to show a 2D chart. There are others and settings, but this is the main.
Existing similar applications aren't using technologies as how it should and they are releasing apps with to few features or they are draining battery like crazy. This I would like to improve it.
This is for web / desktop
View attachment 2397770
Here are a few sentences from my experience, please correct me if I am wrong!
Many-many of implementations are using SDK and 2D graphics. They draw the whole screen every time. Just sere how your battery drained in 1-2 hours! - some really bad implementation they can drain in 3 minutes, I will show later. One exception is: Metatrader 4: it use NDK and OpenGL, Hey pay me, because I am advertising you!
I think the SDK code (.class files) it need to e compiled at runtime execution by virtual machine, which takes CPU usage.
NDK is compiled only one => will use less CPU => will drain less batter as the SDK version.
If this is correct, than it should move more code to NDK if is possible. Not sure about JNI calls overhead!
NDK huuuuge advantage: it will allow to use the phone max available memory ( 1.5GB was last time) instead of SDK max allowed value: 256MB ( in my case, but some devices allow only 24Mb for SDK apps)
If you don't touch this chart than nothing changes, if you set the "Live" option, than the last "candle" will change. The candles are those Red & Green rectangles with the line in upper side and down side with meaning of the open, high, low, close prices. - it is related to business logic, but this special bars can have those 2 lines, which are important. The border of the 1pixel black around the red-green rectangles are for visual effects only. To save battery can be omitted.
(The background text and logos are just for advertisements, nobody cares, not really needed for the user for his actions)
As you can see there is a toolbar, and there are maybe other components too, but when the user want to see highest amount of data than will rotate to landscape and there should be given a Full Screen (in portrait not by default)
I have started the development with a component for rendering with OpenGL ES 2.0.
The UI is in SDK , the renderer there is called, but the method implementation calls the native methods via JNI. The business logic, rendering implementation are all in NDK, which is a native shared library.
Not sure why I started with OpenGL, to have some cool effects, who want to drain his battery faster? or I tough if is faster than will consume less battery? - maybe faster drains, but more: 100 mA from GPU for 0.01 seconds rendering is the same as 10 mA for 0.1 rendering at CPU.
Here I am not sure if I am saving energy. Tell me your opinion!
So I have started learning OpenGL ES 2.0 and all what I saw in tutorials it was triangle triangle triangle, but in this chart there is no triangle, but rectangle, or rectangle+lines or just lines with set width or many triangles?
Here is a cool candle, I would like to see this, but I know the gradients will burn battery.
{
"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"
}
Here is a bit magnified and you can see how I am thinking:
but can't decide. Because I haven't enough experience, don't know the benchmark results. I would like to see a tear down and expected results:
GL_Lines + glLineWidth
GL_triangles
GL_triangle_strip
As the first option with GL_lines:
A candle would be 1x small line from the Low and High price drawn first. Lets say with 5 pixel width to have room for gradient too, if needed. In worse case only 1 pixel, as how they are using others now.
The candle body: the red/green rectangle with has the info of Open/Close price can be another GL_Lines with 50 pixel width - for example.
Will be gradient or not that would depends on user settings. Not sure how is possible to draw black 1-2 pixel of border for candle body in this case - if the user has that settings.
Seconds option with triangles:
2x triangle can make a square.
There is a square as the small line and there is another one the larger square : the candle body.
The triangle strip case:
if only one GL_triangle_strip:
bottomline: 4 vertices
body other 4
upper line 4 vertices
or small line 4x vertices
+
other 4x vertices , so 2x GL_triangle_strip
I made this:
The first thing it was:
Code:
setRenderMode(GLSurfaceView.RENDERMODE_WHEN_DIRTY)
It is a rectangle with 2x triangle and a line with width.
The line has less vertices of course, but in this chart is expected to have 50- 200 bars maximum. Minimum 10-20.
What is needed is that cross at mouse location: that dashed line and the numbers ( price ) on the right and some other texts in bottom. X, Y coordinates in text.
Please post your experience, benchmarks, opinion.
Hi matheszabi,
ok, your question was rather compheresive . So right way to find solution is rather complicated too.
I woudn't choose solution according to differences between JDK / NDK to same function calls of OpenGL ES 2.0
According to my experience, performance (and power consumption) is almost the same.
GLOBAL aproach: I suggest
1) you create your application in Java - use JDK versions - creating native function for just few draw calls is, imho, hard compared what you get
2) if your application is NativeActivity
- use direct calls - be prepared for differences between devices, proper creation of surface, .... but it's faster
- subclass Native Activity and use JAVA as well
3) not using OpenGL ES directly at all - i suggest trying layout and buttons / images inside of it, i saw 200 control buttons on 1 screen and it ran perfectly. And layout is movable by 1 command - offset. I suppose, this is completely written in native code anyway. You just get drawing interface in JAVA.
Now, to OPENGL ES itself (JAVA or NDK)
cons:
- OPENGL is 3D interface so pixel perfect drawing is something which is not supported by itself. (note: opengl has pixel / texel center at 0.5 not at 0.0/1.0)
- you need pixel perfect draw - boxes you draw must be perfectly aligned to screen pixels - othewise you get blurry results
- you might not need texturing - thats PLUS, otherwise drawing pixel perfect opengl suraces is "pain in the ..." - viz. texel interpolation and drawing a pixel checker aligned with screen pixels is real nightmare and it differs on each device (I tried )
- pixel perfect with mipmaps - awful again
- alpha blending (when you have something which is transparent) - you will need sorting to draw it properly
- will you need font ? oh my ...
- NO EMULATOR - will need to test each device if it's working properly (not every, at least each vendor)
to consider:
writing vertex/fragment shader in a world with 3500 (number of opengles 2.0 devices according google) suitable devices/compilers/android versions ... ehm
pluses:
- you draw exactly what you want
- use of fragment shader (alhough i suggest using gradient textures instead)
- i suggest draw primitives in vertex buffers (indexed triangles or triangle strips). Not one box by one - compose all in one array and draw it by one draw call. Doubling points in strips can help you
- instancing is not supported) but there is way surpassing this (preparing buffers with)
- i don't recommend using lines with width definition - each implementation draws this differently - and it's equal to drawing lit cylinder
- in native activity loop - handling if you need redraw - it's difficult
I would try normal android GUI first
pluses:
- you get pixel perfect draw, with / without bitmaps, images, gradients ....
- i suppose its fast enough
- no sorting needed
- redraws will be invoked when something changes
- translation / clipping will be handled internally
- no need to care about device !!! that's big plus
cons:
- zoom will be problematic
- rotations as well (but i suppose you don't need them)
note to power consupmption - both OpenGL :
just swaping screen buffers 30 per sec will deplete most of devices within 2-3 hours. But of course, doing it so only when needed is doable
But I might be wrong so best way is to decide by yourself and, of course, try it and see.
If you have qustions about drawing through ES, i'll post some samples of pixel perfect draw (from my gui)
Good luck, post your decision, and if you have some results, post them too! will be very interesting.
PS.
Petr Sovis said:
Hi matheszabi,
ok, your question was rather compheresive . So right way to find solution is rather complicated too.
I woudn't choose solution according to differences between JDK / NDK to same function calls of OpenGL ES 2.0
According to my experience, performance (and power consumption) is almost the same.
GLOBAL aproach: I suggest
1) you create your application in Java - use JDK versions - creating native function for just few draw calls is, imho, hard compared what you get
2) if your application is NativeActivity
- use direct calls - be prepared for differences between devices, proper creation of surface, .... but it's faster
- subclass Native Activity and use JAVA as well
3) not using OpenGL ES directly at all - i suggest trying layout and buttons / images inside of it, i saw 200 control buttons on 1 screen and it ran perfectly. And layout is movable by 1 command - offset. I suppose, this is completely written in native code anyway. You just get drawing interface in JAVA.
Now, to OPENGL ES itself (JAVA or NDK)
cons:
- OPENGL is 3D interface so pixel perfect drawing is something which is not supported by itself. (note: opengl has pixel / texel center at 0.5 not at 0.0/1.0)
- you need pixel perfect draw - boxes you draw must be perfectly aligned to screen pixels - othewise you get blurry results
- you might not need texturing - thats PLUS, otherwise drawing pixel perfect opengl suraces is "pain in the ..." - viz. texel interpolation and drawing a pixel checker aligned with screen pixels is real nightmare and it differs on each device (I tried )
- pixel perfect with mipmaps - awful again
- alpha blending (when you have something which is transparent) - you will need sorting to draw it properly
- will you need font ? oh my ...
- NO EMULATOR - will need to test each device if it's working properly (not every, at least each vendor)
to consider:
writing vertex/fragment shader in a world with 3500 (number of opengles 2.0 devices according google) suitable devices/compilers/android versions ... ehm
pluses:
- you draw exactly what you want
- use of fragment shader (alhough i suggest using gradient textures instead)
- i suggest draw primitives in vertex buffers (indexed triangles or triangle strips). Not one box by one - compose all in one array and draw it by one draw call. Doubling points in strips can help you
- instancing is not supported) but there is way surpassing this (preparing buffers with)
- i don't recommend using lines with width definition - each implementation draws this differently - and it's equal to drawing lit cylinder
- in native activity loop - handling if you need redraw - it's difficult
I would try normal android GUI first
pluses:
- you get pixel perfect draw, with / without bitmaps, images, gradients ....
- i suppose its fast enough
- no sorting needed
- redraws will be invoked when something changes
- translation / clipping will be handled internally
- no need to care about device !!! that's big plus
cons:
- zoom will be problematic
- rotations as well (but i suppose you don't need them)
note to power consupmption - both OpenGL :
just swaping screen buffers 30 per sec will deplete most of devices within 2-3 hours. But of course, doing it so only when needed is doable
But I might be wrong so best way is to decide by yourself and, of course, try it and see.
If you have qustions about drawing through ES, i'll post some samples of pixel perfect draw (from my gui)
Good luck, post your decision, and if you have some results, post them too! will be very interesting.
PS.
Click to expand...
Click to collapse
Hello thanks for sharing your idea experience.
I have asked in other forum a similar question.
It was a response than the GPU has optimised methods so it will have less power consumption
Also he likes to draw the whole frame not only a part - I'm case of my optimisation
Also I have asked an opengl expert and he told me to use the ortho instead of perspective projection. He has right.
Now I don't have bliry results anymore but is pixel perfect!
For benchmark I made 100 candles : 100 line + 200 triangles.
I have calculated how much is the wigth and the height for the surface => how much space can have a candle and used the matrix transformations and render it.
A nice surprise the fist time it took 18 milliseconds but after that only took 5-6 millisec the. Sdk->ndk->opengl-> SDK steps.
That is very good result on MY trash device. But I think it has a trick: the ndk gives order to render to GPU and it will return. So in those 5-6 milliseconds will start to work the GPU for who knows how much....
Note: audio , video , sensor intensive projects should be developed on real devices not at emulators.
With my method the problem is starting with text drawing and leak of knowledge.
Vbo or texture... Not sure which one but if a native 2D can do it than I can me too.
Cairo as rendering 2d engine is a bit big to include in android.
I still think the ndk is the correct place. Also is isn't so easy to watch the engine code as a decompiled SDK code
Ok! you chose your path - good for you!
18/5-6 ms is just for draw (200 triangles+100 lines) ?, or whole frame time ? Can you tell me the the device you are testing your app on ?
Note: Ortho, i didn't mean to advice perspective transform, ortho is still 3d, and pixel perfect - wait for texturing/text drawing, but you'll manage!
Just few tips to font rendering:
bitmap fonts: I can't add links so google: angelcode bmfont
font bitmap creator: google: angelcode bmfont
+ sample: google: nehe 2d_texture_font
freetype implementation - it's possible to compile it with ndk - i use it and it's simple
google: freetype
and code for starters: google: nehe freetype_fonts_in_opengl
Cheers
P.
Petr Sovis said:
Ok! you chose your path - good for you!
18/5-6 ms is just for draw (200 triangles+100 lines) ?, or whole frame time ? Can you tell me the the device you are testing your app on ?
Note: Ortho, i didn't mean to advice perspective transform, ortho is still 3d, and pixel perfect - wait for texturing/text drawing, but you'll manage!
Just few tips to font rendering:
bitmap fonts: I can't add links so google: angelcode bmfont
font bitmap creator: google: angelcode bmfont
+ sample: google: nehe 2d_texture_font
freetype implementation - it's possible to compile it with ndk - i use it and it's simple
google: freetype
and code for starters: google: nehe freetype_fonts_in_opengl
Cheers
P.
Click to expand...
Click to collapse
My phone is a THL W8S. has FHD resolution
It had a mixed layout, but better I show you:
I have misscalculated the lines positions but for now doesn't matter.
The GLSurface takes a considerable amount of the screen space and that is counted.
On a Samsung Note 10" - at least 1 year old device, lower resolution, but better CPU + GPU it is a lot less this numbers.
My device is a trash (by far not for gamming), I told you:
Hi,
ok, as I understand, the time is just for drawing 200 tris + 100 lines - ok that seems a "little to much" for that.
Besides, your device is not trash at all
I don't know if I can share my examples - but scene from app I released week ago draws 50KTris per frame with some heavy shaders (normal mapping + specular ligting from 2 light sources) and draws text over it + particles + GUI (my ndk gles2.0 engine) and I suppose it will run over 30 FPS on your device (its PoverVR 540 or something) (google play: "Asteroid Hunters" by me)
So, can you post fragment of your drawing code ? maybe there something not really right ?
P
Petr Sovis said:
So, can you post fragment of your drawing code ? maybe there something not really right ?
P
Click to expand...
Click to collapse
I will post, but for me this is good enough others are drawing in 200-2000 milliseconds
The SDK part:
Code:
@Override
public void onDrawFrame(GL10 gl) {
long start = System.currentTimeMillis();
LibJNIWrapper.rendererOnDrawFrame();
long end = System.currentTimeMillis();
//Log.e("Renderer", "onDrawFrame() took: "+ (end-start)+" millisec (1e-6)");
}
The related NDK part:
Code:
void renderer_on_draw_frame() //4
{
LOGE("renderer_on_draw_frame");
//copy
static float grey;
grey += 0.01f;
if (grey > 1.0f) {
grey = 0.0f;
}
glClearColor(grey, grey, grey, 1.0f);
checkGlError("glClearColor");
glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);
checkGlError("glClear");
int i;
for (i = 0; i < CANDLES_COUNT; i++) {
//LOGE("chartengine rendering i= %d",i);
renderLine((candles[i].coloredSingleLine));
renderRectangle((candles[i].coloredSingleRectangle));
}
glFlush();
}
line rendering:
Code:
void renderLine(ColoredSingleLine* pColoredSingleLine) {
if (pColoredSingleLine == NULL) {
return;
}
//matrixTranslateM(mvpMatrix, rndX, rndY, 0);
//LOGE("###renderLine pColoredSingleLine %p\n",pColoredSingleLine);
glUseProgram(pColoredSingleLine->programColoredLine.program);
checkGlError("Line: glUseProgram");
// Enable a handle to the triangle vertices
glEnableVertexAttribArray(pColoredSingleLine->programColoredLine.a_position_location);
checkGlError("Line: glEnableVertexAttribArray");
// Prepare the triangle coordinate data
glVertexAttribPointer(pColoredSingleLine->programColoredLine.a_position_location, pColoredSingleLine->lineData.COORDS_PER_VERTEX_LINE, GL_FLOAT, GL_FALSE,
pColoredSingleLine->lineData.vertexStride, pColoredSingleLine->lineData.vertices);
checkGlError("Line: glVertexAttribPointer");
// Set color for drawing the triangles
glUniform4fv(pColoredSingleLine->programColoredLine.u_color_location, 1, pColoredSingleLine->lineData.color_rgba);
checkGlError("Line: glUniform4fv");
// Apply the projection and view transformation
glUniformMatrix4fv(pColoredSingleLine->programColoredLine.u_mvp_matrix_location, 1, GL_FALSE, pColoredSingleLine->lineData.mvpMatrix);
checkGlError("Line: glUniformMatrix4fv");
glLineWidth(pColoredSingleLine->lineData.lineWidth);
// Draw the line
glDrawArrays(GL_LINES, 0, pColoredSingleLine->lineData.vertexCount); // (GLenum mode, GLint first, GLsizei count);
checkGlError("Line: glDrawArrays"); // GL_INVALID_ENUM
//GL_INVALID_ENUM is generated if mode is not an accepted value.
//GL_INVALID_ENUM is generated if type is not GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT.
GLint error = glGetError();
if (error == GL_OUT_OF_MEMORY) {
LOGE("Out of Video memory error...congrats...is your device a stone ?");
}
// Disable vertex array
glDisableVertexAttribArray(pColoredSingleLine->programColoredLine.a_position_location);
}
and the rectangle:
Code:
void renderRectangle(ColoredSingleRectangle* pColoredSingleRectangle) {
if (pColoredSingleRectangle == NULL) {
return;
}
//matrixTranslateM(mvpMatrix, rndX, rndY, 0);
glUseProgram(pColoredSingleRectangle->programColoredRectangle.program);
checkGlError("Rectangle: glUseProgram");
// Enable a handle to the triangle vertices
glEnableVertexAttribArray(pColoredSingleRectangle->programColoredRectangle.a_position_location);
checkGlError("Rectangle: glEnableVertexAttribArray");
// Prepare the triangle coordinate data
glVertexAttribPointer(pColoredSingleRectangle->programColoredRectangle.a_position_location, pColoredSingleRectangle->rectangleData.COORDS_PER_VERTEX_RECTANGLE, GL_FLOAT, GL_FALSE,
pColoredSingleRectangle->rectangleData.vertexStride, pColoredSingleRectangle->rectangleData.vertices);
checkGlError("Rectangle: glVertexAttribPointer");
// Set color for drawing the triangles
glUniform4fv(pColoredSingleRectangle->programColoredRectangle.u_color_location, 1, pColoredSingleRectangle->rectangleData.color_rgba);
checkGlError("Rectangle: glUniform4fv");
// Apply the projection and view transformation
glUniformMatrix4fv(pColoredSingleRectangle->programColoredRectangle.u_mvp_matrix_location, 1, GL_FALSE, pColoredSingleRectangle->rectangleData.mvpMatrix);
checkGlError("Rectangle: glUniformMatrix4fv");
// Draw the square
glDrawElements(GL_TRIANGLES, NELEMS(pColoredSingleRectangle->rectangleData.drawOrder), GL_UNSIGNED_SHORT, pColoredSingleRectangle->rectangleData.drawOrder); // GL_INVALID_ENUM on Galaxy note
checkGlError("Rectangle: glDrawElements"); // GL_INVALID_ENUM
//GL_INVALID_ENUM is generated if mode is not an accepted value.
//GL_INVALID_ENUM is generated if type is not GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT.
GLint error = glGetError();
if (error == GL_OUT_OF_MEMORY) {
LOGE("Out of Video memory error...congrats...is your device a stone ?");
}
// Disable vertex array
glDisableVertexAttribArray(pColoredSingleRectangle->programColoredRectangle.a_position_location);
}
At any benchmarks my fps is bellow 12, while other devices has 30 or 50 fps. Believe me not my device has the best CPU + GPU by far:
some output from on old code:
Code:
printGLString("Version", GL_VERSION);
printGLString("Vendor", GL_VENDOR);
printGLString("Renderer", GL_RENDERER);
printGLString("Extensions", GL_EXTENSIONS);
....
void printGLString(const char *name, GLenum s) {
const char *v = (const char *) glGetString(s);
LOGE("GL %s = %s\n", name, v);
}
// ### GT-N8000 ### Galaxy note 10" - GL Renderer = Mali-400 MP
// GL_EXT_debug_marker
// GL_OES_texture_npot
// GL_OES_compressed_ETC1_RGB8_texture
// GL_OES_standard_derivatives
// GL_OES_EGL_image
// GL_OES_depth24
// GL_ARM_rgba8
// GL_ARM_mali_shader_binary
// GL_OES_depth_texture
// GL_OES_packed_depth_stencil
// GL_EXT_texture_format_BGRA8888
// GL_EXT_blend_minmax
// GL_OES_EGL_image_external
// GL_OES_EGL_sync
// GL_OES_rgb8_rgba8
// GL_EXT_multisampled_render_to_texture
// GL_EXT_discard_framebuffer
// ### THL V8S - GL Renderer = PowerVR SGX 544MP
// GL_EXT_debug_marker
// GL_OES_rgb8_rgba8
// GL_OES_depth24
// GL_OES_vertex_half_float
// GL_OES_texture_float
// GL_OES_texture_half_float
// GL_OES_element_index_uint
// GL_OES_mapbuffer
// GL_OES_fragment_precision_high
// GL_OES_compressed_ETC1_RGB8_texture
// GL_OES_EGL_image
// GL_OES_EGL_image_external
// GL_OES_required_internalformat
// GL_OES_depth_texture
// GL_OES_get_program_binary
// GL_OES_packed_depth_stencil
// GL_OES_standard_derivatives
// GL_OES_vertex_array_object
// GL_OES_egl_sync
// GL_OES_texture_npot
// GL_EXT_multi_draw_arrays
// GL_EXT_texture_format_BGRA8888
// GL_EXT_discard_framebuffer
// GL_EXT_shader_texture_lod
// GL_IMG_shader_binary
// GL_IMG_texture_compression_pvrtc
// GL_IMG_texture_compression_pvrtc2
// GL_IMG_texture_npot
// GL_IMG_texture_format_BGRA8888
// GL_IMG_read_format
// GL_IMG_program_binary
// GL_IMG_uniform_buffer_object
// GL_IMG_multisampled_render_to_texture
materials
OK!
i know why it's so slow, you practically draw something 300x per frame and it doesn't really matter if it has 2 trinagles or 300 per one call.
300x setup shader per frame is almost a limit for slower(not slow) devices.
Main issues:
1) do not ever call glGetError when not debugging/running debug build - it makes pipeline stall (pipeline stops and waits until all commands are executed)
2) since you have 100 lines - and using for all of them same program, why not to group them in one array ?
2 solutions
-----------------
A)
= you are not using vertex buffers - so
1) create temporary memory and pre-transform all lines/triangles into one array - will be much faster
2) setup shader once + set uniforms
3) setup attributes - start of temporary array you created (every call - believe me, it will be faster, good practice is create array on stack, but beware of overflow - but for 300 lines is practically impossible)
3) call one draw call for all lines/triangles at once
B) even faster solution (fake instancing) - this is really fast
= create vertex buffer with data (and now create this as real VBO !)
- and not with only 1 instance of line, but with reasonable count - for instance 300 (fake instancing) - 300x line data repeated,
- in tex.x,y (for instance) - set index 0.299 -> x = (float(index % 256) / 256.0f ) y = ( (index & (~255)) / 256.0 ) - using lowp vec2 inTex; attribute
= in shader:
- create uniform array with coordinates for instance uniform mediump vec3 positions[300];
- in vertex part - something like this
gl_Position.xyz = inPosition.xyz + positions[(int) ((inTex.x * 256.0) + (inTex.y * 65536.0)) ];
1) use shader
2) fill array with positions and set it to uniform
3) set attributes
4) draw - and according to situation change count of elements drawn
if you need draw more than 300 lines, enlarge array OR just do more calls this time this is getting efficient
But i suppose 1st solution will be more than enough.
Cheers.
P.
Petr Sovis said:
OK!
i know why it's so slow, you practically draw something 300x per frame and it doesn't really matter if it has 2 trinagles or 300 per one call.
300x setup shader per frame is almost a limit for slower(not slow) devices.
Main issues:
1) do not ever call glGetError when not debugging/running debug build - it makes pipeline stall (pipeline stops and waits until all commands are executed)
2) since you have 100 lines - and using for all of them same program, why not to group them in one array ?
2 solutions
-----------------
A)
= you are not using vertex buffers - so
1) create temporary memory and pre-transform all lines/triangles into one array - will be much faster
2) setup shader once + set uniforms
3) setup attributes - start of temporary array you created (every call - believe me, it will be faster, good practice is create array on stack, but beware of overflow - but for 300 lines is practically impossible)
3) call one draw call for all lines/triangles at once
B) even faster solution (fake instancing) - this is really fast
= create vertex buffer with data (and now create this as real VBO !)
- and not with only 1 instance of line, but with reasonable count - for instance 300 (fake instancing) - 300x line data repeated,
- in tex.x,y (for instance) - set index 0.299 -> x = (float(index % 256) / 256.0f ) y = ( (index & (~255)) / 256.0 ) - using lowp vec2 inTex; attribute
= in shader:
- create uniform array with coordinates for instance uniform mediump vec3 positions[300];
- in vertex part - something like this
gl_Position.xyz = inPosition.xyz + positions[(int) ((inTex.x * 256.0) + (inTex.y * 65536.0)) ];
1) use shader
2) fill array with positions and set it to uniform
3) set attributes
4) draw - and according to situation change count of elements drawn
if you need draw more than 300 lines, enlarge array OR just do more calls this time this is getting efficient
But i suppose 1st solution will be more than enough.
Cheers.
P.
Click to expand...
Click to collapse
Thanks
When I wrote I saw the glerror maybe it will slow down a bit.
Since I am coming from an object oriented development environment it was designed on that way...
The candle: line + triangle can have other data too. Maybe need to keep elsewhere the data...
The last candle line and rectangle and his color can change almost at each draw method: just 1 of the 4 params will nort change.
When the last candle is closed a new one need to be staeted
In this case needs to. Shift to left all other candles. Maybe for this I am keeping in separate methods.
I thought the shader setup is done in other part at least there I am getting the pointer to they. On surface changed/ created - I am not at PC now.
Text with price + time scale should be with a texture to a rectangle?
I will reply inline:
matheszabi said:
Thanks
When I wrote I saw the glerror maybe it will slow down a bit.
Since I am coming from an object oriented development environment it was designed on that way...
Click to expand...
Click to collapse
Object development has nothing to do with this , glGetError is NOT a function to retrieve error status from GL functions, its for debugging purposes only. Its commonly used as: (simple form)
#ifdef _DEBUG
#define CHECKGL(x) x; assert(glGetError() == GL_NO_ERROR)
#else
#define CHECKGL(x) x
#endif
CHECKGL( glUniform4f(.... .) );
or still very fast
#define CHECKGL(x) x; if (globalDebugGL) { assert(glGetError() == GL_NO_ERROR); }
matheszabi said:
Thanks
The candle: line + triangle can have other data too. Maybe need to keep elsewhere the data...
The last candle line and rectangle and his color can change almost at each draw method: just 1 of the 4 params will nort change.
When the last candle is closed a new one need to be staeted
In this case needs to. Shift to left all other candles. Maybe for this I am keeping in separate methods.
Click to expand...
Click to collapse
Again - preparing something to vertex buffer is 100x faster than calling gluseProgram, gluniform and then draw call.
Different values per "candle": you can change (per candle) color, position, tex coords, and another values - to max 16 vec4 attributes per vertex in vertex buffer.
just for your imagination what does exactly glUniform: it recompiles and rebuilds shader with new values. It's not fast at all. So drawing 2 triangles with new shader setup (different uniform values) is not very smart. You have only 800-1000 such operations per frame tops. New card can handle much more. Look for term "draw call batching" to learn more. Unity's main feature.
Just imagine, even chip in your phone can easily draw 20 textured MTris per sec and you draw just few thousands and it's sweating.
Very nice article about GLES 2.0 from apple - google for "OpenGL ES Design Guidelines" most of it is true on android as well
matheszabi said:
Thanks
I thought the shader setup is done in other part at least there I am getting the pointer to they. On surface changed/ created - I am not at PC now.
Text with price + time scale should be with a texture to a rectangle?
Click to expand...
Click to collapse
That differs according to your situation.
- Is price/time always same ? (texture)
- it's changing per frame, (prerender texture)
- it's changing per "candle" ? - I posted articles about text in gl apps in the last post.
I thing you can choose your way !
Cheers
P.
Thanks for answer.
Petr Sovis said:
That differs according to your situation.
- Is price/time always same ? (texture)
- it's changing per frame, (prerender texture)
- it's changing per "candle" ? - I posted articles about text in gl apps in the last post.
Click to expand...
Click to collapse
Price/time is the same until: the user press a button, than will change the time ( From To values) and collecting data will result a min price and a max price. So the price probably will change at that button event, but not all the time.
Also the last candle price value is "moving" at least the close value, but an move the min or max value too, which can be the min or the max of the whole chart, on those rare situations need to change the coordinate system too. Can be used here a trick as it is changing and it will add +20% so what not need to change on each tick (frame)
233528246055
matheszabi said:
Thanks for answer.
Price/time is the same until: the user press a button, than will change the time ( From To values) and collecting data will result a min price and a max price. So the price probably will change at that button event, but not all the time.
Also the last candle price value is "moving" at least the close value, but an move the min or max value too, which can be the min or the max of the whole chart, on those rare situations need to change the coordinate system too. Can be used here a trick as it is changing and it will add +20% so what not need to change on each tick (frame)
Click to expand...
Click to collapse
I would definitely use rendering text technique I already posted. Its very fast (when implemented properly) and you can "print" whatever you want.
One of the following
bitmap fonts: (more content preparations - you need to prepare texture for each font)
-------------------
font bitmap creator: google: angelcode bmfont
+ sample: google: "nehe 2d_texture_font"
freetype implementation: (easier use - free type can generate font you want - also very fast)
-------------------------------------
it's possible to compile it with ndk - i use it and it's simple
google: freetype
and code for starters: google: "nehe freetype_fonts_in_opengl"
Cheers
P.
EDIT: 11/15/2014
This post features version 2.x.x. It is a complete rewrite using Android Studio because importing the project from Eclipse didn't go too well.
For information on version 1.x.x , go to post #28
Downloads for both versions are at the bottom of this page.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
ZTORCH Features:
The goal of ZTorch is to be a extremely quick and lightweight app that does one thing and does it well without extra bloat or ridiculous permissions. ZTorch can vary the brightness of your phones LED and allow you to set brightness levels higher than possible anywhere else.
The Galaxy S4 is capable of 16 different levels of brightness (0-15). Compared to other Apps:
The stock "Assistive Light" that is featured with the phone only sets the level to 1.
The brightest AppStore Apps, such as TeslaLED, are able to set the brightness to a little less than half brightness, level 6.
Typically, flashlight apps take about a second to switch on the LED
ZTorch can adjust the LED in mere milliseconds.
ZTorch stays on when the screen is off and doesn't flicker when the screen switches off.
ZTorch works with the camera. Ever wanted to use the flashlight LED while recording a video or taking a picture? Now you can.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
ZTorch should work across all phones with root if the proper system file is on the phone. ZTorch scans for the following binaries below. If your device isn't supported and you know the path to the proper file, you can set that path in the apps preferences. This app has only ever been tested on the Galaxy S4, if you try it on a different phone, PLEASE let me know how it is!
Code:
"/sys/class/camera/flash/rear_flash", - For Galaxy s4
"/sys/class/camera/rear/rear_flash", - For Galaxy Note and maybe s3
"/sys/class/leds/flashlight/brightness," - HTC devices
"/sys/devices/platform/flashlight.0/leds/flashlight/brightness" - HTC devices
" /sys/class/leds/spotlight/brightness" - Motorolla Droid Devices
"/sys/class/leds/torch-flash/flash_light" - Motorolla Droid 2
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Screenshots from ZTORCH-beta-2.0.0.26.apk:
Main Activity as popup with widget shown in background.
{
"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"
}
Notification:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Permissions:
ACCESS_SUPERUSER - To set the LED
RECEIVE_BOOT_COMPLETED - Sets LED to 0, allows for persistent notification, notification on bootup.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Version Information:
Download attached at bottom of post.
LATEST: Version 2.0.3.50: (Feb 24, 2015)
Notification now appears on boot if that setting is enabled
Separated BootReceiver from main broadcast receiver so disabling the boot receiver won't break the rest of the app.
Notification icon changed to support Lollipop.
Renamed some app refs.
Somehow cut 50kb from the app, it's now 100.6Kb. Considering the Icons take up 89.5Kb I'm kinda amazed.
I haven't got around to making an actual Settings activity. So features are the same from prior version.
Version 1.2.2: (Mar 3, 2014) All the features work but is less refined.
Version 1.3.0: (June 16,2014) Added TorchPlayer to act similar to PWM. All Features work.
Version 1.4.0 (June 20,2014) Switching speed was the priority in this version; the brightness can be changed in <3ms. I abandoned the very comprehensive and powerful Stericson RootTools library in favor of a purpose built class that toggles the flashlight. Warning: The notification doesn't work on API-19 Android 4.4+. Clicking it does nothing. I need to build a new version sometime.
For more info on version 1.x.x such as the screenshots, see post #28
ZTORCH-beta-2.0.0.28: (November 15,2014) Beta version does not yet have a settings or preference activity implemented as well as other nonessentials. To change settings in this version, see below. Changes include:
Entirely new MainActivity that's now in a Popup window
Entirely New and Fully Working Notification
Widget now fills the entire 1x1 grid. (Let me know if there's problems, I set the left and right margins to -23dp to do this)
Added Warn feature and Torch Fireball icon for when the brightness is higher than the Warn value.
Slider no longer lags while trying to effectively "make a strobe light" by not sending broadcasts, updating views, or saving the brightness until after you take your finger off.
Slider changes color based on level.
ZTORCH-beta-2.0.0.33optimized: Technically should be: 2.0.2.33(November 16,2014) Changes:
Adds RECEIVE_BOOT_COMPLETE permission.
Ongoing Notification is available in AppPrefs.xml
TapGuard enabled by default. (Widget ignores first tap to prevent accidental taps)
ZTORCH-optimizedbeta-2.0.3.41: (November 17,2014) Changes:
New Notification AppPrefs.
ongoingNotif (Can't swipe away, Persistent).
onPriority and offPriority (levels: -2, -1, 0, 1, 2 where 2 is PRIORITY_MAX)
Shell Command Text and Toggle Button updated instantly while slider moves.
ZTorchReceiver enables you to send commands from other apps such as Tasker. Available broadcasts listed further down.
Fixed Force Close if the Main Toggle button is pressed and root was denied or the device is unsupported. (Not like you can use the app like this anyway, but still)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
BETA Version Settings
I'm still trying to figure out how android implements preferences and preference fragments. So in the beta, there is none! To change a setting, get a file browser with root access such as ES File Explorer, then navigate to the location below and edit the file "LEDPrefs.xml"
Code:
/data/data/derekziemba.ztorch/shared_prefs/
Additionally there is another file, "AppPrefs.xml" where you will find app specific settings and be able to configure the Notification.
"LEDPrefs.xml" will look like this on ZTORCH-beta-2.0.0.28. Later versions will be slightly different. I recommend uninstalling the app before installing a new beta.
default - The value the torch will turn on at when Toggled or Enabled.
inc - increment. Value the notifications "+" and "-" will increase or decrease by and the Widget will increase at if multitap = true;
multitap - If true, on successive widget taps the brightness will increase by the inc value. If false, brightness will toggle to default value;
wait - For multitap and tapguard. Time in milliseconds between successive widget taps to increase brightness. If more time than this has passed, the LED will shut off.
tapguard - To prevent accidental widget taps turning on the LED. If true, the widget ignores the first tap and waits for a second tap, unless the LED is already on.
min - just leave at 0, this is the "off" value, it is here in case some phones are reversed
max - maximum value on slider and the max value you can increment to. Only the first 3 digits of this will ever be used, giving a max possible value of 999.
warn - value at which the torch turns from yellow to a fireball and the slider begins changing colors from blue to yellow to red.
lvl - Current Brightness. There is no way to retrieve the current LED level, so the last value is stored here
sys - the system binary that controls the LED;
mask - bitmask. The brightness level is bitwise AND'ed with this value before executing the shell command to prevent invalid values. If you need help configuring this, use windows calculator and set it to programmer mode on Integer then click the bits you want to use, then use the integer value given.
"AppPrefs.xml" settings:
enableTorchOnAppLaunch - If true, opening the app will automatically set the brightness to the default value listed in "LEDPrefs.xml". Default is "false"
persistentNotif - If true, the notification will be persistent and it cannot be swiped away. Default is "false"
showNotifOnBootComplete - Posts the notification when BOOT_COMPLETE is received for easy access. Use with persistentNotif to prevent swiping away. Default is "true"
Notification Priorities. There are 5: MIN(-2), LOW(-1), DEFAULT(0), HIGH(1), and MAX(2). More info here: http://developer.android.com/design/patterns/notifications.html#guidelines
notifPriorityTorchON - Notification Priority when the LED is on. Default is "2"
notifPriorityTorchOFF - Notification Priority when the LED is off. Default is "-1". Versions before 2.0.3.41 including 1.x.x are hardcoded at "-2"
Important: Before changing any settings, be sure to kill ZTorch with a task manager. Otherwise the settings will not take effect and they will be overwritten when the app gets sent to the background.
If you mess up the settings ZTorch will force close on launch. Delete the XML file to restore defaults.
Strobe Light:
You can get some pretty cool stobbing effects by changing the "mask" and "max" settings.
If you set the "max" value to something like 200 with the mask set to 15 (0000-1111), when sliding the slidebar from 0 to 200, the actual brightness set will repeat 0-15 over and over.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Setting Brightness from other apps such as Tasker, using ZTorch's BroadcastReceiver
I still have to test if this works, but in theory it should. The ZTorchReceiver supports the actions below.
Code:
"derekziemba.ztorch.UPDATE_LEVEL"; //Service will check for extra Integer under the key "lvl" and set that brightness if it is valid.
"derekziemba.ztorch.WIDGET_TAP"; //Behave as if the widget was just tapped. MultiTap, TapGuard, and Wait apply.
"derekziemba.ztorch.STEP_UP"; //Increment Brightness by increment value
"derekziemba.ztorch.STEP_DOWN"; //Decrement Brightness by increment value
"derekziemba.ztorch.INCREASE"; //Increase Brightness by 1
"derekziemba.ztorch.DECREASE"; //Decrease Brightness by 1
"derekziemba.ztorch.ENABLE"; //Turn on torch at default level
"derekziemba.ztorch.DISABLE"; //Turn off torch
"derekziemba.ztorch.TOGGLE"; //Toggle the torch opposite its current state.
---------------------------------Internal---------------------------
"derekziemba.ztorch.UPDATE_FROM_MAIN"; //From main activity, prevents service from broadcasting UPDATE_FROM_SERVICE and cause an endless loop. Contains extra Integer under key "lvl"
"derekziemba.ztorch.UPDATE_FROM_SERVICE"; //Sent from the Service to Main, this one is Unregistered when Main is not visible. It is still sent by the service.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Important Note Regarding Brightness:
For default settings I have the max LED value set to 13 because I've experienced flicker. Values higher than 10 change the color of the slider to red and the widget and notification flame from yellow to fireball. Flicker occurs when your battery voltage is to low to support the current level of brightness.
To avoid LED flicker:
>3800+mV or ~50% is needed for Levels >=13.
> 3750mV or ~30% is needed for Levels > 9.
> 3600mV or ~10% is needed for Levels > 7.
I have used my app to work several hours in an attic at brightness 11. I used my phone because it's actually significantly brighter than every flashlight I own. That includes a flashlight with a 6V cell, a 3 LED headlamp, and a 4 battery AAA LED flashlight. My only light that beat it was my spotlight, but the spotlight's beam is too focused whereas the phone lights up everything.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Note: Android displays the build version as 1 higher than the file name. So Android will show version 2.0.3.41 as 2.0.3.42. This is caused by some Gradle Build Config bug.
I use the torch a lot so I just downloaded this and I'll definitely let you know how it goes. Thanks!
Verizon S4
Liquid Smooth 4.4
Sprint S4
Negalite 4.4
Great app. Been using it for a few days with no issues. Love the incremental increases/decreases.
Anyway to get this to stay in the notification drop down?
Sent from my SCH-I545 using Tapatalk 2
rahilkalim said:
Great app. Been using it for a few days with no issues. Love the incremental increases/decreases.
Anyway to get this to stay in the notification drop down?
Sent from my SCH-I545 using Tapatalk 2
Click to expand...
Click to collapse
I might be able to implement that as a setting quick when I get home. And maybe add an option to make it half height too if it's going to be persistent.
DerekZ10 said:
I might be able to implement that as a setting quick when I get home. And maybe add an option to make it half height too if it's going to be persistent.
Click to expand...
Click to collapse
That would be great. Thanks.
Sent from my SCH-I545 using Tapatalk 2
rahilkalim said:
That would be great. Thanks.
Sent from my SCH-I545 using Tapatalk 2
Click to expand...
Click to collapse
Just updated it. Here's what's new:
Settings Activity has had a makeover. The question mark on the side will explain what the settings do. The image on the left shows what it looks like if the Persistent Notification and the Minimizing Notification toggles are enabled. The right shows what it looks like with the Minimizing Notification toggle off. Notice that when the Minimizing Notification toggle is disabled, zTorch's icon is in the notification bar.
Here is what zTorch looks like in the notification drop down with minimization enabled. The left screenshot is with zTorch minimized. In this state the icon is not in the notification bar. The screenshot ion the right shows the notification expanded with the minimize option enabled, In this state the icon will show up in the notification bar.
Disabling Notification minimization but keeping Persistent notification enabled will cause the notification to appear like the left and middle screenshots. When the Torch is off, only an Activate LED button is present. If there are a large number of other notification, the notification will shrink up. With the Torch on more buttons become available as seen in the middle screenshot. The rightmost screenshot is the notification with both the persistent notification and notification minimization disabled.
Note: This version 1.2.0 has some rough edges. I'll polish it when I have more time. In the future the Settings activity will also be changed to an actual Android Settings layout instead of a generic layout.
EDIT: Version 1.2.1 rounds out those edges.
Now that school is out, I'll be updating and posting the source code on github soon
DerekZ10 said:
Now that school is out, I'll be updating and posting the source code on github soon
Click to expand...
Click to collapse
Great job, works great!
This looks great. Do you have any plans to update this for nc5 4.4.2 compatibility?
Sent from my SCH-I545 using Tapatalk
klabit87 said:
This looks great. Do you have any plans to update this for nc5 4.4.2 compatibility?
Sent from my SCH-I545 using Tapatalk
Click to expand...
Click to collapse
This is why I wanna get the source code up. So others can compile it for their versions. I'm running Android 4.2.2 Eclipse 2.0 Rom. It's all customized and set up the way I like, and it's been very reliable. I'm not sure when I will get around to upgrading. Every rom I have tried as a replacement has had problems.
I haven't got around to posting the source code because there was suddenly some issues with the build? I opened the project the other day and was told I needed to upgrade things, I did and now every object and include directive is underlined in red. I looked at it for about a minute before deciding I'll figure it out some other day. Haven't got around to it since.
Oh ok. I was just wondering. Looking forward to the source so we can have it work for updated android versions someday.
Thanks.
Sent from my SCH-I545 using Tapatalk
klabit87 said:
Oh ok. I was just wondering. Looking forward to the source so we can have it work for updated android versions someday.
Thanks.
Sent from my SCH-I545 using Tapatalk
Click to expand...
Click to collapse
Here's the Source Code Everyone, Good Luck! Everything for the project should be on GitHub including external libraries and the .psd files for the icons.
https://github.com/DerekZiemba/zTorch
I haven't been able to build this or other projects since upgrading the SDK and the Eclipse ADT. I'm not getting any errors, I just get "export build failed." Not sure what to do, maybe reinstall everything. Hopefully someone here can get it working. I just really don't have enough time. In fact the whole project was born out of procrastinating a huge report I didn't want to do for school.
I have everything working again and the source code should build the most stable recent version. The 1.3 beta version is on my dropbox now. This version is a work in progress and the new TorchPlayer feature is not in a working state, but everything else works as usual.
I'm releasing this build before this new feature is working so people with newer versions of android can use the apps pre-existing features.
Here is basically what TorchPlayer is and how it will effect the app in future versions:
Once working properly it will be used to define increment steps for things such as rapid-tap and consecutive-tap (currently double-tap). The time element of these steps will define the max time the LED will stay lit before (likely) dropping down a step. It will be a way to prevent the LED being lit in your pocket all day and limiting the max LED brightness to a defined time.
TorchPlayer will eventually allow you to name and save sequences and have a repeat mode so you can use it as a strobe light. I'm not sure yet how fast the LED can be switched on and off. I might also look into having the sequence controlled by Morse code using dots and dashes.
For this to work I have to figure out, basically, multi-threading(handlers, runnables, threads) and a few other things such as Gson or SQLite.
NOTE: Installing this version messed up my widget. If it happens to you just delete it and re add it to fix.
Shown below is version 1.3 beta 4. I've found that I can strobe the led light ridiculously fast. I haven't encountered the limit yet at even the 5 millisecond intervals. At 5millis the LED is flashing so fast that it is almost becoming steady. With this it may be possible to set custom "LightTones" for certain things like you do with ring tones.
EDIT:
Beta 5 added ability to duplicate several values to save on typing as seen below: Also note, the parenthesis and spaces don't actually matter and are only there to make it easier on me to read. The input is sanitized using: String scheme = behavior.replaceAll("[^0-9/sm,.*&]+",""); So only numbers, the letters s and m, and the symbols / , . * & matter. If a brightness value is out of range that command is ignored.
Here is a video of what the above TorchPlayer string yields.
https://www.youtube.com/watch?v=c1lwTHZwr-M&feature=youtu.be
DerekZ10 said:
I have everything working again and the source code should build the most stable recent version. The 1.3 beta version is on my dropbox now. This version is a work in progress and the new TorchPlayer feature is not in a working state, but everything else works as usual.
I'm releasing this build before this new feature is working so people with newer versions of android can use the apps pre-existing features.
Here is basically what TorchPlayer is and how it will effect the app in future versions:
Once working properly it will be used to define increment steps for things such as rapid-tap and consecutive-tap (currently double-tap). The time element of these steps will define the max time the LED will stay lit before (likely) dropping down a step. It will be a way to prevent the LED being lit in your pocket all day and limiting the max LED brightness to a defined time.
TorchPlayer will eventually allow you to name and save sequences and have a repeat mode so you can use it as a strobe light. I'm not sure yet how fast the LED can be switched on and off. I might also look into having the sequence controlled by Morse code using dots and dashes.
For this to work I have to figure out, basically, multi-threading(handlers, runnables, threads) and a few other things such as Gson or SQLite.
NOTE: Installing this version messed up my widget. If it happens to you just delete it and re add it to fix.
Click to expand...
Click to collapse
For some reason the toggle doesn't show in my drop down now, any ideas?
shindiggity said:
For some reason the toggle doesn't show in my drop down now, any ideas?
Click to expand...
Click to collapse
Just confirmed it is a bug. To get the notification to show you need to switch the torch on once. It'll stay in the dropdown after.
I'll try to get a new build together soon. I learned a few things about Android the other day that made me realize my code was overly complicated and difficult to work with, much more so than it ever needed to be. So I actually started a total rewrite since that version that I want to get perfect.
The new version is a different app all together, the system and launcher will see it as zTorch-L. The L stands for it really being the "Lite" version, in app it will refer to it self as zTorch-Lightning. I decided that the TorchPlayer feature went against the whole purpose of making my own app in the first place. I created it to be fast, simple, no-bs or bugs, do one thing and do it well. What I wanted out of TorchPlayer would cause the app to loose focus of its goal, so I started this new version that would be just that.
Because I want it to be totally finished before releasing, I'm not going to post a link to it here. The code wouldn't even compile if I tried. But if you really rely on the notification being in the dropdown PM me. I have an alpha version I compiled before going to far in to rewriting the code. Everything works great AFTER some tweaking first.
Initially it is inoperable unless, starting from the root directory, you navigate to the following file:
Code:
/data/data/derekziemba.ztorchL/shared_prefs/derekziemba.ztorchL_preferences.xml
Open it, delete what ever is in it, then paste the below text :
Code:
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<int name="flash_current_value" value="0" />
<int name="tap_time" value="900" />
<int name="brightness_increment_steps" value="3" />
<int name="default_value" value="8" />
<int name="flash_limit_value" value="13" />
<boolean name="rapid_tap" value="true" />
<boolean name="persistent_notif" value="true" />
<boolean name="mini_notif" value="true" />
</map>
I sent you a PM, be happy too.
DerekZ10 said:
Just confirmed it is a bug. To get the notification to show you need to switch the torch on once. It'll stay in the dropdown after.
I'll try to get a new build together soon. I learned a few things about Android the other day that made me realize my code was overly complicated and difficult to work with, much more so than it ever needed to be. So I actually started a total rewrite since that version that I want to get perfect.
The new version is a different app all together, the system and launcher will see it as zTorch-L. The L stands for it really being the "Lite" version, in app it will refer to it self as zTorch-Lightning. I decided that the TorchPlayer feature went against the whole purpose of making my own app in the first place. I created it to be fast, simple, no-bs or bugs, do one thing and do it well. What I wanted out of TorchPlayer would cause the app to loose focus of its goal, so I started this new version that would be just that.
Because I want it to be totally finished before releasing, I'm not going to post a link to it here. The code wouldn't even compile if I tried. But if you really rely on the notification being in the dropdown PM me. I have an alpha version I compiled before going to far in to rewriting the code. Everything works great AFTER some tweaking first.
Initially it is inoperable unless, starting from the root directory, you navigate to the following file:
Code:
/data/data/derekziemba.ztorchL/shared_prefs/derekziemba.ztorchL_preferences.xml
Open it, delete what ever is in it, then paste the below text :
Code:
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<int name="flash_current_value" value="0" />
<int name="tap_time" value="900" />
<int name="brightness_increment_steps" value="3" />
<int name="default_value" value="8" />
<int name="flash_limit_value" value="13" />
<boolean name="rapid_tap" value="true" />
<boolean name="persistent_notif" value="true" />
<boolean name="mini_notif" value="true" />
</map>
Click to expand...
Click to collapse
shindiggity said:
I sent you a PM, be happy too.
Click to expand...
Click to collapse
So you guys don't have to keep using that version if you don't want to, try the zTorch-Lightning_v1.Alpha2 . There's a lot of stuff to do yet, but all the basics are working.
You'll notice the notification is way more responsive and that it no longer does that thing "refresh flash" when switching to different notification styles. It responds instantly to setting changes now too.
When tapping the 1x1 incremental widget, the LED is now set to turn on before the system broadcast and before the on screen widget lights up instead of the other way around.
http://db.orangedox.com/FBzt4wNNfVu1xIMc0W/zTorch-Lightning_v1.Alpha2.apk
This is just what i have been looking for!! So what kind of licensing is your code on git under?
Adjustable flash brightness is just what i want to look adding to my Camera app. I need something lower intensity than the stock.
Unfortunately, I am unable to test this app as my rooted devices don't have flash.
hotspot_volcano said:
This is just what i have been looking for!! So what kind of licensing is your code on git under?
Adjustable flash brightness is just what i want to look adding to my Camera app. I need something lower intensity than the stock.
Unfortunately, I am unable to test this app as my rooted devices don't have flash.
Click to expand...
Click to collapse
Free to use as long as you don't repackage it as is but with ads or put a price on the app. However if you are creating your own app and just want to use the flashlight feature, you can use the below code however you want. I think the git code is way out of date, I worked on it a bit a while ago and I don't think I comited it. I've gotten busy and haven't had a chance to work on it in months.
Here is the code for directly changing the brightness. Free to Use however you wish.
Here is the Shell Class. The Static Methods create and maintain the superuser shell. Therefor a command can be executed app wide on a single shell instead of creating multiple Shell instances.
Code:
package derekziemba.misc;
import java.io.*;
public class Shell {
private static Shell rootShell = null;
private final Process proc;
private final OutputStreamWriter writer;
private Shell() throws IOException {//Open with Root Privileges
this.proc = new ProcessBuilder("su").redirectErrorStream(true).start();
this.writer = new OutputStreamWriter(this.proc.getOutputStream(), "UTF-8");
}
private void cmd(String command) {
try{ writer.write(command+'\n'); writer.flush();}
catch(IOException e) { }
}
public void close() {
try {
if (writer != null) { writer.close();
if(proc != null) { proc.destroy(); }
}
} catch (IOException ignore) {}
}
public static void exec(String command) { Shell.get().cmd(command); }
public static Shell get() {
if (rootShell == null) {
while (rootShell == null) {
try { rootShell = new Shell(); }
catch (IOException e) { }
}
}
return rootShell;
}
}
}
Here is what is used for setting the flash brightness. I stripped out all the app logic. SetLevelCovertly is the actual method used for setting the brightness. It is what the TorchPlayer uses to directly change the brightness in just milliseconds. The stripped away normal SetLevel method records the brightness, triggers the broadcasts, sets the widgets, and fires the notification. There is no way of getting the current flashlevel brightness since my Shell implementation is just for blasting commands at the terminal. Anything more will slow it down.
The listOfFlashFiles is a bunch of different files different phones may use. I've only ever tested the samsung file.
Code:
import java.io.File;
import derekziemba.misc.Shell;
public class Torch
{
private static String FLASH_FILE = null;
private static final String[] listOfFlashFiles = {
"/sys/class/camera/flash/rear_flash",
"/sys/class/camera/rear/rear_flash",
"/sys/class/leds/flashlight/brightness",
"/sys/devices/platform/flashlight.0/leds/flashlight/brightness",
"/sys/class/leds/spotlight/brightness",
"/sys/class/leds/torch-flash/flash_light"
};
/**
* Bypasses all checks and settings and just sets the value. The app will not know what the level is because it is not recorded.
* Will not trigger broadcast, widget views, notification
*/
public static void setLevelCovertly(int value) { Shell.exec("echo " + value + " > "+ getSysFsFile()); }
public static String getSysFsFile() {
if (FLASH_FILE != null) return FLASH_FILE;
for (String filePath : listOfFlashFiles) {
File flashFile = new File(filePath);
if (flashFile.exists()) { FLASH_FILE = filePath; }
}
return FLASH_FILE;
}
Hello,
Actually I have a project, let me explain :
On Xiaomi Mi4 running MIUI 6 (android 4.4.4) I have a sony imx214 sensor able of 32 seconds exposure time maximum, but on MIUI camera stock app I have a manual mode allowing me only 1 second exposure time maximum. (Yes I know that I need a tripod for long exposure shots). And I searched how to increase this maximum exposure time.
Xiaomi actually sells a MiNote which has almost the same sensor and able of 32s exposure time. So I took the camera apk from MiNote and replaced it on my Mi4, changing the permissions of the system app of course, but no way I still get 1s exposure maximum. So this setting is related to a dependency of the camera apk.
I tried to decompile apk, no result of what I was seraching for, I also tried apk analyzer app, but it's too much complex for me (I'm a newbie). I also made a project on dexter but I still don't understand how to see dependencies. I tried to make logcats when I changed the exposure time in manual mode and here's what I get :
Code:
D/QCameraParameters( 248): int32_t qcamera::QCameraParameters::setExposureTime(const char*), exposure time: 1000000
I searched everywhere and I was not able to find the QCameraParameters.
If someone is able to help me I can share dexter project with him.
But if no one has time can you just give me a clue?
Edit : Attachement of camera properties, here is the line telling me that camera can handle 32s exposure :
Code:
max-exposure-time=32000000;
And someone here managed to modify it : http://en.miui.com/forum.php?mod=redirect&goto=findpost&ptid=54658&pid=1573405
But can't flash his rom, and it's russian.
Okay, finally found a solution, MiuiCamera.apk from MiNote was not orking for longer exposure time but the apk from russian rom do the job.