User Guide. Android x86 Modified System. Sponsor: Huan Ren. Compiled by: Zachary Bair, Taronish Daruwalla, Joshua Duong, and Anthony Nguyen

Transcription

1 User Guide Android x86 Modified System Sponsor: Huan Ren Compiled by: Zachary Bair, Taronish Daruwalla, Joshua Duong, and Anthony Nguyen

2 Table of Contents 1. What is Android x86? 2. How to get Android x86 3. Features Added to Android x86 a. File Manager b. System UI c. Multi Window Support 4. Troubleshooting Android x86 a. Frequently Asked Questions 5. Contact Information 6. Appendix A: Design Documentation 7. Appendix B: Testing Documentation

3 What is Android-x86? Android x86 is an unofficial initiative to port Google's Android mobile operating system to run on devices powered by AMD and Intel x86 processors, rather than RISC based ARM chips. The OS is based on the AOSP, with some minor modifications which allow it to run on PC architecture. The ultimate goal of Android x86 is to create a fully functional Desktop environment for the Android Operating System, which fully supports Android applications. There are a number of reasons as to why the Android x86 operating system is being created. It fulfils a general market, and has the potential to disrupt major operating system players such as windows, mac, and popular linux distributions such as Ubuntu. However, there is a lot of work to be done to the current Android x86 iteration before it is ready to have a significant impact on the market. The original version was a straight port, in which the low level drivers and bit code was adapted to be able to run on common personal computer chips. However, there are many small things which inhibit familiar use of the Android x86 operating system. Most of these are small control issues. Users of android are used to using their fingers to swipe across the screen for all types of operations. However, using a trackpad or mouse, swipe was inconvenient, and was some of them were replaced. How to get Android-x86 There are a few ways to obtain Android x86 to upgrade an existing system. One way is to download the complete source code for the Android x86 operating system from x86.org/getsourcecode. For this, we chose to modify the kit kat(4.4) Android release as it is the latest release to allow for multi window purposes. After retrieving the source code, you may follow the instructions found on the website to build an iso image and create a bootable USB to load the operating system onto most PCs. On the above site, they already have the iso/img file online to download, so if you do not want to compile the source tree yourself, you can just download the file, create a bootable usb and boot the system on a PC.

4 Features Added to Android-x86 In the course of this project, major modifications have been made to the system in order to make it more user friendly. File Manager One of the modified areas was the file manager that came with the system. We modified it so that the main layout is designed for efficient use with a mouse and keyboard. We implemented several keyboard shortcuts for file handling such as copy and paste. System UI Multiple aspects of System UI were changed in order to improve the quality of the system. We moved multiple notification buttons to the launcher so that we may access the controls easier, instead of having swipe down menus, which are awkward for keyboard/mouse users. We added a home/show apps button to the systemui so that it is independent from the launcher area. We added a taskbar to the systemui bar for easier task switching (similar to the task bar found on Ubuntu or Mac machines). Multi-Window Support We applied a patch to our source code called Tieto Multi Window Support. This patch allowed a basic multi window ability to the operating system. We worked to modify this patch to include minimizing, maximizing, and a close task button to the frame of each window. Troubleshooting Android-x86 On occasion, there are some issues with the Android x86 system. Problems Building From Source If you are trying to build the system from the source tree, and the compilation fails, please make sure you have all the dependencies required to compile the system by looking at If, after you have all the dependencies, still cannot build the system, you will need to resync the source tree from Github, as some files may have failed to download when doing the first source tree sync.

5 Developer Troubleshooting If you are trying to develop on the android x86 platform, and need to use output debugging, use adb logcat. For more information, refer to on how to use logcat, and this wiki for more options on debugging. Frequently Asked Questions Q: How can I more easily restart the System UI when rebooting is the other option? A: The Restart System UI application can be downloaded online, and is quite useful, especially when doing development. Q: How do I enable the multi window support? A: Go to Settings >Jabol and check the box labeled multiwindow. Q: Whenever there is a popup asking for root permissions, I cannot reposition the popup window. A: This problem is a bug, and has not been addressed by the latest build of Tieto, nor by our team. Q: How do I view the installed applications? A: Click on the Android man icon in the bottom left corner to open up a startup menu which contains a list of all installed applications as well as quick settings such as brightness, wifi management, and power controls. Q: How do I shut down the system? A: Click on the Android man icon in the bottom left corner to open up a startup menu which contains a list of all installed applications as well as quick settings such as brightness, wifi management, and power controls. Another way to shut down the system is to hold the power button down for around 10 seconds. Q: How do I manage the wifi? A: Click on the Android man icon in the bottom left corner to open up a startup menu which contains a list of all installed applications as well as quick settings such as brightness, wifi management, and power controls. Clicking on the wifi panel will direct you to the wifi settings, where you can choose manage your network.

