Video Tutorial on How to Compile Android and Modify Kernels

video

For those interested, I have just posted a video tutorial series on XDA for building Android Oreo, Nougat, Marshmallow, and Lollipop on 5 different phones, the emulator, and 5 different ROMs. Also included are custom kernel editing, adding apps, changing source code, backgrounds, and more. Here’s what I posted:

From XDA: https://forum.xda-developers.com/android/general/guide-how-to-build-custom-roms-kernel-t3814251

===========================================================================

Praise God! Finally a video tutorial of how to build Android and modify kernels!

I have created a video tutorial and guide for how to compile Android, from Lollipop through Marshmallow, Nougat, and Oreo. The video series covers several different phones, the emulator, kernel and rom editing, app source code editing, and much more!

Who is this video series for?
Well, this video tutorial is a step by step guide built primarily for the beginner. This is written for those who already know how to flash TWRP, CWM, or the like, and who have installed a custom rom before. This is designed to help those who are ready to move up from flashing and installing other peoples custom rom to actually start making their own custom roms. I recommend that a beginner watch the entire series in numerical/alphabetical order (the videos are marked).

That said, I believe that an intermediate developer may find a useful trick here and there, and they should just skip ahead to videos of interest. Perhaps kernel development, or something along those lines.

An advanced rom/kernel developer will probably far exceed my feeble abilities, and will not likely find much useful information here. Perhaps if you are an advanced developer, you would consider continuing the tutorial or making an advanced video series! (See further posts for recommendations on contributing videos.)

Why did you put this together?
Well, after building roms for several different devices, I started receiving requests from users who wanted to start building their own roms, but didn’t know how. I didn’t have enough time to answer everyones questions, so I wrote a few guides, pointed others to guides that were available, but there are some things that you just need to see to understand. Hence, the video tutorial. I just hope that someone finds it useful.

This course was written in order! While Lollipop and Marshmallow are old by today’s standards, there is still good learning value in building them, and there are topics covered there that really make them worth watching.

What’s in the videos?
During the series, we will be building for the emulator, as well as 5 different phones of various brands, and 5 different roms. I hope that this will give the viewer a good idea of how to build for their own specific phone as they see the differences and similarities across the phones and custom roms.

[CODE]
+ Ubuntu installation
+ Java installations
+ Using Git, GitHub, GitKraken, and the command line
+ Fastboot and ADB
+ Heimdall/Odin
+ QFIL, QPST, SALT, and other tools
+ AOSP, SlimRoms, PACrom, AOKP, AOSCP
+ Lollipop, Marshmallow, Nougat, Oreo
+ Errors
+ Overclocking CPU/GPU
+ Adding Governors and I/O Schedulers
+ Sound modifications
+ Changing app colors, text, and icons
+ Adding prebuilt apps
+ Adding source code
+ Converting device from one rom to another
+ AND MORE!
[/CODE]

**** This is an UNOFFICIAL TUTORIAL. Use at your own risk! ****
Download links:
Ogg Vorbis Video GitLab:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide[/url]
Clicking on a video in GitLab will allow you to watch it online.

Ogg Vorbis Video Downloads:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide/-/archive/master/course_android_developer_guide-master.zip[/url]
This download is rather large due to the multiple videos.

MP4 Video GitLab:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide_mp4[/url]
Clicking on a video in GitLab will allow you to watch it online.

MP4 Video Downloads:
[url]https://gitlab.com/alaskalinuxuser/course_android_developer_guide_mp4/-/archive/master/course_android_developer_guide_mp4-master.zip[/url]
This download is rather large due to the multiple videos.

I also have several written guides available on XDA, here are a few:

Building ROMs for the Galaxy Note Edge: [url]https://forum.xda-developers.com/note-edge/general/guide-build-aosp-roms-kernels-note-edge-t3488840[/url]
Building ROMs for the Galaxy S4: [url]https://forum.xda-developers.com/galaxy-s4-tmobile/general/guide-step-step-instructions-building-t3402637[/url]

===========================================================================

Be sure to check out the videos or the XDA thread! I hope that these will help some of the aspiring Android developers out there!

Linux – keep it simple.

Advertisements

What exactly constitutes as open source hardware (OSHW)?

oshw-logo-200-px

