15 Sep 2014

feedPlanet Maemo

2014-09-09 Meeting Minutes

Meeting held 2014-09-09 on FreeNode, channel #maemo-meeting (logs)

Attending: Gido Griese (Win7Mac), Paul Healey (sixwheeledbeast), Jussi Ohenoja (juiceme), Niel Nielsen (nieldk), Peter Leinchen (peterleinchen)

Absent: Joerg Reisenweber (DocScrutinizer05)

Summary of topics (ordered by discussion):


Topic (Certificate issue on wiki.m.o):

Topic (Security check on m.o):

Topic (Transition to Maemo e.V., referendum and membership registration):


Action Items:
  • Sixwheeledbeast to clarify the CSS issue on wiki.maemo.org with techstaff.
  • juiceme to create a wording draft for the referendum (to be counterchecked by council members).

0 Add to favourites0 Bury

15 Sep 2014 6:35pm GMT

2014-09-02 Meeting Minutes

Meeting held 2014-09-02 on FreeNode, channel #maemo-meeting (logs)

Attending: Craig Woodward (Woody14619), Gido Griese (Win7Mac), Ruediger Schiller (chem|st), Paul Healey (sixwheeledbeast), Jussi Ohenoja (juiceme), Philippe Coval (rZr), Niel Nielsen (nieldk), Peter Leinchen (peterleinchen)

Absent: Joerg Reisenweber (DocScrutinizer05)

Summary of topics (ordered by discussion):


Topic (NielDK's resignation):

Topic (Discussion on Maemo e.V. and Council rules):

Topic (Code of Conduct):


Action Items:
  • N/A

0 Add to favourites0 Bury

15 Sep 2014 6:34pm GMT

2014-08-26 Meeting Minutes

Meeting held 2014-08-26 on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer05), Jussi Ohenoja (juiceme), Philippe Coval (RzR), Peter Leinchen (peterleinchen)

Partial: (lbt), (xes), Gido Griese (Win7Mac)

Absent: Niel Nielsen (nieldk)

Summary of topics (ordered by discussion):


Topic (handling of MoMs):

Topic (community input):

Topic (x-fade contact about IRC):


Action Items:
  • N/A

0 Add to favourites0 Bury

15 Sep 2014 6:33pm GMT

2014-08-19 Meeting Minutes

Meeting held 2014-08-19 at 20:00 UTC on FreeNode, channel #maemo-meeting (logs)

Attending: Paul Haley (sixwheeledbeast) Joerg Reisenweber (DocScrutinizer05), Niel Nielsen (nieldk), Philippe Coval (RzR)

Partial: (xes)

Absent: Jussi Ohenoja (juiceme), Peter Leinchen (peterleinchen)

Summary of topics (ordered by discussion):


Topic (new MC e.V. structure, roles of HiFo/MC e.V. and Council):

Topic (karma calculation):

Topic (coop/friend with Jolla):


Action Items:
  • Check if karma calculation/evaluation is fixed.
  • NielDK to prepare a draft for letter to Jolla.

0 Add to favourites0 Bury

15 Sep 2014 6:32pm GMT

2014-08-12 Meeting Minutes

2014-08-12 Meeting Minutes

Meeting held 2014-08-12 on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer05), Jussi Ohenoja (juiceme), Philippe Coval (RzR), Peter Leinchen (peterleinchen)

Partial: (lbt), (xes), Gido Griese (Win7Mac)

Absent: Niel Nielsen (nieldk)

Summary of topics (ordered by discussion):


Topic (IRC channel operator priviliges):

Topic (Discussion on Council writing an introductory letter to Jolla):

Topic (Discussion on a place for Maemo e.V. related documents):

Topic (Discussion on the change to Maemo landing-page):


Action Items:
  • N/A

0 Add to favourites0 Bury

15 Sep 2014 6:31pm GMT

2014-08-05 Meeting Minutes

Meeting held 2014-08-05 at 20:00 UTC on FreeNode, channel #maemo-meeting (logs)

Attending: Gido Griese (Win7Mac), Falk Stern (warfare),
Philippe Coval (RzR), Niel Nielsen (nieldk), Peter Leinchen (peterleinchen)

Absent: Joerg Reisenweber (DocScrutinizer05), Jussi Ohenoja (juiceme)

