Using git tools…

While working on the android code. I find difficulty when i want to remove my changes or want to check what I have changed in the last 5-6 day.

While searching the Internet I find git tools as a good option for this purpose. Even once initialized the git there is not need of internet connection to check the diff with the original code.

Following are the links may be useful. 

Android’s repo and git  document http://source.android.com/source/version-control.html

A comprehensive docs on http://book.git-scm.com/3_comparing_commits_-_git_diff.html

regards

Y$

Posted in git | Leave a comment

using gdb with android emulator.

One of the biggest challenge ,I face while working on Browser in Android Platform is ‘GDB’. Many time I have to check the stack strace of the call to native function.

Here is one method which make your debugging native easy on android emulator.

1) First of all customize you .gdbinit file, so that till will include the essensial libs at the time you start you gdb.

file out/target/product/generic/symbols/system/bin/app_process
set solib-absolute-prefix out/target/product/generic/symbols
set solib-search-path out/target/product/generic/symbols/system/lib

2) Create a script for lunch arm-gdb  and gdbserver.

echo ‘Usage :bash gdbemu.sh <browser-pid>’
echo ‘———————————————–‘
echo ‘TCP forward done…’
echo adb forward tcp:5039 tcp:5039
adb forward tcp:5039 tcp:5039
echo ‘———————————————–‘
echo adb shell ps | grep browser
VAR=`adb shell ps | grep browser | awk ‘{print $2}’`
echo $VAR
echo ‘Starting gdbserver….’
echo adb shell gdbserver :5039 –attach $VAR &
adb shell gdbserver :5039 –attach $VAR &
echo ‘Starting gdb………..’
./prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gdb

 

Note:- This script working only then you script is in the root folder of the android code.

 

All is set now lunch the emulator , then browser and  run this script. If you feel any problem while setup this enviroment please comment.

 

 

Posted in android, Debugging Native Libary | Leave a comment

vi advance settings

Vi is one of the most standard and powerfull tools for programmers. You can also customize the vi editor as per your need. following is my vi setting file.

if has(“autocmd”)
  filetype plugin indent on
endif

set incsearch  ” Incremental search

set mouse=a  ” Enable mouse usage (all modes)

syntax on

filetype indent plugin on

set wildmenu

set showcmd

set hlsearch

set backspace=indent,eol,start

set ruler
set nu
set expandtab
set statusline=%F%m%r%h%w[%L][%{&ff}]%y[%p%%][%04l,%04v]
set laststatus=2 ” always show the status line

You can  edit your  .vimrc file in your home directory.

Posted in Uncategorized | Tagged | Leave a comment

GL Architecture for webkit on android

 GL Architecture To draw things, WebView use a tree of layers. The root of that tree is a BaseLayerAndroid, which may have numerous LayerAndroid over it. The content of those layers are SkPicture, the content of the BaseLayer is an PictureSet. When drawing, we therefore have one large “surface” that is the BaseLayer, and (possibly) additional surfaces (usually smaller), which are the LayerAndroids. The BaseLayer usually corresponds to the normal web page content, the Layers are used for some parts such as specific divs (e.g. fixed position divs, or elements using CSS3D transforms, or containing video, plugins, etc.).

*** NOTE: The GL drawing architecture only paints the BaseLayer for now.

The rendering model is to use tiles to display the BaseLayer (as obviously a BaseLayer’s area can be arbitrarly large). The idea is to compute a set of tiles covering the viewport’s area, paint those tiles using the webview’s content (i.e. the BaseLayer’s PictureSet), then display those tiles. We check which tile we should use at every frame.

Overview

The tiles are grouped into a TiledPage — basically a map of tiles covering the BaseLayer’s surface. When drawing, we ask the TiledPage to prepare() itself then draw itself on screen. The prepare() function is the one that schedules tiles to be painted — i.e. the subset of tiles that intersect with the current viewport. When they are ready, we can display the TiledPage. Note that BaseLayerAndroid::drawGL() will return true to the java side if there is a need to be called again (i.e. if we do not have up to date textures or a transition is going on). Tiles are implemented as a BaseTile. It knows how to paint itself with the PictureSet, and to display itself. A GL texture is usually associated to it. We also works with two TiledPages — one to display the page at the current scale factor, and another we use to paint the page at a different scale factor. I.e. when we zoom, we use TiledPage A, with its tiles scaled accordingly (and therefore possible loss of quality): this is fast as it’s purely a hardware operation. When the user is done zooming, we ask for TiledPage B to be painted at the new scale factor, covering the viewport’s area. When B is ready, we swap it with A.