6 Contact Information If there are any questions or you would like to contact contributors of this project for any reason, feel free to. Zachary Bair Taronish Daruwalla Joshua Duong Anthony Nguyen

7 Appendix A: Design Documentation 1. Technology background The Android x86 project has been in existence since Since then there has been a port of android that is able to run on PCs. While the initial port took a considerable amount of effort, the current project consists of updating the system with each subsequent Android version release. At this moment, a few auxiliary members have been creating small changes such as external mouse support. 1.1 The Android Architecture The Android OS framework is layered in blocks from bottom to top. The OS starts its foundation with a linux kernel that comes with the necessary drivers to handle input/output devices, power management, etc. On top of the linux kernel is the native libraries written in C/C++, the android runtime libraries and the dalvik virtual machine. The next layer is the application framework, and on top of that, the applications The Linux Kernel The Android OS is built on top of a linux kernel, with all the necessary drivers for input/output controls, power management, etc. Even though the OS is built from a linux kernel, Android is not linux, in that it does not have a native windowing system, no GNU libc (glibc) support, and does not include the entire set of standard linux utilities. Also, the Android OS comes with other custom drivers specific to the Android platform. The reason the developers chose to use the Linux kernel is because it has great process management, as well as a long standing security model. Also, the linux kernel has good driver support and is open source The Native Libraries On top of the linux kernel are the native libraries written in C and C++ such as function libraries, hardware abstraction libraries and the native servers. These libraries provide low level functionalities and computationally intensive functionalities to the Android platform. The native library also includes bionic libc, which is essentially a custom glibc built to be efficient on embedded systems, and small enough to not affect RAM performance. The functional libraries do all of the intensive work of the android platform, and are abstracted in higher level APIs. The native servers handle all of the interactions with the input/output devices and provide them to the android platform. The hardware abstraction libraries provide an abstraction between the hardware and the higher level APIs for applications. Bionic libc is

8 not based off of glibc, so bionic libc is not compatible with glibc and thus all native code must be compiled with bionic libc The Android Runtime The android runtime provides two essential things: the core libraries and the dalvik virtual machine. All of the applications run in the dalvik virtual machine, and the virtual machine makes it so the application can run in any hardware system, provided it has the dalvik virtual machine. The core libraries provide the application developers with all of the familiar java APIs used for things like network access, file access, standard data structures, etc The Application Framework Sitting on top of the native libraries and the android runtime is the application framework. The application framework is all written in the Java language, contains all of the classes and core system services used for application development. This is also where the system UI of the Android system resides The Applications On top of the application framework lies all of the applications built by the developers for the android OS such as the browser, the file manager, the camera, etc. Applications exist on the android device as an android application package, or.apk file. These are built from their original source code and installed on the android device. 2. Design goal The end goal of the project is to make a series of functional and aesthetic changes to the Android x86 system in order to bring it to the level of usability exhibited by modern personal computers. This means we will have to architect major changes to core applications inside the system, as well as perhaps manufacture some stand alone applications from scratch. The current proposed changes are as follows: 1. File Manager 2. Home Screen (Launcher) 3. Taskbar 4. Multi Window Support These applications have been determined as having a large impact on user experience, as well as lacking in its current form. Not only this, but these applications should be manageable in the scope of this project.

9 The file manager does not compare to that of other operating systems. The current version is simplistic but functional it starts from a given directory and shows the contents in a list. In other operating systems the view defaults to clickable icons for each, and provides secondary navigation tools such as most visited places, back and forward, and displays the current path. There are also keyboard commands that make file managing more easy such as commands for copy and paste. Another ability that should be implemented is the dragging & dropping of files and directories. The home screen needs significant changes in order to mimic that of normal personal computer operating systems. One of the biggest changes that can be seen in the two concept pictures above is the addition of a taskbar at the bottom. This is used to quickly change between applications that are currently running. This is featured on all common consumer OSs today, and should be added to Android x86. Additionally a Start functionality that displays commonly used applications will be added. Finally, we will implement functionality to support multiple independent windows. In the current android OS, whenever switching to a different app, the app will take up the entire screen space. We want to modify this behavior so that on application startup, the application will open into an independent window that can be moved and resized. Also, when you click on a window in the background, that application will be the application in focus. 3. Architectural choices and corresponding pros and cons Of the many design architectures, there seems to be three architectures that many developers use to build android applications: the Model View Controller (MVC) model, the Model View Presenter (MVP) model, and the Model View View Model (MVVM) model. In the MVC model, the user interacts with the controller and sees the view. Whenever the user inputs something to the controller, the controller updates the model, which holds some type of data, and then the model will update the view so the user can see the changes. In the MVP model, the user interacts with the view. Whenever the user interacts with the view, events will be sent from the view to the presenter. From here, the presenter will update its model. When the model changes, the model will send a confirmation message to the presenter indicating that an update has been made. Once the presenter receives this notification, it will update the view to reflect changes.

