Database Develop

[DEV][CM7] Compositor Bypass

Hi, I haven't posted 10 times yet, so hopefully somebody can move this to the Android Development section for me...
SurfaceFlinger has a mode called "COMPOSITION_BYPASS". This lets a fullscreen OpenGL window draw directly to the framebuffer, instead of SurfaceFlinger copying each frame to the framebuffer itself. It avoids a fullscreen copy and avoids a GPU context switch. It should be a major performance enhancement.
I haven't got it to work yet, but I've made some progress. Posting in case anybody has any good ideas to try...
The COMPOSITION_BYPASS mode is enabled in SF's Android.mk and the part that allocates the buffer for the client app is in Layer.cpp:387. I tried previously to enable COMPOSITION_BYPASS mode but got stuck because gralloc would not return a valid FD for any buffer allocated with GRALLOC_USAGE_HW_FB (i.e.: a framebuffer backbuffer).
I noticed in the new SGX drivers that gralloc.omap3.so has a constant string HALCompositionBypass. I *think* that adding a line like HALCompositionBypass=1 to /system/etc/powervr.ini might change the behavior of gralloc and give valid FDs out -- however, when I set it gralloc_open in FramebufferNativeWindow.cpp returns EFAULT!
Maybe some kernel poking is required...
Randall

[[Speed Improvements]] Brainstorming & Testing Thread!!