Summary of topics (ordered by discussion):


Topic (status of MC e.V.):

Topic (new SSL certificates):

Topic (IRC configuration/administration rights):

Topic (future of Harmattan):


Action Items:
  • nieldk setting up an email until next weeks meeting to contact Jolla board about x-fade timeframe.

0 Add to favourites0 Bury

15 Sep 2014 6:24pm GMT

2014-07-29 Meeting Minutes

Meeting held 2014-07-29 at 20:00 UTC on FreeNode, channel #maemo-meeting (logs)

Attending:

Partial: Joerg Reisenweber (DocScrutinizer05), Peter Leinchen (peterleinchen)

Absent: Jussi Ohenoja (juiceme), Philippe Coval (RzR), Niel Nielsen (nieldk)

Summary of topics (ordered by discussion):


Nothing has been discussed.

Action Items:
  • N/A

0 Add to favourites0 Bury

15 Sep 2014 6:22pm GMT

2014-07-22 Meeting Minutes

Meeting held 2014-07-22 at 20:00 UTC on FreeNode, channel #maemo-meeting (logs)

Attending: Ruediger Schiller (chem|st), (xes),
Jussi Ohenoja (juiceme), Philippe Coval (RzR), Peter Leinchen (peterleinchen)

Partial: Joerg Reisenweber (DocScrutinizer05)

Absent: Niel Nielsen (nieldk)

Summary of topics (ordered by discussion):


Topic (IRC cloaks):

Topic (administration of IRC channels):

Topic (certificates problem):

Topic (HiFo / MC e.V. transfer):

Topic (future of Harmattan):

Topic (listing of resources):


Action Items:
  • RzR trying to contact x-fade.

0 Add to favourites0 Bury

15 Sep 2014 6:13pm GMT

12 Sep 2014

feedPlanet Maemo

profiling is not understanding

When software goes slow, generally, the first reaction is to profile. This might be done through system tools (like Instruments on OS X, perf/valgrind/etc on Linux, VTune, etc). This is fine and good, but just because you have the output of a tool does not necessarily correlate to understanding what is going on.

This might seem like an obvious distinction, but all too often, efforts at improving performance focus on the small picture ("this thing here is slow") and not the bigger picture ("why is this so slow"). At Jolla, I had the pleasure of running into one such instance of this, together with Gunnar Sletta, my esteemed colleague, and friend.

As those of you who are familiar with Jolla may know, we had been working on upgrading to a newer Qt release. This also involved quite a bit of work for us, both in properly upstreaming work we had done on the hurry to the late-2013 release, and in isolating problems and fixing them properly in newer code (the new scenegraph renderer, and the v4 javascript engine in particular have been an interesting ride to get both at once!).