There is a lot of buzz around the net on this idea of open source hardware (OSHW). However, the deeper that I look into it, the more tangled the web seems to be. I’ve been noticing that some sites tout equipment as OSHW because they have SOME open source hardware on-board. In other cases, the pieces/parts are all closed source hardware, but the schematic of the use of those parts is open, so that makes it open source hardware. It gets a little confusing.

Some of you are reading this, thinking, “What IS open source hardware, and why does it matter?” I guess it is time to get technical, here is the definition from https://www.oshwa.org:

Open Source Hardware (OSHW) is a term for tangible artifacts — machines, devices, or other physical things — whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things.

Well, that clears up the first part of our question. I guess now the second part to answer is: “Why does it matter?”

For the educated, you will find them placing tape over their computer cameras, using tor clients, chatting through XMPP, and generally taking a strong stance to protect their privacy.  You see, with all of this great technology, come great risk. That risk is this: someone could be spying on you.

Take, for example, Carrier IQ. (If you doubt that this is real, you can look it up on Google or any other search engine, because it does exist.) It was a great program designed for cell phone manufacturers so that they could get reports on what went wrong for the end user while using their phone. Say the camera app crashes, it could send a detailed report to the carrier (such as T-Mobile, AT&T, Verizon, etc.) to let them know that a user is having camera problems. As they collect this data, they can see statistically that all the users having this camera app crash are all using software version blah-blah.blah, and it trips on this line of code because of a kernel issue. Now armed with this information, the carrier can make modifications to the kernel, push out an update, and solve that issue for their phone users who want to take pictures with their camera.

Overall, the above paragraph sounds great. The end users get the camera working properly, and the carriers get happy customers, so everybody wins. Here’s where it gets touchy. What people came to realize is that the Carrier IQ software could also do things like: log every keystroke, take a picture and upload it to some carrier server, record audio, view your phone logs, etc., etc., etc. That’s where people took issue.

Granted, the example above was for software, and we are talking about hardware. However, hardware often faces similar issues. For troubleshooting purposes (we will give them the benefit of the doubt….) hardware will often have “back doors” or be “magic black boxes” that you don’t really understand or know about. Because the drawing, schematics, and software that runs on these smaller hardware items, such as modem chips, SoC’s, etc., are closed source, hidden from your view, you don’t know what is really going on under the hood.

So, a fictitious example:

What if you bought a *Name your car company* model: ZuperOne. Let’s say that, unbeknownst to you, every mile you drive, it sent your GPS position to the car factory, as well as what radio station you were listening to at the moment, what speed you were driving, if you were wearing your seat belt, and record from the microphone in the car, etc., all without letting you know.

What would they want that information for? Well, who knows, really. Perhaps they want to build better ZuperOne’s, or see what radio equalizers they should put in the next model. Maybe they want to evaluate engine performance by region compared to the recorded temperatures. That’s great, I guess.

But, what if they decided to sell your radio preferences to local stations? Or turn you over to the police for speeding? Or record your conversations in the car? Whoa! That would be bad, obviously. Your private life is just that, private, and it should stay that way.

The problem is that your privacy is being invaded, but you don’t even know it. Seems far fetched, but now replace that car with your cell phone. Built in hardware that is below the system level, available for the hardware manufacturer to use at their leisure.

So, back to the real world. What if the ZuperOne car was made OSHW? E.g., every part was specifically spelled out in the documents and drawing, all of the software was available for review, and you knew everything about the car? Then you would be informed that they are spying on you. You might not drive the same way, or go the same places. Or, you might ask your programming buddy to reprogram the source code to not transmit some (or all) of that data to the factory. Now you are not only informed, but you have modified it so you will not be spied on at all.

That is the goal of open source hardware. The OSHW stamp *SHOULD* mean that every part of something has been open sourced, allowing you to at least know what it is doing. In general, because they are open, they do not include any kind of spy ware, since you will obviously see it and not use it for that reason. Notice that it does not actually mean that there is no “back door” nor spyware, it just means that you are able to look at the code yourself and can see those issues, and that you have the means and permission to change them, if you want to.

