Hi @all,
yesterday i posted a nice article about how HW Acceleration is done since honeycomb (and the difference before).
I think its a good idea to post here nice and interesting articles - this can help the devs here but the users to why
sometimes its simply impossible to code things or fix things.
Please dont spam this thread, even its in general section - let users read interesting things instead of pages full of ****
"The Reason Android is Laggy"
Dianne starts off her post with a surprising revelation:
“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.”
Hun? How can this be the case? Anybody who’s used a Nexus S knows it slows down in all but the simplest of ListViews.
And forget any semblance of decent performance if a background task is occurring, like installing an app or updating the
UI from disk. On the other hand, iOS is 100% smooth even when installing apps. But we know Dianne isn’t lying about the
potential CPU performance, so what’s going on?
The Root Cause
It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering
occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering
occurring on the main thread with normal priority.
This is a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari.
Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around.
All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is
intercepting all events and rendering the UI at real-time priority.
If you repeat this exercise on Android, you’ll notice that the browser will attempt to both animate the page and render the HTML,
and do an ‘ok’ job at both. On Android, this a case where an efficient dual core processor really helps, which is why the Galaxy
S II is famous for its smoothness.
On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until
all rendering is finished. Android tries to do both at the same priority, so the frame rate suffers. Once you notice this happening,
you’ll see it everywhere on an Android phone. Why is scrolling in the Movies app slow? Because movie cover thumbnails are
dynamically added to the movie list as you scroll down, while on iOS they are lazily added after all scrolling stops.
Other Reasons
The fundamental reason Android is laggy is UI rendering threading and priority, but it’s not the only reason. First, hardware
acceleration, despite Dianna’s reservations, does help. My Nexus S has never been snappier since upgrading to ICS. Hardware
acceleration makes a huge difference in apps like the home screen and Android market. Offloading rendering to the GPU also
increases battery life, because GPUs are fixed-function hardware, so they operate at a lower power envelope.
Second, contrary to what I claimed earlier, garbage collection is still a problem, even with the work on concurrent GC in Dalvik.
For example, if you’ve ever used the photo gallery app in Honeycomb or ICS you may wonder why the frame rate is low. It turns
out the frame rate is capped at 30 FPS because without the cap, swiping through photos proceeds at 60 FPS most of the time,
but occasionally a GC pause causes a noticeable “hiccup”. Capping the frame rate at 30 fixes the hiccup problem at the expense
of buttery smooth animations at all times.
Third, there are the hardware problems that Dianne discussed. The Tegra 2, despite Nvidia’s grandiose marketing claims, is hurt
by low memory bandwidth and no NEON instruction set support (NEON instructions are the ARM equivalent of Intel’s SSE, which
allow for faster matrix math on CPUs). Honeycomb tablets would be better off with a different GPU, even if it was theoretically
less powerful in some respects than the Tegra 2. For example, the Samsung Hummingbird in the Nexus S or Apple A4. It’s telling
that the fastest released Honeycomb tablet, the Galaxy Tab 7.7, is running the Exynos CPU from the Galaxy S II.
Fourth, Android has a ways to go toward more efficient UI compositing. On iOS, each UI view is rendered separately and stored
in memory, so many animations only require the GPU to recomposite UI views. GPUs are extremely good at this. Unfortunately, on
Android, the UI hierarchy is flattened before rendering, so animations require every animating section of the screen to be redrawn.
Fifth, the Dalvik VM is not as mature as a desktop class JVM. Java is notorious for terrible GUI performance on desktop. However,
many of the issues don’t carry over to the Dalvik implementation. Swing was terrible because it was a cross platform layer on top
of native APIs. It is interesting to note that Windows Phone 7’s core UI is built in native code, even though the original plan was to
base it entirely on Silverlight. Microsoft ultimately decided that to get the kind of UI performance required, the code would have to
be native. It’s easy to see the difference between native and bytecode on Windows Phone 7, because third party apps are written
in Silverlight and have inferior performance (NoDo and Mango have alleviated this problem and the Silverlight UIs are generally very
smooth now).
Thankfully, each of the five issues listed above is solvable without radical changes to Android. Hardware acceleration will be on all
Android phones running ICS, Dalvik continues to improve GC efficiency, the Tegra 2 is finally obsolete, there are existing workarounds
for the UI compositing problems, and Dalvik becomes a faster VM with every release. I recently asked +Jason Kincaid of +TechCrunch
if his Galaxy Nexus was smooth, and he had this to say:
“In general I've found ICS on the Galaxy Nexus to be quite smooth. There are occasional stutters — the one place where I can
consistently get jitters on the Galaxy Nexus is when I hit the multitasking button, where it often will pause for a quarter second.
That said, I find that the iPhone 4S also jitters more than I had expected, especially when I go to access the systemwide search
(where you swipe left from the home screen).”
So there you go, the Android lag problem is mostly solved, right? Not so fast.
Going Forward
Android UI will never be completely smooth because of the design constraints I discussed at the beginning:
- UI rendering occurs on the main thread of an app
- UI rendering has normal priority
Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these
two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year
old iPhone. So why did the Android team design the rendering framework like this?
Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry.
The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device.
When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI
framework.
This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they
were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and
started from scratch. Android is the only mobile OS left that existed pre-iPhone.
So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:
“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the
biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing,
possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to
this also.”
Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:
- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed
However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely
unacceptable. It should be priority #1 for the Android team.
When the topic of Android comes up with both technical and nontechnical friends, I hear over and over that Android is laggy and slow.
The reality is that Android can open apps and render web pages as fast or faster than iOS, but perception is everything. Fixing the UI lag
will go a long way to repairing Android’s image.
Beyond the perception issue, lag is a violation of one of Google’s core philosophies. Google believes that things should be fast. That’s a driving
philosophy behind Google Search, Gmail, and Chrome. It’s why Google created SPDY to improve on HTTP. It’s why Google builds tools to help
websites optimize their site. It’s why Google runs it’s own CDN. It’s why Google Maps is rendered in WebGL. It’s why buffering on Youtube is
something most of us remember, but rarely see anymore.
But perhaps the most salient reason why UI lag in Android is unacceptable comes from the field of Human-Computer Interaction (HCI). Modern
touch screens imply an affordance language of 1 to 1 mapping between your finger and animations on the screen. This is why the iOS over-scroll
(elastic band) effect is so cool, fun, and intuitive. And this is why the touch screens on Virgin America Flights are so frustrating: they are incredibly
laggy, unresponsive, and imprecise.
A laggy UI breaks the core affordance language of a touch screen. The device no longer feels natural. It loses the magic. The user is pulled out of
their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get “lost” in an iPad, but I cringe when a
Xoom stutters between home screens. The 200 million users of Android deserve better.
And I know they will have it eventually. The Android team is one of the most dedicated and talented development teams in the world. With stars like
+Dianne Hackborn and +Romain Guy around, the Android rendering framework is in good hands.
I hope this post has reduced confusion surrounding Android lag. With some luck, Android 5.0 will bring the buttery-smooth Android we’ve all dreamed
about since we first held an HTC G1. In the mean time, I’ll be in Redmond working my butt off trying to get a beautiful and smooth mobile OS some
of the recognition it deserves.
Click to expand...
Click to collapse
How do Android Apps work- Java, its compilation and role of DalvikVM
OK, here goes mine..
was researching around about the role of java in android and I found this piece of info..
it explains the way android apps work and stuff..
Visit here for the full article..
What is Java?
Android applications are developed using the Java language. As of now, that’s really your only option for native applications. Java is a very popular programming language developed by Sun Microsystems (now owned by Oracle). Developed long after C and C++, Java incorporates many of the powerful features of those powerful languages while addressing some of their drawbacks. Still, programming languages are only as powerful as their libraries. These libraries exist to help developers build applications.
Some of the Java’s important core features are:
It’s easy to learn and understand
It’s designed to be platform-independent and secure, using
virtual machines
It’s object-oriented
Android relies heavily on these Java fundamentals. The Android SDK includes many standard Java libraries (data structure libraries, math libraries, graphics libraries, networking libraries and everything else you could want) as well as special Android libraries that will help you develop awesome Android applications.
Why is Platform Independence Important?
With many programming languages, you need to use a compiler to reduce your code down into machine language that the device can understand. While this is well and good, different devices use different machine languages. This means that you might need to compile your applications for each different device or machine language—in other words, your code isn’t very portable. This is not the case with Java. The Java compilers convert your code from human readable Java source files to something called “bytecode” in the Java world. These are interpreted by a Java Virtual Machine, which operates much like a physical CPU might operate on machine code, to actually execute the compiled code. Although it might seem like this is inefficient, much effort has been put into making this process very fast and efficient. These efforts have paid off in that Java performance in generally second only to C/C++ in common language performance comparisons.
Android applications run in a special virtual machine called the Dalvik VM. While the details of this VM are unimportant to the average developer, it can be helpful to think of the Dalvik VM as a bubble in which your Android application runs, allowing you to not have to worry about whether the device is a Motorola Droid, an HTC Evo, or the latest toaster running Android. You don’t care so long as the device is Dalvik VM friendly—and that’s the device manufacturer’s job to implement, not yours.
Why is Java Secure?
Let’s take this bubble idea a bit further. Because Java applications run within the bubble that is a virtual machine, they are isolated from the underlying device hardware. Therefore, a virtual machine can encapsulate, contain, and manage code execution in a safe manner compared to languages that operate in machine code directly. The Android platform takes things a step further. Each Android application runs on the (Linux-based) operating system using a different user account and in its own instance of the Dalvik VM. Android applications are closely monitored by the operating system and shut down if they don’t play nice (e.g. use too much processing power, become unresponsive, waste resources, etc.). Therefore, it’s important to develop applications that are stable and responsive. Applications can communicate with one another using well-defined protocols.
Compiling Your Code
Like many languages, Java is still a compiled language even though it doesn’t compile all the way down to machine code. This means you, the developer, need to compile your Android projects and package them up to deploy onto devices. The Eclipse development environment (used with the Android Development plug-in) makes this pretty painless. In Eclipse, automatic compilation is often turned on by default. This means that every time you save a project file, Eclipse recompiles the changes for your application package. You immediately see compile errors. Eclipse also interprets Java as you type, providing handy code coloring and formatting as well as showing many types of errors as you go. Often, you can click on the error and have Eclipse automatically fix a typo, or add an import statement, or provide a method stub for you, saving lots of typing.
You can still manually compile your code if you so desire. Within Eclipse, you’ll find the Build settings under the project menu. If you have “Build Automatically” turned on, you can still choose the “Clean…” option that will allow you to do full rebuild of all files. If “Build Automatically” is turned off, “Build All” and “Build Project” menu options are enabled. “Build All” means to build all of the projects in the workspace. You can have many projects in an Eclipse workspace.
The build process, for regular Java projects, results in a file with the extension of JAR – Java ARchive. Android applications take JAR files and package them for deployment on devices as Android PacKage files with an extension .apk. These formats not only include your compiled Java code, but also any other resources, such as strings, images, or sound files, that your application requires to run as well as the Application Manifest file, AndroidManifest.xml. The Android Manifest file is a file required by all Android applications, which you use to define configuration details about your app.
Click to expand...
Click to collapse
And here goes another article, by an Ex-Intern Andrew Munn who worked on the android project..
i just post the link here, its a huge article...
Follow up to “Android graphics true facts”, or The Reason Android is Laggy
Click to expand...
Click to collapse
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
D3oDex3D_Ayush717 said:
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
Click to expand...
Click to collapse
exactly ! android is 100 times better and powerfull than ios ! if in an iphone ui rendering didnt happen didicatedly, it would be 100 times more laggy than android. one other thing that shows that ios does concentrate completly on ui when scrolling- swipe left right through homscreens in speed (even with all apps closed) - ull see that the dots below which indicate which screen ur on , doesnt change at all untill uve stopped scrolling and then it moves directly to the current screen indicator!
---------- Post added at 03:16 PM ---------- Previous post was at 03:09 PM ----------
btw this here is a contradicting article to what andy you posted ! here ! :
Dianne Hackborn - 00:38 (edited) - Public
A few days ago I wrote a post trying to correct a lot of the inaccurate statements I have seen repeatedly mentioned about how graphics on Android works. This resulted in a lot of nice discussion, but unfortunately has also lead some people to come up with new, novel, and often technically inaccurate complaints about how Android works.
These new topics have been more about some fundamental design decisions in Android, and why they are wrong. I’d like to help people better understand (and judge) these discussions by giving some real background on why Android’s UI was designed the way it is and how it actually works.
One issue that has been raised is that Android doesn’t use thread priorities to reduce how much background work interrupts the user interface. This is outright wrong. It actually uses a number of priorities, which you can even find defined right here http://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_AUDIO in the SDK.
The most important of these are the background and default priorities. User interface threads normally run at the default priority; background threads run in the background priority. Application processes that are in the background have all of their threads forced to the background priority.
Android’s background priority is actually pretty interesting. It uses a Linux facility called cgroups to put all background threads into a special scheduling group which, all together, can’t use more than 10% of the CPU. That is, if you have 10 processes in the background all trying to run at the same time, when combined they can't take away more than 10% of the time needed by foreground threads. This is enough to allow background threads to make some forward progress, without having enough of an impact on the foreground threads to be generally visible to the user.
(You may have noticed that a “foreground” priority is also defined. This is not used in current Android; it was in the original implementation, but we found that the Linux scheduler does not give enough preference to threads based on pure priority, so switched to cgroups in Android 1.6.)
I have also seen a number of claims that the basic Android design is fundamentally flawed and archaic because it doesn’t use a rendering thread like iOS. There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave.
Android had a number of very different original design goals than iOS did. A key goal of Android was to provide an open application platform, using application sandboxes to create a much more secure environment that doesn’t rely on a central authority to verify that applications do what they claim. To achieve this, it uses Linux process isolation and user IDs to prevent each application from being able to access the system or other application in ways that are not controlled and secure.
This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all.
An important part of achieving this security is having a way for (EDIT: It has been pointed out to me that iOS does in fact use multiple windows and multiple GL contexts. Lesson to me, just don't talk about anything I haven't directly verified. That still doesn't change things for Android, though, where as I mention later we simply did not have hardware and drivers that could do multiple GL contexts until fairly recently.)
individual UI elements to share the screen in a secure way. This is why there are windows on Android. The status bar and its notification shade are windows owned and drawn by the system. These are separate from the application’s window, so the application can not touch anything about the status bar, such as to scrape the text of SMS messages as they are displayed there. Likewise the soft keyboard is a separate window, owned by a separate application, and it and the application can only interact with each other through a well defined and controlled interface. (This is also why Android can safely support third party input methods.)
Another objective of Android was to allow close collaboration between applications, so that for example it is easy to implement a share API that launches a part of another application integrated with the original application’s flow. As part of this, Android applications traditionally are split into pieces (called “Activities”) that handle a single specific part of the UI of the application. For example, the contacts lists is one activity, the details of a contact is another, and editing a contact is a third. Moving between those parts of the contacts UI means switching between these activities, and each of these activities is its own separate window.
Now we can see something interesting: in almost all of the places in the original Android UI where you see animations, you are actually seeing windows animate. Launching Contacts is an animation of the home screen window and the contacts list window. Tapping on a contact to see its details is an animation of the contacts list window and the contacts details window. Displaying the soft keyboard is an animation of the keyboard window. Showing the dialog where you pick an app to share with is an animation of a window displaying that dialog.
When you see a window on screen, what you are seeing is actually something called a “surface”. This is a separate piece of shared memory that the window draws its UI in, and is composited with the other windows to the screen by a separate system service (in a separate thread, running at a higher than normal priority) called the “surface flinger.” Does this sound familiar? In fact this is very much like what iOS is doing with its views being composited by a separate thread, just at a less fine-grained but significantly more secure level. (And this window composition has been hardware accelerated in Android from the beginning.)
The other main interesting interaction in the UI is tracking your finger -- scrolling and flinging a list, swiping a gallery, etc. These interactions involve updating the contents inside of a window, so require re-rendering that window for each movement. However, being able to do this rendering off the main thread probably doesn’t gain you much. These are not simple “move this part of the UI from X to Y, and maybe tell me when you are done” animations -- each movement is based on events received about the finger on the screen, which need to be processed by the application on its main thread.
That said, being able to avoid redrawing all of the contents of the parts of the UI that are moving can help performance. And this is also a technique that Android has employed since before 1.0; UI elements like a ListView that want to scroll their content can call http://developer.android.com/reference/android/view/View.html#setDrawingCacheEnabled(boolean) to have that content rendered into a cache so that only the bitmap needs to be drawn as it moves.
Traditionally on Android, views only have their drawing cache enabled as a transient state, such as while scrolling or tracking a finger. This is because they introduce a fair amount more overhead: extra memory for the bitmap (which can easily total to multiple times larger than the actual frame buffer if there are a number of visual layers), and when the contents inside of a cached view need to be redrawn it is more expensive because there is an additional step required to draw the cached bitmap back to the window.
So, all those things considered, in Android 1.0 having each view drawn into a texture and those textures composited to the window in another thread is just not that much of a gain, with a lot of cost. The cost is also in engineering time -- our time was better spent working on other things like a layout-based view hierarchy (to provide flexibility in adjusting for different screen sizes) and “remote views” for notifications and widgets, which have significantly benefited the platform as it develops.
In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.
I hope this helps people better understand how Android works. And just to be clear again from my last point -- I am not writing this to make excuses for whatever things people don’t like about Android, I just get tired of seeing people write egregiously wrong explanations about how Android works and worse present themselves as authorities on the topic.
There are of course many things that can be improved in Android today, just as there are many things that have been improved since 1.0. As other more pressing issues are addressed, and hardware capabilities improve and change, we continue to push the platform forward and make it better.
One final thought. I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists: “Getting it up to sixty is more difficult—you may have to simplify the cell's view hierarchy, or delay adding some of the content, or remove text formatting that would otherwise require a more expensive text rendering API, or even rip the subviews out of the cell altogether and draw everything by hand.”
I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS.
D3oDex3D_Ayush717 said:
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
Click to expand...
Click to collapse
Ehhhh I still think 3GS is better than optimus one
That's a lot of bull**** in even more words...
Kidding
But I don't understand anything of it, I'll leave it to the real devs (A)
Luck dev'ing
ok, here some basic informations on how long it take and why before a developer can
release a complete OS:
http://developer.sonyericsson.com/w...from-source-code-release-to-software-upgrade/
About Accelerated Android Rendering:
It's pretty interesting although these guys aren't talking about Ice Cream Sandwich (they're talking about Honeycomb that introduced hardware accelerated 2D rendering)
http://www.youtube.com/watch?v=v9S5EO7CLjo
I could be way off base here, but is there anything useful that could be extracted from qualcomm's adreno sdk?
https://developer.qualcomm.com/
terratrix said:
Ehhhh I still think 3GS is better than optimus one
Click to expand...
Click to collapse
I am not comparing 3Gs and O1, am talking abt. difference between AndroidOS and iOS............
Sent from my LG Optimus One P500 using XDA App
This week, google started a nice topic on the android developer page "Best practices to develop android applications".
Reading some articles is recommended for developers who want to save some battery and/or network traffic, want to spped
up listviews, save ram and other good things:
look here:
Improving Layout Performance
Optimizing Battery Life
Sharing content between applications
i hope, this can someone help to understand what we can do to make things nice.
When I first saw Remix OS, I was ecstatic thinking of the possibilities for development, and now that it's come out on the Pixel C, this could be really innovative.
Imagine using Android Studio on my laptop and then pushing my in-development application to the Pixel C using ADB (Android Debug Bridge) over wire or wifi, and then an app window showing up to test my app, essentially replacing a real phone with an all in one Pixel C computer. The main reason why this was so ecstatic for me was because what I am testing on is now no longer a phone, but a computer, four very important and useful things open up for me to possibly experience:
I can resize my application easily on the tablet to test out any dimensions.
- We all know the emulator is a ***** in Android and even the thought of starting and restarting different emulator instances for different dimensions, or, god forbid spending hundreds of dollars on different android devices of different sizes just irks me to the core.
- Resizing would become as simple as a click, hold, and drag, just like browser development. An added bonus would be Jide giving a little toolbar above or below or to the side of these development applications to simulate different settings, such as Location, Network, whatever, and maybe even a resize button to select popular and customizable preset dimensions.
I can have multiple instances of my application to run at the same time, basically A/B test on myself.
- I don't know how you can manage this, but if you can, whatever the way it may be done, it would be marvelous.
- Imagine the power of being able to test multiple versions of an application side by side or even different applications side by side, one for each window of Android studio perhaps.
- Testing is one of the slowest factors of android development, but no matter how you put it, being able to run as many applications as I want to test would definitely speed up the process.
- Write a bit of code for idea one and start the test and let it run.
- Code up another idea to test.
- While the second one is getting ready for testing, you can test the first one.
- When the second one is ready, we can test them side by side to see which idea is better.
- It would be, again, simply marvelous, and the number of instances to test could be increased for even greater speed.
I can control it from my laptop.
- If you need to be told the gigantic advantages of being able to control your android device by simply moving your mouse over to the screen as if it was an extended display, then you must really not have any imagination.
- https://sites.google.com/site/droidskm/
- https://sourceforge.net/projects/synergyandroid/
- There are many tools out there to allow this kind of control, and all Jide really has to do is make it really easy for us to root the OS, maybe a button click in the developer tools, so we can install tools like the ones I mentioned above.
Remix OS could become where I test AND develop. If an android studio like tool were to be created for Remix OS, where all the previews and all the testing are just popups on the sides of the tool, then development would be even cooler.
- There would be no need for a native android device, no need to fumble back and forth, especially since Laptops or the Pixel C would probably have all the features of a modern phone, and thus act just like one in testing.
- Since all we're doing is launching another application on the native OS, there shouldn't be any annoying and overbearing emulator problems, nor lag or performance issues.
- I know this is a stretch, since a tool like Android Studio would be very hard to live up to, but even a simpler version would do, like sublime; Jide may even contract or partner up with IntelliJ to create such a tool or host of tools.
These four core points are marvelous, and for an android developer, Jide would become heaven. If Jide really does listen to the community, they would listen to this, because if they pushed forward with these ideas, their platform would grow a lot, easily becoming the number one platform for Android development, definitely garnering a lot of attention.
Oh, and please add a Linux console I can use.
Thank you.
Sincerely, an imaginative android/web developer.
- redDrill
On #2 you can sort of do that already by using different users
On #4 something like AIDE would be too simple I take it...
Huawei launched a range of smartphones, smart watches, and tablets powered by its new HarmonyOS 2 operating system today, including a new version of the HUAWEI Mate 40 Series and HUAWEI Mate X2, the HUAWEI WATCH 3 Series, and the HUAWEI MatePad Pro.
At today's event, Huawei also released the HUAWEI FreeBuds 4, its next-generation open-fit Active Noise Cancellation (ANC) wireless Bluetooth earbuds, and two high-end monitors, the HUAWEI MateView and the HUAWEI MateView GT. The company took this opportunity to announce that roughly 100 other Huawei devices – including both smartphones and tablets – will be upgraded to run on HarmonyOS 2, giving consumers access to a seamless intelligent experience across multiple devices in all different types of scenarios.
There are more smart devices in our lives than ever, but the experience they provide often isn't smart. Siloed systems tend to complicate interconnectivity and operations, which have ultimately led to a fragmented user experience.
HarmonyOS is designed to address this problem. As a next-generation operating system for smart devices, HarmonyOS provides a common language for different kinds of devices to connect and collaborate, providing users with a more convenient, smooth, and secure experience. It uses distributed technology to meet the varied needs of all types of different devices with a single system, enabling flexible deployment as needed. HarmonyOS also combines previously independent devices into a cohesive and holistic Super Device that integrates all hardware and resources to freely leverage the capabilities of its component devices based on the user's real-time needs. For developers, HarmonyOS allows cross-platform development and cross-device deployment of apps, making the development of apps across devices easier than ever before.
HUAWEI WATCH 3 Series: An independent smart assistant as powerful as your smartphone
Huawei's brand-new flagship smart watch, the HUAWEI WATCH 3 Series, redefines fashion on your wrist. Featuring a curved glass screen and 316L stainless steel case, this stylish watch comes complete with a brand-new 3D rotating crown that senses different levels of pressure and provides haptic feedback in response to user input, making the watch both comfortable to wear and easy to operate. The HUAWEI WATCH 3 Series also allows you to make and receive phone calls and listen to music using the same phone number and data plan as your smartphone.
The HUAWEI WATCH 3 Series runs on HarmonyOS 2, which allows it to integrate seamlessly with Huawei smartphones to serve as a multifunctional travel assistant. Functionality flows directly from your smartphone to your wrist, making all ride-hailing and flight information available at a glance. On the ride home from the airport, if you're taking public transit, both your watch and your phone will remind you when you're getting close to your final destination. You never have to worry about missing your stop again1.
The HUAWEI WATCH 3 Series also serves as a professional fitness & health manager that supports more than 100 workout modes. In addition to a broad range of healthcare support options, the watch can now monitor skin temperature with a new, high-precision temperature sensor2. It also supports fall detection and SOS functions so users can monitor and manage their health in real time.
The HUAWEI WATCH 3 Pro features an ultra-long battery life, which lasts five days in smart mode and 21 days in ultra-long battery life mode. The HUAWEI WATCH 3, in turn, has a battery life of three days in smart mode and 14 days in ultra-long battery life mode3.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
HUAWEI MatePad Pro: A new productivity hub that breaks through boundaries for maximum creativity
The new HUAWEI MatePad Pro features a stunning 12.6-inch OLED FullView Display with a 90% screen-to-body ratio, the highest among all tablets currently available on the market. Every display comes with a ΔE color difference of less than 0.5 for incredibly high color accuracy, delivering a crisp, color-accurate picture that is on par with professional monitors. The HUAWEI MatePad Pro also has an ultra-high contrast ratio of 1,000,000:1, and supports a DCI-P3 color gamut.
Equipped with Kirin 9000 series chipsets, the HUAWEI MatePad Pro delivers incredible levels of performance. Supported by the distributed data management and task scheduling capabilities of HarmonyOS, the tablet can work together seamlessly with smartphones and PCs to double your productivity and creativity in different scenarios, whether you're in the office or at the drawing board.
The HUAWEI MatePad Pro also supports Multi-screen Collaboration with PCs4. The tablet can become a drawing board in Mirror mode and a monitor in Extend mode. It also supports cross-device file dragging and dropping, delivering a more efficient and collaborative multi-device experience.
The second-generation HUAWEI M-Pencil5 was unveiled together with the HUAWEI MatePad Pro. The new smart pen features a new platinum-coated nib for high-precision handwriting and ultra-low latency, accurately differentiating between 4,096 levels of force. The HUAWEI M-Pencil supports FreeScript, which converts handwriting in any input box into digital text in real time. In addition, intelligent interactions such as double-tap to switch, Instant Shape, and Instant Table make handwritten input more seamless and natural to fit your unique workflow.
An entirely new interactive experience: Easier to use and smarter than ever
Multi-device interaction with HarmonyOS makes working across multiple devices as simple as controlling one. The new Control Panel supports simple and intuitive connections through a drag-and-integrate feature that allows users to freely connect the devices they want based on specific scenarios.
For example, if you want to watch a movie at home late at night, all you have to do is open up the Control Panel and drag the smart screen icon to your phone icon, and the movie jumps directly from your phone to the TV. If you're wearing your HUAWEI FreeBuds 4, you can then drag the earphone icon to the phone icon, at which point the movie will play on your smart screen while rerouting its sound through your FreeBuds. This is just one example of the Super Device experience.
HarmonyOS 2's new Task Center allows apps to travel between different devices at will without installing them on each and every one, so that all functions and services are available whenever and wherever they're needed. On any device that's part of a Super Device system, you can see the tasks running on all other devices6. If you want a bigger display for mobile gaming, you can simply swipe up and hover to bring up the Overview Screen, and then transfer the game to your HUAWEI MatePad Pro to continue the fun.
The new HarmonyOS Home Screen is more streamlined and organized than ever. You can swipe up on apps to generate Service Widgets7 that display real-time, easy-to-access information or services without having to open the app itself. You can customize the size of the Service Widgets, tap apps and swipe up to display their widgets, and tap any vacant location on the home screen to hide them. Service Widgets can also be used to access Atomic Services, which can be easily called on and shared in the Service Center without the need to download or install anything, making it easier and more convenient to access functions like news aggregation8.
In terms of look-and-feel, the beauty of innovative interaction lies in the aesthetic details: The specially designed HarmonyOS Sans font and natural Gravitational Animations offer a consistent user experience across all HarmonyOS devices.
HUAWEI HiLink has been upgraded to HarmonyOS Connect to equip more non-Huawei devices with smart features. Smart home devices can be connected to your mobile phone with a single tap: Tap your phone against a Midea oven that supports HarmonyOS Connect and select a recipe to start preparing your meal instantly. Keep your leftovers safe for longer with Haier refrigerators that automatically adjust their temperature based on the type of food you're storing. And get the perfect soymilk for your body with Joyoung soymilk machines that can recommend recipes based on the data in your Health app9. When working together, these connections can turn your kitchen into a personal health coach.
Comprehensive performance gains for more privacy and security
HarmonyOS 2 runs even more smoothly than the last generation of EMUI. A HarmonyOS 2 phone can maintain read/write speeds similar to those of a new phone after 36 months of use, even with very little storage still available on the device.
HarmonyOS 2 keeps opened apps running in the background so that your tasks are always available where you left off. You can return to the last action or page on a given app even if you have dozens of other apps open. For example, if you were on a shopping app looking at a product, then you switched to another app to send your friend a message, and then opened up your browser to search for something else, you can now return to the last page you were browsing on your shopping app without a hitch. What's more, you can enjoy a longer battery life with a HarmonyOS 2-based device. After upgrading to HarmonyOS 2, the HUAWEI Mate 40 Pro can run Game for Peace for 5.1 hours straight10.
Huawei is committed to protecting user privacy and security. HarmonyOS inherits and further builds on the leading privacy and security technologies found in EMUI. Our core design principle is to ensure that only the right person can access the right data with the right device, ensuring the security of each access to each device, as well as the security of each act of storing, transmitting, and using data across all scenarios. When multi-device collaborative identity authentication is activated, users can only unlock their phones with a combination of facial recognition on their smartphone and a special check that ensures that the user's watch is the one that's connected to the phone.
In addition, HarmonyOS manages user data by category and protects devices by level, setting specific security thresholds for Super Devices. Only devices that meet strict security requirements can access data corresponding to their security level, making sure that users can make use of Multi-device Collaboration features with true peace of mind. HarmonyOS apps go through rigorous testing throughout development, release, installation, and use to ensure they deliver a secure experience in a clean ecosystem.
"We are surrounded by more and more smart devices these days, and are now in a world where all things are connected," said Richard Yu, Executive Director and CEO of Huawei's Consumer Business Group. "Every single one of us is a part of this fully connected world, as is every device. We look forward to working with more partners and developers to build a thriving HarmonyOS ecosystem and provide even better experiences, products, and services to our customers the world over."
To give more consumers the opportunity to experience the convenience, seamlessness, and security of HarmonyOS across all scenarios, nearly 100 Huawei devices are set to receive the HarmonyOS 2 upgrade in China, including the HUAWEI Mate 40 series, Mate 30 series, P40 series, Mate X2, nova 8 series, and MatePad Pro series. Users who want to try out the new OS sooner can submit an application at the Huawei Club or on the My Huawei app, or sign up for the HarmonyOS Experience Officer Program in any of Huawei's 66 offline experience stores in China11.
1.These features are provided through third-party apps, the availability of which varies from country to country. Please refer to Huawei's local official website.
2.Only supported after OTA programming upgrade. This feature is not designed to be a medical device, and is not intended to diagnose, treat, cure or prevent any disease. All data and measurements should be used for personal reference only.
3.All data is based on lab test results. The actual length of usage may vary depending on individual product differences, user habits, and environmental variables. For more details, see the HUAWEI WATCH 3 Series product page on Huawei's official website.
4.This function is only supported by certain files and apps between Huawei tablets powered by HarmonyOS 2 and above and Huawei laptops with a HUAWEI PC Manager version of 11.1 and above. If you have any questions about this function when buying or using Huawei products, please contact Huawei's customer service staff.
5.This function is only available on certain Huawei tablets powered by HarmonyOS 2 and above.
6.The Task Center is currently available only on certain Huawei smartphones and tablets powered by HarmonyOS 2 and above.
7.The apps and functions supported by Service Widgets are subject to actual situations. Certain apps only support Service Widgets after receiving an OTA upgrade.
8.This news function is provided by the Sina News app, and is currently only available on the Chinese mainland.
9.The products referred to here are the Midea S5 Mini steam oven and Joyoung Soymilk Machine DJ12R-K2S (HM). The Haier refrigerator is not yet commercially available.
10.Data from Huawei labs. Game version: 1.13.12. Game play settings: HUAWEI Mate 40 Pro with a screen refresh rate of 90 fps with smooth images displayed.
11.Offline experience is available in more than 30 cities across China. For more information, please visit https://consumer.huawei.com/en/ or the My Huawei app.
Original Link:https://consumer.huawei.com/en/press/news/2021/huawei-launches-new-products-powered-by-harmonyos-2/
does it provide mobile phone development?