10 In the MVVM model, the view is the user interface, the model is the data representation of the screen, and the view and model are directly bound together. This direct binding means that whenever the user changes information on the view, the view notifies the model to update its data. In this design pattern, the view model simply exposes the model to the view and its properties and commands. For the most part, the MVP and MVVM models are the same. The only difference is that the MVVM model requires bindings whereas the MVP model does not. This difference corresponds to more code behind in the presenter of the MVP model, and less code in the viewmodel. All of the models described above have loose coupling between the view and the model, which makes unit testing easier. The only difference is that with the MVC model, where the controller unifies all of the different windows together, limits the areas unit testing can cover. 4. Selected architecture Since android supports all of the above implementation schemes, we have decided to go with the MVVM model, simply because our team members have experience with Windows WPF MVVM model. If later, we find that the Android API available on the Android x86 platform does not support bindings, we will revert to the MVP model. 5. Implementation notes We will have four development environments for testing purposes: development, integration, acceptance and production, where production is the release pushed into the final version of the product. The development environment will be used for the developers to build and test the product. The integration environment will be used for the testers to run the product in a test environment. The acceptance environment will be to test use cases in the actual android environment.

11 Appendix B: Testing Documentation Summary of Components to be tested File Manager The file manager is a highly used application that is native to Android. For the Android x86 port, the original file manager exists, but requires modification in order to match that of other modern operating systems such as Windows and OSX. Use cases for the file manager include file/directory creation and deletion, renaming files/directories, moving files/directories, and being able to open files using the appropriate application. UI Changes Permanent bookmark bar Commands Shift + Click : highlights multiple items(directories/files) Ctrl + D : deletes item Double Click : opens item Ctrl + Shift + D : new directory Ctrl + Shift + F: new file Ctrl + C : copy item Ctrl + V : paste item (Hold click) + (move mouse) : drag and drop item (aka copy/paste) Launcher UI Changes Moved app launcher to bottom left of screen. Have a taskbar at bottom to switch between applications. Power, battery status, wifi, bluetooth buttons moved to always visible portion of screen. Multi window support Open multiple applications to be run simultaneously side by side or cascaded. Resize application window by click/dragging window corners. Minimize/Maximize window by button. Kill application by button. Resources Required for Testing

12 Testing of the Android x86 operating system requires a modern computer that is based on the Intel x86 architecture. After this, a copy of the operating system image is needed in order to either install or run Android x86. If testing is completed using an Android x86 image that has all of implemented changes already built in, then the appropriate applications will be able to run and tested. However, if it is the unmodified original Android x86, then an internet connection will be needed to use the Android Debug Bridge, or adb in order to push the modified.apk files to the system. Testing of the modified Android x86 can also be done on a host computer that is running a different host operating system by using a virtual machine. The settings of the virtual machine will have to be changes such that it has a unique IP address on the local network if adb is being used to acquire the modified applications. Packaging and Building In order to build our android code, there needs to be the proper android development tools setup. This includes the correct jdk version, android sdk version, and numerous other tools. The command lunch was used to add different file locations to the path variable, and then the envsetup.sh file is sourced using source android x86/build/envsetup.sh. When all of these development tools are included, you can build an application. In order to build the android application, we used the command: mmm android x68/packages/applications/filemanager which would generate a.apk file in the output folder. Test Case Example test case to test implemented clicks in File Manager 1. User Type: Admin/User 2. Goal: Ensure that proper navigation can be done 3. Initial Conditions/Required Resources/Configurations: Begins in home directory 4. Test Script: a. User double clicks directory b. Enters the directory and displays content c. User Shift + clicks files d. Selects multiple files