So, what’s the issue? The problem that I’ve been running into is that some hardware is being manufactured, claiming to be open source hardware, only to find that it is *mostly* open source hardware. The question becomes, how much of a product needs to be OSHW for the entire product to be marked as OSHW? In my mind, it is black and white. To procure a OSHW stamp of approval and sale, the entire product must be made OSHW, and all of the components must be OSHW. But apparently, there are more than one opinions on that.

However, on the plus side, I have found one website that sells OSHW, and closed source hardware as well. However, they appear to be very diligent in marking and marketing each product as to it’s open source hardware status. I’ve also checked with a few other sites who have reviewed their products (since I’m not an engineer), and found them to be very reputable on what they mark as OSHW or not. That website is Olimex. There are probably others as well. If you know of one, be sure to drop a line in the comments. Although a little dated, there is also a wiki list of open source hardware projects that you can view.

Do I wear a tinfoil hat to bed every night? No. Just on Tuesdays (just kidding). But it would be nice to live in a world where your hardware wasn’t built to spy on you.

Linux – keep it simple.

Geany: the little IDE that could!

geany_ide.png

Recently, while working with some older equipment, I needed a lightweight java IDE to compile some java projects. I really wasn’t looking for something quite as big as eclipse or netbeans, I just wanted a simple, one stop solution that would allow me to build java programs on an older laptop.

So, I rubbed a magic lamp, and out popped Geany!

Well, more specifically, the laptop is running Debian Wheezy, and had openJDK already installed. With that alone, I could have built java programs from the command line, but it can get a little tedious. So, I looked on the repositories for an IDE that wasn’t too large.

Thus enter Geany. I first used Geany a long time ago as a text editor on #! (CrunchBang) Linux, but revisiting the program revealed that I was not using it to it’s full potential. Specifically, you can compile, build, and run various program types from within Geany. Of course, it only outsources the commands for you, so you need a java jdk in order to compile java, or a c++ compiler to compile c++. Geany just does all the command line work for you.

What Geany does accomplish for you, however, is a great user interface with templates and the ability to organize projects or view code with different filters. As you can see in the picture, I was testing out Logic Crazy’s Alpha Beta Chess program.

As well as showing you the code, it can do parenthesis highlighting, colors for different code type, and a class and method tree on the side. It really is a great program if you need a lightweight IDE. I know that I’ll be putting it to good use.

Linux – keep it simple.

Installing the latest PicoLisp on Ubuntu

While testing out The Quiet Learner‘s game, Dr. Theobold, a text based adventure game written in picolisp, I ran into several issues. As discussed previously, I added these issues to the bug tracker on Savannah. Come to find out, the distributed packages for Ubuntu are using version 15.xxx of picolisp, and The Quiet Learner wrote his program for version 16+. We needed to find out if the old version was the culprit, or if there truly were issues in the game.

So, I updated to version 17.7.6 (a rather interesting numbering, since I tried this the 4th of July week, but that is something else entirely).

As simple as the above statement was, my trek was not quite as simple. I am used to compiling programs. Typically, you start by unzipping the source, using ./configure, then make, and sudo make install. However, this was different.

Of course, I downloaded the source from the link in the PicoLisp Wiki. After that, I unzipped it with the standard

$ tar -xzvf ./picoLisp.tgz

and moved into the new director with

$ cd picoLisp

Once there my usual bag of tricks didn’t work, which is why it is always good to read the instructions. Ends up that I needed to cd into the src64 directory and run make. No ./configure first.

$ cd src64

$ make

And there was no option to make install. Instead I had to manually symbolically link the files, and that is where everything went wrong. You see, the INSTALL file had pre-typed instructions with all 3 links you could use, like so:

# ln -s /<installdir> /usr/lib/picolisp
# ln -s /usr/lib/picolisp/bin/picolisp /usr/bin
# ln -s /usr/lib/picolisp/bin/pil /usr/bin

But after doing that, it didn’t work. It didn’t work because I forgot that the directory was picoLisp, not picolisp. I chased my tail for a while, re-creating the same bad links over and over again until I realized my mistake. Since /<installdir> was not the directory (obviously) I was hand typing picolisp, and it wasn’t working. So, be smart and not like me. Do as I now say, not as I erroneously did!

After straightening it out, it worked great! Actually it cleared up 3 of the issues that I put on the tracker for the Dr. Theobold game. I guess it pays to have the latest and the greatest when it comes to PicoLisp!

Linux – keep it simple.

