Profile

Cover photo
Android Developers
2,107 followers|28,546 views
AboutPostsPhotosVideos

Stream

Android Developers

Shared publicly  - 
 
Created a new community for Android Developers, now with working Link!
Android Developers
A home for every Android Developer
View community
4
Marcus Hamilton's profile photo
 
Broken link?
Add a comment...

Android Developers

Shared publicly  - 
 
 
Nexus 4, Nexus 10, Android 4.2: an exclusive first look from inside Google HQ 
#nexus4   #nexus7 #android42  
 ·  Translate
3
1
StartApp's profile photo
Add a comment...

Android Developers

Shared publicly  - 
 
Hey Android Fans, with the new changes to the Google Plus Page Settings its possible to define Managers to a Page.
If you interested in writing Android Developer News and Infos around Android please leave us a Message with your Google Mailadress.
2
Will Smith's profile photoAndroid Developers's profile photoJames Patillo's profile photoAshish Mohite's profile photo
5 comments
 
K
Add a comment...

Android Developers

Shared publicly  - 
 
Today Chrome for Android was released, unfortunately only for Android ICS Devices. If you own a 4.0 Device grab it while its hot!
1
Add a comment...

Android Developers

Shared publicly  - 
 
That are some awesome News!
Rupert Rawnsley originally shared:
 
The Android SDK Manager (which is a download manager for Android developers) just added Sources for Android SDK to the latest release. This allows you to easily step through the source code when debugging, which was sort of possible before, but frankly a huge hassle to get working.

According to cryptic comment 149 near the bottom of this discussion http://code.google.com/p/android/issues/detail?id=979, they will be adding this to all releases going forward, but not retrospectively.
4
1
Michele Corazza's profile photoSteve Webb's profile photo
3 comments
 
Well you can add this as a plugin (install software under eclipse) http://adt-addons.googlecode.com/svn/trunk/source/com.android.ide.eclipse.source.update/ that will look after it for you prior to 14.
Add a comment...

Android Developers

Shared publicly  - 
 
Vic Gundotra originally shared:
 
A growth rate of more than one billion app downloads per month.

Wow.
1
Add a comment...
Have them in circles
2,107 people
Hiago Mendes's profile photo
ITM Telco Network's profile photo
Sony CS's profile photo
Jonas Lund's profile photo
bahaa shaikh's profile photo
Omar J's profile photo
vincenzo carrino's profile photo
Nguyen Manh Tuan's profile photo
Ran Duan's profile photo

Android Developers

Shared publicly  - 
 
Just created a Android Developers community. Feel free to Join!
https://plus.google.com/communities/101922091538507902725
Android Developers
A home for every Android Developer
View community
7
dustin evans's profile photoRoberto Girelli's profile photoTomi Urankar's profile photoAndroid Developers's profile photo
9 comments
 
+Roberto Girelli  The G+ app doesnt support communities yet
Add a comment...

Android Developers

Shared publicly  - 
 
A fresh Look for the Developer Site
 
Android Developer Site Redesign

Every year Google I/O means there are plenty of new eyes on the Android Developer Site, so we've taken the opportunity of this year's I/O to update developer.android.com to provide a more streamlined, simplified, and focused experience. 

As developers, our tasks fall into three baskets: Design, develop, and distribute; so we've restructured developer.android.com to reflect this.

We'll be sharing more tips to help you design, develop, and distribute your apps at Google #IO12 , with all sessions being recorded and many of them live streamed during the event.

What do you think of our new look?
The official site for Android developers. Provides the Android SDK and documentation for app developers and designers.
2
Add a comment...

Android Developers

Shared publicly  - 
5
1
Ahmed Jannen's profile photoJaiprakash soni's profile photo
 
Hello Sir/Mme, I initiated a small company in kairouan-Tunisia concerbed with the creation and develloppment of android application and in 10 days i will start a school to teach the android, hoping to make it more important in my city and my country and help people to bring their best in developping android application. However the field of knowldge is still always narrow while i am sure that me and my employees can give more , i hope that you can support us , help us and hopefully be our guests here in tunisia to have the chance to lean some of your skills and listen to you lectures. This country is always ready for more once we can give it more. thank you for your time .

Sincerly
Ahmed jannen
Kairouan-Tunisia
ahmed.jannen@cyberi-tech.com
+216 21 280 093
Add a comment...

Android Developers

Shared publicly  - 
 
New Android Design Site check this out: http://developer.android.com/design/index.html

Nice new Styleguide with a lot of valueable Tipps & Tricks
New in Android 4.0 · Gestures · App Structure · Navigation · Action Bar · Multi-pane Layouts · Swipe Views · Selection · Notifications · Compatibility · Pure Android · Building Blocks · Tabs · Lists ·...
3
2
BitMind's profile photoDr. Micheal Burns, MAEd, EdD (Mike Burns)'s profile photo
Add a comment...

Android Developers

Shared publicly  - 
 
Android Lint for ADT 16 is out. Comment below if you tried it yet. Are the tips/optimizations helpful?
http://tools.android.com/tips/lint
2
1
Kyaw Kyaw Zin's profile photoSteve Webb's profile photo
 
How to change app permission on android
Add a comment...

Android Developers

Shared publicly  - 
 
Dianne Hackborn originally shared:
 
How about some Android graphics true facts?

I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:

• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.

• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.

• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.

• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.

• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)

• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.

• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.

• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.

• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.

• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)

• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.

• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
2
Christian Jackson's profile photo
 
Nice encouraging words
Add a comment...
People
Have them in circles
2,107 people
Hiago Mendes's profile photo
ITM Telco Network's profile photo
Sony CS's profile photo
Jonas Lund's profile photo
bahaa shaikh's profile photo
Omar J's profile photo
vincenzo carrino's profile photo
Nguyen Manh Tuan's profile photo
Ran Duan's profile photo
Links
Story
Tagline
Android Developers
Introduction
This is a place for all Android Developers all over the World.
Feel free to follow to get the lastest Android Developer related News!

@All Android Developers, as soon a page can get multiple Admins we can give away write access. For the meantime i share related posts from our followers.