Texture allocation

 Obviously we cannot have every BaseTile having a GL texture — we need to get the GL textures from an existing pool, and reuse them. The way we do it is that when we call TiledPage::prepare(), we group the tiles we need (i.e. in the viewport and dirty) into a TilesSet and call BaseTile::reserveTexture() for each tile (which ensures there is a specific GL textures backing the BaseTiles). reserveTexture() will ask the TilesManager for a texture. The allocation mechanism goal is to (in order): – prefers to allocate the same texture as the previous time – prefers to allocate textures that are as far from the viewport as possible – prefers to allocate textures that are used by different TiledPages Note that to compute the distance of each tile from the viewport, each time we prepare() a TiledPage. Also during each prepare() we compute which tiles are dirty based on the info we have received from webkit.

BaseTile Invalidation

We do not want to redraw a tile if the tile is up-to-date. A tile is considered to be dirty an in need of redrawing in the following cases – the tile has acquires a new texture – webkit invalidates all or part of the tiles contents To handle the case of webkit invalidation we store two ids (counters) of the pictureSets in the tile. The first id (A) represents the pictureSet used to paint the tile and the second id (B) represents the pictureSet in which the tile was invalidated by webkit. Thus, if A < B then tile is dirty. Since invalidates can occur faster than a full tiled page update, the tiled page is protected by a ‘lock’ (m_baseLayerUpdate) that is set to true to defer updates to the background layer, giving the foreground time to render content instead of constantly flushing with invalidates. See lockBaseLayerUpdate() & unlockBaseLayerUpdate().

 Painting scheduling

The next operation is to schedule this TilesSet to be painted (TilesManager::schedulePaintForTilesSet()). TexturesGenerator will get the TilesSet and ask the BaseTiles in it to be painted. BaseTile::paintBitmap() will paint the texture using the BaseLayer’s PictureSet (calling TiledPage::paintBaseLayerContent() which in turns calls GLWebViewState::paintBaseLayerContent()). Note that TexturesGenerator is running in a separate thread, the textures are shared using EGLImages (this is necessary to not slow down the rendering speed — updating GL textures in the main GL thread would slow things down).

Posted in android | 3 Comments

Another ways to put logs in native

The is one more simple way to put logs in native library of android. You have to following the methon as explained below.

1) First of all check weather you your lib is linking with libutils and libcutils if not just add these flags in   LOCAL_SHARED_LIBRARIES  in   your library’s Android.mk

2) Now  include #include <utils/Log.h> header file.

3) Define LOG_TAG micro with some value. You can use this value to filter logs in logcat.

  #undef LOG_TAG

#define LOG_TAG “YS”

3) After this you can use below mero functions to put logs LOGV, LOGI, LOGW, LOGF, LOGS.

for example LOGV(“This is my log statement on line %d”,__LINE__);

 

I hope this method of putting logs is more easy and simple .

Posted in Debugging Native Libary | Tagged , , | Leave a comment

Real difference between Interface and Abstract Class

I was googleing  regarding this  find interesting thing which, I want to make a note for me.

  • Java interface should be implemented using keyword “implements”; A Java abstract class should be extended using keyword “extends”.
  • An interface can extend another Java interfaces only, an abstract class can extend another Java class and implement multiple Java interfaces.
  • Interface is absolutely abstract and cannot be instantiated; A Java abstract class also cannot be instantiated, but can be invoked if a main() exists.
  • Main difference is methods of a Java interface are implicitly abstract and cannot have implementations. A Java abstract class can have instance methods that implements a default behavior.
  • Variables declared in a Java interface is by default final. An  abstract class may contain non-final variables.
  • Members of a Java interface are public by default. A Java abstract class can have default access  behavioral.

Refernce:-  JavaPapers.com

Posted in Java | Leave a comment

Putting Log in Native Code

Hi All,

This post is to put logs in the Native code  which will show in DDMS.

Following is the detail for log function for native code.

Lib Name:- liblog.so

HeaderFile:-    “android/log.h”

Function:-  int   __android_log_write(int prio, const char *tag, const char *text);

For Log Priority you can use following Value.

    ANDROID_LOG_UNKNOWN = 0,
    ANDROID_LOG_DEFAULT, /* only for SetMinPriority() */
    ANDROID_LOG_VERBOSE,
    ANDROID_LOG_DEBUG,
    ANDROID_LOG_INFO,
    ANDROID_LOG_WARN,
    ANDROID_LOG_ERROR,
    ANDROID_LOG_FATAL,
    ANDROID_LOG_SILENT,
Tag :- It is up to you which tag you want to use for filtering in DDMS.
Text:- A simple text which you use in printf format.
Now a very small example  how we can you this Log function
1) First make some changes in Android.mk file so that you can link to liblog.so.
LOCAL_LDLIBS := -llog
2) After this I just include the header file as
#include <android/log.h>

3) Define Macros as

#define  LOG_TAG    "YS" #define  LOGI(...)  __android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)
 
All is done now you can use the LOGI() macro for putting logs.
Posted in Debugging Native Libary | Leave a comment