MechDome: Run your Android apps on iPhones and iPads!

As an open source developer of simple Android applications, I can’t tell you how ecstatic I am about a new website: MechDome  (https://www.mechdome.com/). Finally, a one stop shop to turn your Android app into one that can be used on iOS devices, in minutes!

Can this really be? Is it really that simple? Drag and drop your Android apk file into their website and it spits out an iOS application? Well, I decided to try it for myself, and I’ve devoted this entire post to my experience.

TLDR: MechDome ROCKS! It successfully converted my opensource app: Hourglass, into an app for iPhones. If you are an Android developer, you should head over to MechDome right now!

Still with me? Great, then here are my thoughts on MechDome ….

Website Experience:

mechdome_home

The MechDome website is intuitively laid out in an informative and well thought out manner. From the opening page you will see all the information you need to get started, as well as informative placards telling you what MechDome will do for your app, namely convert it from a native Android apk to a native iOS application.

mechdome_intro

After clicking “Create App” at the top, you are asked to sign up for an account. The process is clean and intuitive, and I really liked the color scheme. Perhaps one of the best features of the website is the modern user interface and clean look.

I also tested the website out on my cell phone, and it worked beautifully.
mechdome_icon

Within a minute I had my app uploaded and was ready to test out this process. You have a couple of options about Firebase or Google ads, etc., as well as the option to use a custom icon. I think the choice to use a custom icon is great, as you may want something that looks more “iPhone-ish” or something to differentiate between your Android and iOS applications visually. After choosing your options, press save.

Once your settings are properly set, all you have to do is click the Simulator button. Presumably, when they open up the options to go to the Apple store, you can simply press the iOS button instead, but for now, free accounts are only able to upload one app for the simulator.

This is the only “problem” I saw with the website. After clicking the Simulator button, the button starts spinning, but there is no sort of progress report. After a while of waiting I ended up closing the browser, opening the page again and found the button still spinning, so I left the screen to do some research. After a few minutes, however, I received an email telling me that my app was ready for download.

So if you convert an app, after clicking Simulator, you can go about your business knowing that an email will be sent to you when your app is ready. That is really convenient. I do think the website should indicate that, though, after you click the Simulator button.

I tried this twice with my two email accounts. The first app I tested was done in a few minutes. The second app I tested was not done for several hours. Both of the apps were about the same size, albeit one was a little more complicated than the other.

mechdome_appready

Once your app is ready, the Simulator button changes from the orange “refresh” symbol to a green “download” symbol to let you know your app is ready for download.

A quick tap of the download button and I had a shiny new zip folder on my hard drive. Simple, short, sweet!

Now all I had to do is test it…..

App conversion:

It actually took me a while to get the hang of how to use an Apple computer so I could test the app that I converted. Since that is a bit of a rabbit trail, I will save that for the next post. Here I will just talk about how well the app conversion worked.

As I said before, I used my two email accounts to “cheat” and use MechDome twice. Currently, free accounts only get one trial download/conversion for simulator use only. Both apps that I tested did work rather well, so I will only discuss the open source app that I tested, which was my Hourglass app, available on F-Droid and the Google Play Store.

Here’s a few screen shots of my app in iOS action:

This slideshow requires JavaScript.

Overall the app worked great! It looked pretty close to what it looks like on Android, and as far as I could tell, every part of the app, every button, every slider, etc., worked flawlessly.

Notifications, however, were a bit different. Not wrong, just different. First, as you can see in the slideshow, I was prompted to ask if I would allow this app to send notifications or not. Choosing yes allowed the notification to pass through, and you could see it in the notifications bar, if you pull the bar down. When the timer on the app reaches 0:00, it is supposed to have a popup to tell you that your timer is up, but that didn’t happen. If the app was open, then that would transpire, but not if the app was closed. However, the sounds still played, so it seems to still function great as a background timer.

The other app I converted was a customer feedback type of app, which was not open source, so there are no pictures of it here, sorry. An interesting note, it used parse extensively, and seemed to work flawlessly. This proved to me that parse, networking, and intents were working great! The only oddity was the color of the “stars” for the ratings. In the Android version, the stars were orange/yellow, but in the iOS version, the stars were an odd gray color. Still functional, just a bit of a visual oddity. Overall, I was really impressed. Two thumbs way up from this Android developer!

Open source and Pricing potential:

I exchanged a few emails with the MechDome staff and was really impressed by how quickly they responded, as well as their professionalism, enthusiasm, and helpful attitude. In those emails I asked them about general pricing and open source development. They have not publicly finalized any pricing options, but it sounds like they plan on a tier subscriptions. Perhaps those who do multiple apps, or apps of a certain magnitude will fall under larger “tiers” and be charge extra.

Within our emails, we had a brief discussion in which I was proposing an open source developer account option. While I cannot speak on their behalf, they did seem very favorable to supporting open source development. Obviously, if you are making free applications, it doesn’t work to pay money to convert them for the iOS systems. They were curious to know what my thoughts are for what an open source developer account might look like.

These sort of things are probably best left to bean counters who usually handle this thing, but here are my thoughts on how to best support open source development:

  • Ideal: Give users the opportunity to create an open source developer account that can convert a limited number of open source apps per month, such as two or three, for free. No subscription costs, and if the account stays active, then it will not expire.
  • Less than ideal, but still helpful: Give users who already have paid subscriptions the ability to convert open source applications without counting against their monthly quota or subscription.
  • A one time setup cost: Another option might be a one time cost, rather than a subscription, for an open source account. E.g., a $25 setup fee for open source users to set up a developer account.

With either of the above options they will help support open source development. However, I suspect that if it costs anything for a subscription, a lot of open source developers will not be able to participate.

For instance, my open source applications and software work garner me $0 currently. I receive no donations currently, and do not get paid for my open source work, I don’t currently support advertisements, because this is my hobby. So if the subscription costs too much, I would not be able to maintain the subscription.

But, if there was a one time fee (like there is to get a Google developer account and put apps on the Play Store), or a free account with limited use for the open source developer, then I would be all in! Obviously, any account that used the software improperly, to convert closed source materials for free would need to be prosecuted, etc., but that is something I’m sure MechDome  is already looking at from a legal standpoint.

These are just my thoughts, and they do not reflect MechDome‘s opinion on the matter, as that remains to be seen. Hopefully they will consider the open source community and help it thrive by allowing some sort of use of their conversion software, because MechDome has proven to me to be exceptional when it comes to quality and customer service so far! Now all we have to wait on is their pricing.

In the mean time, head over to MechDome and try converting an app yourself! It works great! If you have trouble running that app in the simulator, be sure to check out my next post!

Linux – keep it simple.

P.S. I don’t want to sound like a broken record, MechDome is not offering me any special deals, payment, or benefits to write this, I just really liked my test run of their conversion software on their website.

Apache bouncy castles….

So, another day, and another error. While building SlimRoms 7 for the Note Edge, I ran into this error:

[CODE]
[ 0% 60/15886] Docs droiddoc: /home/a…rget/common/docs/apache-http-stubs-gen
external/apache-http/../../frameworks/base/core/java/android/net/http/SslCertificate.java:19: error: cannot find symbol
import com.android.internal.util.HexDump;
^
symbol: class HexDump
location: package com.android.internal.util
external/apache-http/../../frameworks/base/core/java/android/net/http/SslCertificate.java:42: error: package com.android.org.bouncycastle.asn1.x509 does not exist
import com.android.org.bouncycastle.asn1.x509.X509Name;
^
external/apache-http/../../frameworks/base/core/java/android/net/http/HttpResponseCache.java:19: error: package com.android.okhttp does not exist
import com.android.okhttp.Cache;
^
external/apache-http/../../frameworks/base/core/java/android/net/http/HttpResponseCache.java:20: error: package com.android.okhttp does not exist
import com.android.okhttp.AndroidShimResponseCache;
[/CODE]

Hours of online surfing and scrounging, and trying different things led me to this Google issue:
https://code.google.com/p/android/issues/detail?id=230820

That perfectly detailed the same problem I had, as well as providing a viable solution. So I implemented it by opening build_slim7/external/apache-http/Android.mk, which read (among other things) :

[CODE]
LOCAL_JAVA_LIBRARIES := $(apache_http_java_libs)
LOCAL_MODULE_CLASS := JAVA_LIBRARIES
LOCAL_DROIDDOC_SOURCE_PATH := $(LOCAL_PATH)/src \
$(LOCAL_PATH)/android \
$(LOCAL_PATH)/../../frameworks/base/core/java/org/apache
[/CODE]

And exchanged it with this:

[CODE]
# WJH LOCAL_JAVA_LIBRARIES := $(apache_http_java_libs)
LOCAL_JAVA_LIBRARIES := $(apache_http_java_libs) okhttp bouncycastle framework
LOCAL_MODULE_CLASS := JAVA_LIBRARIES
LOCAL_DROIDDOC_SOURCE_PATH := $(LOCAL_PATH)/src \
$(LOCAL_PATH)/android \
$(LOCAL_PATH)/../../frameworks/base/core/java/org/apache
[/CODE]

And the problem went away! So, I thought I’d share in case any of my readers had a similar issue.

Linux – keep it simple.

Ship, Captain, and Crew!

Ready to set sail for high adventure? Having trouble deciding which one of you and your friends are going to pay the tip at dinner? That’s why I put together this little dice game, Ship, Captain, and Crew. Praise God, it even works!

You can check it out on the Play Store:

https://play.google.com/store/apps/details?id=com.alaskalinuxuser.shipcaptainandcrew&hl=en

And hopefully soon on F-Droid ( I submitted the project, and it was accepted, just waiting to post to the repository).

device-2017-03-08-124806

Here’s the description:

A classic dice game for up to four players!

This simple game requires a lot of luck and a very small amount of skill. In times past, this game was used as a gambling or drinking game by sailors and merchants alike. You must procure a ship (6), a captain (5), and a crew (4), the remainder is your cargo.

Once you have your ship, captain, and crew, you can click on dice that you wish to hold in order to save them rather than roll them. You can also choose to keep them all if the conditions are right. The “point” or high score is always visible, and that is a big help to the “hammer” or the last player.

This game is open source and add free! So grab a couple friends and set sail for high adventure with this fun little dice game. If your lucky, you may even strike “midnight”!

It is an open source app, and you are welcome to check out the code on my github page.

Linux – keep it simple.

Can’t apply that type to a super!

Another compiling error as I work on getting Android Nougat on the TBLTEXX/TBLTETMO Samsung Galaxy Note Edge. This time, it will not allow me to return processUnsolicited(p) as a type under “super” like so:

[CODE]
super.processUnsolicited(p);
^
[/CODE]

So, I opened up build_cm14/device/samsung/tblte-common/ril/telephony/java/com/android/internal/telephony/tblteRIL.java and took a look, here is what I found:

[CODE]
@Override
protected void
processUnsolicited (Parcel p) {
Object ret;
int dataPosition = p.dataPosition(); // save off position within the Parcel
int response = p.readInt();
……………EDITED FOR SPACE……………..

// Forward responses that we are not overriding to the super class
super.processUnsolicited(p);
return;
}

}
[/CODE]