Hey guys,
Seems there's a lot of ways you can improve the speed of Android in general. Some seem to be snakeoil... others, work quite well and there's proof to back it up.
I'm only interested in discussing the latter .
A lot of people have helped me gather a better understanding of Android (hyc, stinebd to name a few) in addition to a lot of Google searching. I am going to compile a list of what I have done, I would like to hear what you guys have done! Most app killer apps / app control will already be addressed, so those tools need not apply... I'm looking for real, permanent fixes here without adding more apps!
I am also trying to have topics that are easy working up to advanced. Obviously the more advanced topics are going to be harder to do. You've been warned.
So here's the disclaimer.
****DISCLAIMER****
Speed is as always relative. That basically means I don't want arguments about which build is faster. I want to argue about how to make every build faster .
Also, these tips should apply to any build, any device... they are pretty generic tips, but are obviously specific to Android, with some idiosyncrasies that apply to our port that wouldn't apply to native Android devices. Some is common sense, others are real ways to tear into the system. Hope you enjoy it!
Topic 1
Difficulty Easy - Apps/Widgets​
I've noticed the number of widgets i have on my screens, or the number of apps that I have installed/are running in the background to greatly effect performance, in an obviously negative way.
Once I removed all the widgets (I only have the basic analog clock widget & the Google search widget on one desktop...) this seemed to improve general speed. One minor thing to check is if apps are set to auto/background sync. Only enable the ones you really want syncing, others just check manually.
On this same topic, replacing the launcher (the stock launcher in Android, Launcher2 is quite slow) can help immensely. I like ADW, but I've used LauncherPro in the past and it is good. Zeam also seems like a good launcher. I haven't used Go Launcher EX, I've heard good and bad things about it. Use what works best for you, try 'em all!
The last thing on this topic I would like to mention is animations. Settings -> Display -> Animation -> No animations can make the phone feel quite a bit snappier, obviously at the expense of the look/feel of the OS.
Topic 2​
Difficulty Easy - Controlling app 'net Access​
This leads me into the next topic, DroidWall. I've noticed that blocking apps from accessing the internet has been a very good thing - it's not so much a performance booster (although it probably does provide a little bump) it's mostly about battery life. Just be warned, if you block an app that is set to background sync, it will probably have very negative effects. Only disable an app's access to the internet with DroidWall after you've checked that app's background sync feature is disabled. I have a few apps allowed in DroidWall, and the rest are blocked. You can "whitelist" everything and check apps you want to block, or "blacklist" everything and check the apps you want to allow. It's a little annoying to remember to enable/disable DroidWall (I use the DroidWall widget to enable/disable it globally) but if you do, it is much better - you have complete control over how apps access the 'net on your device. It is available on the Market.
Topic 3​
Difficulty Moderate - SD cache/readahead tweaking​
The only reason I'm calling this one 'moderate' is the number of choices you have for settings for this... It's basically telling the SD card how much to hold on to or... read "ahead" if you will . This was turned way up in FRX07, (from 256kb to 2048kb or 2mb...) and I think this might be the source of a lot of the complaints of 'mini-resets' if you will where the boot animation is suddenly seen after a long system hang...
So some cards will work better with a larger setting - I've heard some with spankin new C6 cards that said 3072kb or 3mb was a good setting. Others have found a sweet spot at 256kb or 1024kb (1mb).
There are two ways of doing this - you can hack the init in the rootfs and adjust the setting manually, or be lazy like me and use SD Booster (from the Market). Adjusts the same settings, and they are applied immediately!
I would like to find a "sweet spot" - a good default if you will. Can folks test out 512kb and 1024kb, see if you have any more mini-resets within Android or any other slowness, etc... Obviously this isn't a cure-all for the slowness or the mini-resets, what we're looking to do is mitigate the effects. So let's focus on that, thanks!
Topic 4​
Difficulty Moderate - Overclocking​
Overclocking is obviously one relatively easy way to improve the speed of Android. In your startup.txt, add a line
Code:
acpuclock.oc_freq_khz=710400
for example to overclock to 710.4mhz. How did I find this value? I actually put in 714000, but if you look at dmesg near the beginning you'll see "ACPU running at ..." - that's what clock is the actual maximum. It goes in 19.2khz increments.
Feel free to experiment with how high your phone can go, just be warned that the higher you go the potential for failure goes up as well . Phone shouldn't blow up, but it might not work correctly or at all. Rebooting and scaling it back will fix it.
Here's the full *example* startup.txt:
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 physkeyboard=rhod400 acpuclock.oc_freq_khz=710400"
boot
You can put the command anywhere in the cmdline section, just make sure it's between the quotes and at least one space between each command.
Topic 5​
Difficulty Advanced - How Android Manages Memory/apps​
Ok, I'm going to take two approaches to this. The first, is the full explanation on how Android manages memory.
Please feel free to read the post I originally read that inspired me to start looking at this stuff - How to configure Android's *internal* taskkiller. It was very helpful for me to grasp how Android manages applications. This is the reason why application killers are not a good thing...
If you want to do it manually, Starfox suggests:
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
To try to do these commands, adb is very useful. Once you get adb shell working, then you just need to "su" (provides 'super user' privileges (root)) and put in the echo command above ^^.
I had another user (thanks icevapor) suggest this script -
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I tried it myself, and it works very well. This thread is a little overwhelming, but the jist of it is this:
Install Script Manager (on the Market)
Run the V6 SuperCharger script. I use "Aggressive 1 Settings" (#2) and then I use the OOM Grouping Fixes & "Hard to Kill" launcher (#17)
Point Script Manager to run /data/99SuperCharger.sh to run as root & on boot. This will ensure the tweaks are reapplied after a reboot.
Topic 6​
Difficulty Advanced - Managing Apps that auto-start on boot​
This is one of the most annoying things in Android. When you have no apps installed, it seems very fast. Then you install apps, and you never seem to get that original speed back... Now you can!
This is kind of difficult to do, I am still getting the hang of it... but here goes. All credit goes to hyc, his original post.
The basic idea here is you run a logcat (adb logcat is easiest here, or you can use GetLogs to pull logcat...) Look in this log for "for broadcast" and find apps that start on boot. For example,
Code:
Line 41: I/ActivityManager( 1394): Start proc nextapp.systempanel for broadcast nextapp.systempanel/.monitorservice.BootReceiver: pid=1752 uid=10060 gids={3003, 1015}
Notice there are two sides of the "for broadcast". The name of the package (nextapp.systempanel) and the name of the service, "nextapp.systempanel/.monitorservice.BootReceive". I made the mistake of disabling the app (the left side). Do not do this, you want to disable the right side!
So in the shell,
Code:
pm disable nextapp.systempanel/.monitorservice.BootReceive
This will be persistent across boots, it will go with your data.img.
Obviously this was just one example of an app to disable. So long as you disable the right side (after the 'for broadcast') you shouldn't disable anything that will cause a serious problem. The apps should still work, but for example if you disable Google Voice you won't get messages until you open the app. So think about that... You disable Titanium Backup schedules.BootReceiver, the schedules for Titanium Backup (if you have any) won't run. Stuff like that. Disable calendar, you won't get calendar events... Disable clock no alarms. Get it? Good. I have been rebooting several times, and I keep checking what is set to start on boot. I'm not quite happy with it yet, but there's some things I'm leery of disabling. Just be wary, if you do disable something and don't like it - just pm enable <whatever you disabled>.
Now experiment away! The one caveat is if you do break something with pm disable (and it's serious) you might get a failure to boot. It really depends on how bad you mess up. If you make a copy of your data.img before you start making these changes, you can revert to that data.img and start back there.

Alright guys. Going to use this thread as a way to brainstorm about ways to improve the speed. Read up what I've posted, let me know if I did anything wrong... Also let me know what you guys do to improve speed!
Don't care about what build you're running, this thread isn't about what build is fastest - this is a how do I make every build faster thread.
I also realize I posted this in the Rhodium section - I want to see if there's any TOPAa-specific tweaks that others should be made aware of!

Update to this - I changed around how topic 4 is done. Feel free to re-read that section.

Thanks arrrghhh, but for startup stuff, there are some apps doing the job, like Startup Manager or Startup Cleaner pro (found in Market), honestly haven't tried them yet but from rating, some of them has got 4.1/5.. What do you think mate?

metho88 said:
Thanks arrrghhh, but for startup stuff, there are some apps doing the job, like Startup Manager or Startup Cleaner pro (found in Market), honestly haven't tried them yet but from rating, some of them has got 4.1/5.. What do you think mate?
Click to expand...
Click to collapse
For the pm disable stuff? If you find an app that does it, more power to you. I want to control Android directly, hence the reason I went with a script that utilizes that concept. The pm disable stuff is obnoxious I know - so if you do find an app that'll do it for you, have at it. I didn't want to add any more apps into the mix if it wasn't necessary .

Rhod400 in startup.txt
Does physkeyboard=rhod400 cahnge the keyboard layout when texting?Does it make it bigger or what is that cmdline for?

1edge1 said:
Does physkeyboard=rhod400 cahnge the keyboard layout when texting?Does it make it bigger or what is that cmdline for?
Click to expand...
Click to collapse
Sorry, that part is completely irrelevant to TOPA. It is for a RHOD400, sets up the physical keyboard. You were only supposed to look at the acpu clock command, as it fits in the startup.txt... lol.
Use the startup for your device, I'm just showing you how the line should appear in the startup.txt...

arrrghhh said:
Sorry, that part is completely irrelevant to TOPA. It is for a RHOD400, sets up the physical keyboard. You were only supposed to look at the acpu clock command, as it fits in the startup.txt... lol.
Use the startup for your device, I'm just showing you how the line should appear in the startup.txt...
Click to expand...
Click to collapse
yeah i do use the startup for topaz. Was just wondering. haha. thanx for clearing it up

[Q] Compilation in the cloud (really?)

Hello,
I have a simple question about the compilation in the cloud for wp8 apps. As detailed on the MS Blog post titled Compile in the Cloud with WP8, when a developer submits an WP8 (only) app to the store, the app is compiled in MDIL in order to optimize the subsequent execution.
Despite this, on my unlocked Samsung Ativ S I experienced that even in the case of wp8 app - and I mean, apps that target ONLY the WP8 platform - the DLLs are still in CIL and not MDIL, and so they can be easily decompiled with tool such as dotPeak.
My question is: where am I wrong?
Thanks,
Sandro.

.NET binaries have multiple pieces. One of them is the CIL, which is what something like dotPeek decompiles. There's also an area where JIT output can be stored, to speed up future execution. It sounds like what the Store is doing is JITing the apps for ARM processors, to reduce load time after installing (otherwise, JITing a large app on the phone can take a while; you can see this yourself if you ever sideload a large app). This slightly increases the size of the binaries, but improves performance. The CIL isn't removed though, either because they want to allow the phone to make different optimizations (for example, different amounts of CPU cache can effect when you would want to unroll loops or inline function calls vs. when you wouldn't) or just because the format of a .NET binary *expects* there to be CIL there.

GoodDayToDie said:
.NET binaries have multiple pieces. One of them is the CIL, which is what something like dotPeek decompiles. There's also an area where JIT output can be stored, to speed up future execution. It sounds like what the Store is doing is JITing the apps for ARM processors, to reduce load time after installing (otherwise, JITing a large app on the phone can take a while; you can see this yourself if you ever sideload a large app). This slightly increases the size of the binaries, but improves performance. The CIL isn't removed though, either because they want to allow the phone to make different optimizations (for example, different amounts of CPU cache can effect when you would want to unroll loops or inline function calls vs. when you wouldn't) or just because the format of a .NET binary *expects* there to be CIL there.
Click to expand...
Click to collapse
Can you please point me to any documentation that describes the .NET binaries format, in order to better understand the CIL and MDIL section and .NET binary structure in general ?
Thanks, Sandro

The ones I found were all pre-MDIL, I'm afraid. There's plenty of documentation of the general format of a PE binary - it's a public standard - but I'm not sure where the MDIL is stored, actually. I was mistaken about the normal JIT output; it's either stored in memory only for that process execution, or in an assembly cache (as when you run ngen.exe on a managed assembly).

[Q] Hook X function use single instance of function Y for them

Hello,
i've spent few days experimenting and i'm totally lost.
I will write some example scenario:
I have function_1 in which give different results on every run (if last call >30s new results, <30s will give old one) (the time is checked using another "Utils class")
I'm hooking 3 processes which use some_method_1
I need to give them exactly same results from my function_1
The problem is every hooked process run another instance (?) of function_1, so i get bad results.
I've experimented a lot with Intents, BroadcastReceiver etc.
Tried implemeting them in initZygote but the problem was i don't know why but i can't load there sqlite file
Code:
SQLiteDatabase db = SQLiteDatabase.openDatabase(PATH, null, 1);
loading of file mostly works only in some parts of handleLoadPackage.
Tried invoking file loading, when all was loaded but still error 14, i guess it's about that BroadcastReceiver was in initZygote , and to be strict it was:
Code:
findAndHookMethod("com.android.server.am.ActivityManagerService", null, "systemReady", Runnable.class, new XC_MethodHook()
I would be glad for any help, thanks in advance!

Actually each process has its own memory. During startup, there is only one process (well, on 32-bit ROMs that is) called Zygote. That's where Android initializes some stuff that is required by every app, and where initZygote() is called. Every time an app is started, it gets a copy of the Zygote process, including its memory at that time, but from that point on, the memory is independent. There is no sync between the app's memory and Zygote anymore, in neither direction, and no sync between apps.
If I understand you correctly, you store the result and the timestamp in variables. As explained above, that variable is not shared between processes due to Android's (or Linux') general architecture. That's what you need IPC for, i.e. using services, intents, files, ... I don't know what exactly you're trying to do and which solution would fit best. Using files is usually the easiest way, but they're not really suitable if you have lots of refreshes and you might run into racing conditions. With intents, you have to check whether you can find a good way to send back the result. And services are generally possible (used e.g. by XPrivacy), but harder to implement, especially under Lollipop.

rovo89 said:
Actually each process has its own memory. During startup, there is only one process (well, on 32-bit ROMs that is) called Zygote. That's where Android initializes some stuff that is required by every app, and where initZygote() is called. Every time an app is started, it gets a copy of the Zygote process, including its memory at that time, but from that point on, the memory is independent. There is no sync between the app's memory and Zygote anymore, in neither direction, and no sync between apps.
If I understand you correctly, you store the result and the timestamp in variables. As explained above, that variable is not shared between processes due to Android's (or Linux') general architecture. That's what you need IPC for, i.e. using services, intents, files, ... I don't know what exactly you're trying to do and which solution would fit best. Using files is usually the easiest way, but they're not really suitable if you have lots of refreshes and you might run into racing conditions. With intents, you have to check whether you can find a good way to send back the result. And services are generally possible (used e.g. by XPrivacy), but harder to implement, especially under Lollipop.
Click to expand...
Click to collapse
IPC would be some good idea, thanks for hints Master, I appreciate your response!
//I aim only KK, don't plan to use LP

Kernel warning

While reading the kernel log I saw this:
Code:
**********************************************************
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for produciton use. **
** **
** If you see this message and you are not debugging **
** the kernel, report this immediately to your vendor! **
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
this is what the author of trace_printk() says:
Code:
trace_printk() is used to debug fast paths within the kernel. Places
that gets called in any context (interrupt or NMI) or thousands of
times a second. Something you do not want to do with a printk().
In order to make it completely lockless as it needs a temporary buffer
to handle some of the string formatting, a page is created per cpu for
every context (four per cpu; normal, softirq, irq, NMI).
Since trace_printk() should only be used for debugging purposes,
there's no reason to waste memory on these buffers on a production
system. That means, trace_printk() should never be used unless a
developer is debugging their kernel. There's macro magic to allocate
the buffers if trace_printk() is used anywhere in the kernel.
To help enforce that trace_printk() isn't used outside of development,
when it is used, a nasty banner is displayed on bootup (or when a module
is loaded that uses trace_printk() and the kernel core does not).

What does this mean?

Alien333 said:
What does this mean?
Click to expand...
Click to collapse
This function lets kernel developers debug fast path sections (Fast path forwards packets without extra processing in the kernel. Its better for speed). A normal printk doesnt work (well it might, but be extremely expensive) in these fast paths so the developer has to use this to see what is going on during debugging.
To facilitate this debugging, extra memory is used when trace_printk() is being used. This memory is reserved at a kernel layer so you likely lose memory for application use - how much and how often depends on how much of this debugging function they are using. Allocation of this memory is also expensive.
This debug method should be stripped out before packaging the kernel for the device but Xiaomi hasnt done this somewhere in the kernel and its throwing a warning.

Thread moved.

LOL They have packed debug version of kernel into rom which goes out to the masses... WTF Xiaomi? I hope that won't be the case for my device when I get my hands on it in a few days...

zelendel said:
Thread moved.
Click to expand...
Click to collapse
Oooo... You're in the Xiaomi forum now?

TheDriller said:
Oooo... You're in the Xiaomi forum now?
Click to expand...
Click to collapse
Everywhere and nowhere all at once lol

This is on 2 of my note 9's and a note 10, should I be concerned?