As a part of this work, we noted that touch handling was quite slow (something which we had worked around for our initial release, but now wanted to solve properly). This was due to the touch driver on the Jolla introducing touchpoints faster than the display was updating, that is, while the display might be updating at 57 hz (yes, the Jolla is weird, it doesn't do 60 hz) - we might be getting input events a lot more frequently than that.

This was, in turn, causing QtQuick to run touch processing (involving costly item traversals, as well as the actual processing of touch handling) a lot more frequently than the display was updating. As these took so much time, this in turn slowed rendering down, meaning even more touch handling was going on per frame. A really ugly situation.

Figure 1: Event tracing inside the Sailfish OS Compositor

Figure 1 demonstrates this happening at the compositor level. The bottom slice (titled "QThread") is the event delivery thread, responsible for reading events from evdev The peaks there are - naturally - when events are being read in. The top thread is the GUI thread, and the high peaks there are touch events being processed and delivered to the right QtQuick item (in this case, a Wayland client, we'll get to that later). The middle slice is the compositor's scenegraph rendering (using QtQuick).

With the explanation out of the way, let's look at the details a bit more. It's obvious that the event thread is regularly delivering events at around-but-not-quite twice the display update. Our frame preparation on the GUI thread looks good, despite the too-frequent occurrence of event delivery, though, and the render thread is coping too.

But this isn't a major surprise - the compositor in this case is dead simple (just showing a fullscreen client). What about the client? Let's take a look at it over the same timeframe...

Figure 2: Event tracing for the client (Silica's component gallery, in this case)

Figure 2 focuses on two threads in the client: the render thread (top), and the GUI thread (bottom). Touch events are delivered on the GUI thread, QtQuick processes them there while preparing the next frame for the render thread.

Here, it's very clear that touch processing is happening way too often, and worse than that, it's taking a very long time (each touch event's processing is taking ~4ms), not leaving much time for rendering - and this was on a completely unloaded device. In a more complicated client still, this impact would be much, much worse, leading to frame skipping (which we saw, on some other applications).

Going back to my original introduction here, if we had used traditional profiling techniques, we'd have seen that touch handling/preparation to render was taking a really long time. And we might have focused on optimizing that. Instead, thanks to some out-of-the-box thinking, we looked at the overall structure of application flow, and were able to see the real problem: doing extra work that wasn't necessary.

As an aside to this, I'm happy to announce that we worked out a neat solution to this: QtQuick now doesn't immediately process touch events, instead, choosing to wait until it is about to prepare the next frame for display - as well as "compressing" them to only deal with the minimal number of sensible touch updates per frame. This should have no real impact on any hardware where touch delivery was occurring at a sensible rate, but for any hardware where touch was previously delivering too fast, this will no longer be a problem as of Qt 5.4.

(Thanks to Gunnar & myself for the fix, Carsten & Mikko for opening my eyes about performance tooling, and Jolla for sponsoring this work.

P.S. If you're looking for performance experts, Qt/QML/etc expertise or all round awesome, Gunnar and myself are currently interested in hearing from you.)0 Add to favourites0 Bury

12 Sep 2014 6:06pm GMT

11 Sep 2014

feedPlanet Maemo

SlimPort on Android or getting a free FireTV

SlimPort is a feature of Nexus devices which is unfortunately not covered much in reviews. It is still a quite important feature - especially for those who are interested in getting Amazon Instant Video from the phone on the big screen.
Basically SlimPort is DisplayPort over the Micro-USB connection of your device allowing you to mirror its display.

But the future has arrived: we got Miracast!

One might wonder why one should go through the hassle of using a old-school HDMI cable.
You can get a Chromecast Stick for 35$ and nowadays it also supports Miracast so you can simply stream the images over WiFi.

Well Miracast is all nice if all you need to do is to put up some slides without carrying all possible adapters with you. But as soon as you try to stream a movie or a game you will reach its limitations.

Remember that Miracast works by grabbing the Framebuffer and compressing it with H.264. While encoding happens in hardware it still takes some time and it inevitably introduces compression artifacts. This means:

Going old-school

Going with the old-school cable on the other hand you get HDMI 1.4 transfer rates for up to 1080p at 60Hz while saving the battery.

Configuring the second screen is quite straightforward in android. As Mirroring is your only option, there is actually nothing to configure. Once you connect the adapter android will set up your monitor based on its EDID information and transfer image and audio over HDMI.
In case you only want to have the image over HDMI, simply attach your speakers to the phone and android will re-route the audio.
The days where you had to manually set up everything are over.

Furthermore most adapters have an micro-USB port allowing to still charge your phone while using SlimPort.

The free FireTV

Well it took Amazon long enough to finally release Instant Video for android - although their Fire devices share almost the same software stack. And even then they still left out Chromecast support. Amazon is clearly trying to push their own devices.
And it kind of works out - the FireTV for the launch price of 50€ is a steal. (The comparable Odroid U3 is 100€+ and that is w/o any remote)

But still it is 50€ if all you want is to get Instant Video on the big screen. Using the SlimPort of your device you get there. And for the saved money you can get a Bluetooth Gamepad/ Keyboard get some more FireTV functionality out of your android device.

Device Support

The downside is that most of the devices do not support SlimPort. The device list more or less boils down to

Samsung devices go with the alternative MHL. Comparing these two SlimPort has the bandwidth advantage of 5Gb/s vs. 3Gb/s of MHL.

0 Add to favourites0 Bury

11 Sep 2014 10:37pm GMT

01 Sep 2014

feedPlanet Maemo

PADI Rescue diver

For this one I worked really hard. Buddy breading, relaxing people in panic at 20 meters deep, keeping yourself cool. And that in Belgian waters (no visibility and freezing cold). We simulated it all. It was harder than most other things I did in my life.

0 Add to favourites1 Bury

01 Sep 2014 4:25pm GMT

27 Aug 2014

feedPlanet Maemo

Plastic surgery Discussed

header_plastic-surgeryThere are people who wonder why they have impairments in life. These impairments or dysfunctions results to a varied negative impacts to several people. These includes traumas, burns, congenital defects, developmental abnormalities, infections and diseases, and tumors and cancer. These cases leads many people having these a great alteration n their life. With this condition they might not be able to perform normal activities of daily living. In addition to that, emotional effects are a huge factor on their inability to continue life normally. One may be embarrassed, bullied, or even abused of their condition by some people. Low self-confidence and self-esteem would result in cases like these. As time passed and technology grows, fortunately, there are several discoveries which lead to make a solution to these problems.

Basic facts

Plastic Surgery on its simplest sense, helps these people revive the normality of their being. With plastic surgery they can have the life that they always wanted. Away from those abusers and humiliating people. Plastic surgery or also known as reconstructive surgery performs various procedure to correct the imperfections or dysfunctions of a human being. In case of a congenital defect such as cleft lip, cleft palate and other defects, it is best addressed as soon as possible so as not to give the baby a hard time growing up. The developmental stage of a person is a big factor to its whole well-being so that makes the parents to make a prompts decision in those cases. As for the other impairments, there's no better time of treating a condition but now if also allowed and ordered by a Physician.

Guide to success

cosmetic-surgery-1In the verge of deciding to have the condition treated, you must choose the most suitable person to perform the procedure. Plastic surgeon have undergone a wide range of education, trainings, and experiences. For a certain condition, it is best to look for the Plastic Surgeon who has performed that specific procedure numerous times. Always remember that nothing beats repetition as a successful way of mastery. If you have chosen your surgeon already it is also necessary to choose the best hospital where the procedure will be performed. Sanitation and cleanliness of the hospital is a great factor on the success of the operation. Also, caring and loving hospital staffs works best on the success of the surgery and recovery. So always consider many things and not be like an impulsive buyer and regret in the end because this is not shopping but a lifetime change of a human being.

Our generation is very fortunate that several people have discovered many things already and we can benefit from them now. Aside from all of that discussed, personal attitude and view of life are still the most important elements of life. One can be happy beyond its imperfections if only he or she knows how to handle the situation and views life positively. Having a good attitude towards life and others can make your life worth living till the end.

0 Add to favourites1 Bury

27 Aug 2014 5:02am GMT

13 Aug 2014

feedPlanet Maemo

sailing in search of fresh waters

I've had a long, quiet time on this blog over the past few years while I've been frantically helping Jolla to launch their self-named product: the Jolla. I've enjoyed (almost) every day I've been there: they really are a great bunch of people and the work has been plentiful and challenging.

But as the saying goes, "this too shall pass". Nothing lasts forever, and it's time for a change: after this week, I will be taking a break from Jolla to get some fresh perspective.

On the bright side, maybe I'll have some more time for writing now :)

If anyone is interested in getting a hold of a C++/Qt/QML/Linux expert with a focus on performance, expertise on mobile, and a wide range of knowledge across other areas who loves open source, please let me know.0 Add to favourites1 Bury

13 Aug 2014 11:55am GMT

02 Aug 2014

feedPlanet Maemo

Problem on linking OpenSSL into your NDK application

This week, I tried to compile a simple NDK application and link it with the OpenSSL library. Most of libraries (including OpenSSL) are not supported by the NDK, what makes it a bit more complicated to use. So, in this post, I describe what I usually do to properly compile applications that need external libs.

The project structure is as follows:

my_project/
+ jni/my_code.c
+ jni/Android.mk
+ jni/Application.mk
+ libs/system

Problem #01: How my Android.mk looks like?

In this example, I need two libraries: libcrypto.so and libssl.so. So, the final Android.mk looks like this

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE := my_exec
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := my_code.c
LOCAL_C_INCLUDES += $(ANDROID_SRC)/external/openssl/include \
$(ANDROID_SRC)/external/openssl/crypto \
$(KERNEL_SRC)/kernel/module
LOCAL_LDLIBS += -L$(LOCAL_PATH)/../libs/system
LOCAL_SHARED_LIBRARIES := libandroid libdl libz libcrypto libssl
LOCAL_LDLIBS += -landroid -ldl -lz


include $(BUILD_EXECUTABLE)


See, as an example, that we also include the headers for the library (in ANDROID_SRC/external/openssl/include).

NDK does not provide support for libcrypto.so and libssl.so -- we need to have access to the libraries somehow. So, you should create a folder (for example, my_project/libs/system) and push the files /system/lib/libcrypto.so and /system/lib/libssl.so from the device to such folder.

Problem #02: Where do I get the libs from?

You shall get all of them (including libc.so) from your rooted device. The point is that, as I said, NDK does not provide support for libcrypto.so and libssl.so. Therefore, you need to get such libraries from the device. However, there's another problem: most likely, the libcrypto.so and libssl.so libraries don't recognize the symbols from the NDK libc.so and libstdc++.so libraries. Regarding this problem, it will be discussed on item #04.

Problem #03: Where do I get the headers from?

Usually, you get them from the android source code. For OpenSSL, they are located inside the folder ANDROID_SRC/external.

Problem #04: Why does my lib complain about libc symbols?

As I described in topic #02, you need to copy the libraries from the device. However, libcrypto.so and libssl.so do not recognize some symbols from the libc.so and libstdc++.so libraries (most likely, the libraries provided by NDK are not compatible with the ones in the device). Usually, you will have the following compilation error:

/home/raul/android-ndk-r10/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/raul/my_project/jni/../libs/system/libcrypto.so: error: undefined reference to '__strlen_chk'
/home/raul/android_development/android-ndk-r10/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/raul/my_project/jni/../libs/system/libcrypto.so: error: undefined reference to '__memcpy_chk'
/home/raul/android_development/android-ndk-r10/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/raul/my_project/jni/../libs/system/libcrypto.so: error: undefined reference to '__memset_chk'
/home/raul/android_development/android-ndk-r10/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld:
/home/raul/my_project/jni/../libs/system/libcrypto.so: error: undefined reference to '__strchr_chk'
/home/raul/android_development/android-ndk-r10/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-
x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/raul/my_project/jni/../libs/system/libcrypto.so: error: undefined reference to '__strcat_chk'


That's easy to solve. Here comes the trick: you have to replace NDK's libraries by those ones from the device. NDK contains several libraries for distinct platforms, as we can see from the path NDK_FOLDER/platforms:

@desktop:$ ls NDK_FOLDER/platforms
android-12 android-13 android-14 android-15 android-16 android-17
android-18 android-19 android-3 android-4 android-5 android-8 android-9

Considering that your application is using NDK for platform android-17 (you can define that in file Application.mk), replace the main libraries of folder NDK_PATH/platforms/android-17

@desktop:$ ls NDK_FOLDER/platforms/android-17/arch-arm/usr/lib
crtbegin_dynamic.o crtend_android.o libc.a libEGL.so libjnigraphics.so libm_hard.a libOpenSLES.so libthread_db.so
crtbegin_so.o crtend_so.o libc.so libGLESv1_CM.so liblog.so libm.so libstdc++.a libz.so

crtbegin_static.o libandroid.so libdl.so libGLESv2.so libm.a libOpenMAXAL.so libstdc++.so

So, push the libraries /system/lib/libc.so, and /system/lib/libstdc++.so from the device to the folder NDK_FOLDER/platforms/android-17/arch-arm/usr/lib. After that, compile the application again and voilà -- all problems solved :-)


0 Add to favourites0 Bury

02 Aug 2014 4:32pm GMT

28 Jul 2014

feedPlanet Maemo

Android image/kernel building/flashing - A *VERY* short guide :-)

This week, I had to go through the process of Android OS/Kernel building/installation. And it was a lot much better and 6 months ago (maybe, because I built it for a device and not for the emulator?). I compiled the images in Ubuntu 12.04 and I used a Samsung Galaxy Nexus device (maguro with tuna as kernel). Therefore, I decided to summarize the steps that I took. This mini-tutorial is a lot shorter and simpler (and really works!!).

1. Android OS

1.0 Setting up the building environment

Check this instructions (here and here) to set up the basic environment and download the code. I used the branch [android-4.3_r1.1].

1.1 Compiling the Android OS

a. Download and unpack the manufacturer drivers from this link. They have to be unpacked into the directory [android_source_code]/vendors -- but don't worry, as the .zip files contain a script that does all the work for you.

b. Once the drivers are in the proper place, run the following commands:

@desktop:$ cd [android_source_code]
@desktop:$ make clobber
@desktop:$ lunch full_maguro-userdebug
@desktop:$ make -j4

It takes a long time to compile the image.

After these steps, the Android OS is ready.

1.2 Flashing the device with the new Android OS

Now, you need two tools from the Android SDK: adb and fastboot. These tools are located in the folder [androis_sdk]/platform-tools.

a. Reboot the device in the bootloader mode -- hold VolumeDown and VolumeUp and then press the PowerUp button.

b. Connect the USB cable.

c. Run the following commands:

@desktop:$ export PATH=$PATH:[android_sdk]/platform-tools
@desktop:$ cd [android_source_code]
@desktop:$ sudo fastboot format cache
@desktop:$ sudo fastboot format userdata
@desktop:$ sudo ANDROID_PRODUCT_OUT=[android_source_code]/out/target/product/maguro/ fastboot -w flashall

After these steps, reboot the device. A clean installation will take place. To check the new version of you device, go to "Settings" - - > "About Phone" and check "Model number": now, it should be "AOSP on Maguro" (check attached image)



2. Android Kernel

Ok. Now, we have the AOSP in place and we need to compile a new kernel. But why do you need to compile and install a new kernel? Oh, well, let's say that you want to apply some patches or that you need to change the kernel to enable Linux module support (the default Android Linux Kernel does not support modules).

2.0 Setting up the building environment

If you have built the Android OS before, you don't need anything special for the kernel building. I used the official code from https://android.googlesource.com/kernel/omap.git, branch android-omap-tuna-3.0-jb-mr2.

2.1 Compiling the Kernel

First, you need to set some variables that are important for the building process (ARCH and CROSS_COMPILE):

@desktop:$ export ARCH=arm
@desktop:$ export CROSS_COMPILE=[android_source_code]/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-

Now, you have to generate a .config which contains all the options for the kernel building. By running the following command you generate a basic .config file for Android.

@desktop:$ cd [android_kernel_code]
@desktio:$ make tuna_defconfig

Sometimes, you need to set some specific entries of the .config to enable/disable certain features of the kernel. For this specific example, let's set the option CONFIG_MODULES to y (the entry in the .config file should be CONFIG_MODULES=y). With CONFIG_MODULES set to y, it is possible to insert/remove kernel modules. Now, let's build the kernel

@desktop:$ cd [android_kernel_code]
@desktop:$ make

(it takes some time to compile the kernel)

2.2 Preparing the kernel for installation

The kernel image is almost ready: it's still necessary to wrap it up properly to flash it into the device. The Android source code contains scripts that do the work for us. Consider that the image was generated at [android_kernel_code]/arch/arm/boot/zImage.

@desktop:$ cd [android_source_code]
@desktop:$ export TARGET_PREBUILT_KERNEL= [android_kernel_code]/arch/arm/boot/zImage
@desktop:$ make bootimage

At the end, a custom image is ready for installation at [android_source_code]/out/target/product/maguro/boot.img

2.3 Flashing the device with the new Kernel

Now, everything is in place and we can finally flash our kernel image. To do so:

a. You need to boot the device in bootloader mode (hold VolumeDown and VolumeUp and then press the PowerUp button)

b. Connect the USB cable


c. Run the following commands


@desktop:$ cd [android_source_code]
@desktop:$ sudo ANDROID_PRODUCT_OUT=[android_source_code]/out/target/product/maguro/ fastboot flash boot [android_source_code]/out/target/product/maguro/boot.img

After these steps, reboot the device. A clean installation will take place. To check the new version of you kernel, go to "Settings" - - > "About Phone" and check "Kernel version": you will see a different name for you kernel image (as for the previuos image).


0 Add to favourites0 Bury

28 Jul 2014 7:06pm GMT

25 Jul 2014

feedPlanet Maemo

Firefox for Android: Collecting and Using Telemetry

Firefox for Mobile
Firefox for Android: Collecting and Using Telemetry - http://starkravingfinkle.org/blog...

0 Add to favourites0 Bury

25 Jul 2014 3:08am GMT