Which I changed to this after reviewing similar code for the JFLTETMO in their jflteRIL.java code:

[CODE]
@Override
protected void
processUnsolicited (Parcel p, int type) {
Object ret;
int dataPosition = p.dataPosition(); // save off position within the Parcel
int response = p.readInt();
……………EDITED FOR SPACE……………..

// Forward responses that we are not overriding to the super class
super.processUnsolicited(p, type);
return;
}

}
[/CODE]

Apperently, we needed to give it an integer named type to keep things flowing smoothly. I understand that well enough, but what confuses me is that this worked in Marshmallow, why does it not function in Nougat the way it was written before?

Linux – keep it simple.

Breaking down a voltage control app

I learned so many things while making the S4 GPU voltage control app, that I thought it would be appropriate to break it down into groups.

Here is the source on GitHub:

https://github.com/alaskalinuxuser/S4_GPU_voltage_control_app

And a download link for the app itself: http://www.mediafire.com/file/hk5vcce0s5r6kb7/GpuVoltageControl_1.0.apk

Since, by nature of the app, it was inherently dangerous, I wanted to make sure that people without the appropriate files would not be able to use this app. That part was pretty simple. First, I declared the needed file. If you don’t have this file, there is no reason to use this app.

[CODE]
// declare the gpu file
File gpu = new File(“/sys/devices/system/cpu/cpufreq/vdd_table/gpu_vdd_levels”);

// check if the file exists
if(gpu.exists()){
System.out.println(“gpu exists”);
} else {
Toast.makeText(this, “This kernel does not support this action!”, Toast.LENGTH_SHORT).show();
finish();
}
[/CODE]

So, if the file exists, then it pints out “gpu exists” to no where, which does nothing, but allows the program to continue. If not, or “else” it creates a pop-up (toast) that tells the user they don’t have the file and thus the kernel doesn’t support this app, and the app closes with the “finish();” command.

Then, I needed a way to tell the user what the current state of the GPU voltage was. Is it set to the default values? Is it over volted? Under volted? They needed to know so they could decide what they wanted to do next. Remember, above we already declared the file in question as “gpu”.

[CODE]
// read the file for the current status
try {
FileInputStream fIn = new FileInputStream(gpu);
BufferedReader myReader = new BufferedReader(
new InputStreamReader(fIn));
String aDataRow = “”;
String aBuffer = “”;
while ((aDataRow = myReader.readLine()) != null) {
aBuffer += aDataRow + “\n”;
}
// get first 3 characters
String result = aBuffer.toString().substring(0, 3);

// if overvolted, tell the user
if (result.equals(“955”)) {
Toast.makeText(getBaseContext(),
“GPU is currently overvolted.”,
Toast.LENGTH_LONG).show();
} else {
// do nothing
}

// if undervolted, tell the user
if (result.equals(“935”)) {
Toast.makeText(getBaseContext(),
“GPU is currently undervolted.”,
Toast.LENGTH_LONG).show();
} else {
System.out.println(result);
}

// if default, tell the user
if (result.equals(“945”)) {
Toast.makeText(getBaseContext(),
“GPU is currently set to default.”,
Toast.LENGTH_LONG).show();
} else {
System.out.println(result);
}

myReader.close();
} catch (Exception e) {
Toast.makeText(getBaseContext(), e.getMessage(),
Toast.LENGTH_SHORT).show();
}
[/CODE]

Here we see that the reader will take a file input stream (the gpu file) and read the first few bytes of the file. This is because the file is laid out like this:

[CODE]
945000
1050000
1150000
[/CODE]

With each line being the voltage of the corresponding frequency stage. Honestly, now that I have progressed farther in my course, I could have done this part better, to check for options that were outside of my program, say, if the user had manually set the voltages. What I did, though, was knowing what my pre-set over/under/default voltages would be, I tailored this part of the code to look for one of my presets, and to tell the user what it is set to with a toast. It works well within the confines of the app, if the user only uses this app to control the voltages.

However, if the user were to use a different app (although one does not exist at present) to control the voltages, their changes may fall outside of the limited choices of my app, so this could have been done better, but for this app, it works well enough, provided this app is the only means the user uses to control the GPU voltage.

Now that the user knows the current status of the GPU voltage, I present them with buttons to choose their own voltage options. There are only 4 options, so it is a very limited selection, but they were voltage choices that seemed to work safely, and hence why I chose them. We will only look at one for brevity, but you can check them all out on my GitHub if you would like.

[CODE]
// first up, the over volt button
oVButton = (Button) findViewById(R.id.ovButton);
oVButton.setOnClickListener(new OnClickListener() {

public void onClick(View v) {
try {
// the command to run
String[] pwrUp = { “su”, “-c”, “echo ‘955000\n1150000\n1250000’ > /sys/devices/system/cpu/cpufreq/vdd_table/gpu_vdd_levels” };
Runtime.getRuntime().exec(pwrUp);
// tell the user
Toast.makeText(getBaseContext(),
“GPU overvolted by 10 mV!”,
Toast.LENGTH_SHORT).show();

} catch (IOException e) {
// tell the user the problem
e.printStackTrace();
Toast.makeText(getBaseContext(), e.getMessage(),
Toast.LENGTH_LONG).show();
}
}
});
[/CODE]

The real magic here was how to run a command as the superuser so the program would be able to write to that system file.

Runtime.getRuntime().exec(pwrUp); // This line actually runs the command.

String[] pwrUp = { “su”, “-c”, “echo ‘955000\n1150000\n1250000’ > /sys/devices/system/cpu/cpufreq/vdd_table/gpu_vdd_levels” }; // This line is the command. If printed, it would look like this:

su -c echo ‘955000\n1150000\n1250000’ > /sys/devices/system/cpu/cpufreq/vdd_table/gpu_vdd_levels

Remember that echo is using the apostraphe, for quotes. The “\n” portion becomes a litteral line break in the file. If you used the double quote, then the output would be a litteral one line file of:

955000\n1150000\n1250000

Which wouldn’t work at all. This is convenient, since the double quote would also end the String[] (array) and break it into more parts and cause errors. So, by clicking the over volt button, they are sending a pre-set string of voltage parameters to their GPU. This is very limiting for the user, but very simple to implement, and in a way prevents abuse of the GPU by an error or unknowledgable input by the user.

All that being said, it also requires some permissions to be built into the app, by placing them in the AndroidManifest.xml file, as you can see here:

[CODE]
<?xml version=”1.0″ encoding=”utf-8″?>
<manifest xmlns:android=”http://schemas.android.com/apk/res/android&#8221;
package=”com.alaskalinuxuser.gvc” >
<uses-permission android:name=”android.permission.ACCESS_SUPERUSER” />
<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />

<application
android:allowBackup=”true”
[/CODE]

Notice the two “uses-permission” lines. The app has access to the superuser, and the permission to write (and consequently read) to/from files. Technically, I am not sure that I need the write permission, since the writing is done by the super user, however, I do need to read the file in question, so at a minimum, I would change this to READ_EXTERNAL_STORAGE.

I hope all of my scribbles make sense! Granted, there are probably much better ways to do this, and I hope to improve as I continue to build apps.

Linux – keep it simple.

How to add an I/O Scheduler to your kernel

How to add an I/O Scheduler to your kernel:

Praise God, another succesful addition to the TBLTE kernel was that of adding the FIOPS I/O scheduler to the kernel. What is an I/O scheduler? Well it is the part of the kernel that handles, or schedules, input and output. Particularly, this has to do with writing and reading to and from media, like your hard drive, flash drive, etc.

So, how do we do that? How do we add I/O schedulers to our kernel?

Well, for the TBLTE kernel, I will show you what I did, and you can add to your kernel similarly.

Go to the block folder in your kernel source. The first thing that you need to do is add the fiops-iosched.c file. Whatever I/O scheduler you want to add will be named like this: {NAME-iosched.c} you can search Google or github for them, or take them from my source if you would like.

Once you put your fiops-iosched.c file in your kernel’s ./block/ folder, you can now edit two other files in that folder. You need to add the new scheduler to the make file, so it knows to make it, you can do that like so:

Open ./block/Makefile and add this line after the other *-iosched.o lines:

[CODE]
obj-$(CONFIG_IOSCHED_FIOPS) += fiops-iosched.o
[/CODE]

Notice that it just uses the name of the iosched file, but with an “.o” extension instead of a “.c” extension. The “.c” file you added earlier will create a “.o” (object) file that the Kernel needs to use to “make” the kernel.

Now edit the ./block/Kconfig.iosched file like so:

[CODE]
config IOSCHED_FIOPS
tristate “FIOPS I/O scheduler”
default y
—help—
The FIOPS I/O scheduler. WJH.
[/CODE]

This way, when you are moddifying your configuration, you can select to build it. Notice that it is a “default y”, essentially, I am telling the config file creator to allways assume I want to build this, unless I choose not to. You can also eddit the “—help—” portion to say anything you want. I put my initials in there so I can find it easily with the search tool.

Now open your configuration file. For the stock builds, that would be ./arch/arm/configs/ap88084_sec_defconfig, and add this line:

[CODE]
CONFIG_IOSCHED_FIOPS=y
[/CODE]

Note that you could also do this through

[CODE]$ make menuconfig [/CODE]

.
You may also note, since we gave it a “default y” in the Kconfig.iosched file, we don’t actually need to add this to our configs, as it will be built by default, but I like to declare what I am building in my configs so I remember what I am doing.

There you go! Now when you build your kernel again, the FIOPS I/O scheduler will be added in. It is remarkably simple, just the way I like it. You can read the commit here: [url]https://github.com/alaskalinuxuser/kernel_samsung_tblte/commit/f80320a895612bd1379ca789f88f1d6dfd6e68f9[/url]

Linux – keep it simple.