Android API versions. “Robot Heart”: How to use the Android system API for personal purposes



Please share your blank project, ready for publication for TV devices.
I can’t seem to publish something, and now it’s been rejected with the following errors:
APK:8
No Now Playing notification"
Your App does not contain a “Now Playing” notification for when the user has selected the HOME button within the app. Please refer to our Displaying a Now Playing Card documentation for more details.
APK:8
Play/Pause key event is not respected during playback
Your media apps that play video or music content must respect the play/pause key during playback. Please refer to our Media Play/Pause documentation and Update the Playback State documentation for details.
Missing DPad functionality
Your app requires user interaction for menus or app navigation. Please make sure that all menus and app navigation are fully functional using a DPad. Please refer to our DPAD Control and Hardware Declaration documentation.
Well, I didn’t attach the banner
No full-size app banner
Your app does not contain a full-size app banner or is it not visible in the launcher. We are targeting 1080P, which we consider xhdpi. Apps should include the banner in the xhdpi (320 dpi) drawables folder with a size of (320px × 180px). Please refer to our Home Screen Banner and UI Patterns documentation.
The title should help users identify apps in the launcher. Please refer to our Visual Design and User Interaction documentation for more information.
I would be very grateful for a working empty skeleton with a manifesto.

From

During the development process I encountered a very strange situation, the roots of which are still unclear, but a solution was found.
So. Delphi 10.3.3. Clean application - empty form and button. Works great on various devices except Samsung Galaxy Tab A (2016). Android 5.1.1
The program crashes before it even has time to load. Any. At the same time, it, compiled on another computer, starts normally. And even after changing the SDK/NDK on it, nothing crashes.
LogCat gives an extremely strange picture
java.lang.IllegalArgumentException: Unable to load native library: /data/app-lib/com.embarcadero.Project1-1/libProject1.so
We are starting to experiment with SDK, NDK, etc. I also installed hotfixes for 10.3.3.
I’ll say right away that the SDK/NDK were installed separately via Android studio and were not downloaded along with Delphi. Don’t rush to stop reading at this point!)) On another computer, where everything works, everything was installed in exactly the same way.
In short, many combinations of SDK/NDK versions have been tested.
The result is this. With the gradual downgrade of the NDK, everything took off with NDK v22.

At the same time, the SDK version apparently does not have such a big impact, because this option works fine

I repeat. Everything worked on other devices and on newer Ndk. Xiaomi Mi Pad4, Samsung Galaxy Tab A (2019), Xiaomi Redmi 5 and 5Plus

Thank you for your participation and help in sorting out the rubble @Andrey Efimov

From

I have two applications in my work, and both of them are not intended for the Play market, since they have a limited range of use, in fact, purely internal corporate ones. So it is not advisable to post them on alternative app stores either.
The update question automatically arises. If for the first time we can install the application ourselves with the help of admins, then updating them is not so easy. And the contingent of users cannot cope with “download the APK from the link, find where the browser downloaded it, and manually launch the last downloaded one, and not just any one”...
The simplest way is to let the application download a fresh copy from the website and run the system installer on the resulting file.
But fresh Andoirds directly forbid doing this. Need filepropvider. I spent the whole day poking around with manuals and YT,
This is what happened as a result.
If you have 10.3.3 like me, you don’t have to enter ... in the manifest and your file file_paths.xml (or whatever you are advised to call it on the Internet) in deployment.
Now all this is done, albeit somewhat strangely and one-sidedly, but automatically, by checking the Secure File Sharing checkbox

After this, the manifest will automatically include one of the file placement options that you can find on the Internet. The alias external-path is used
The file shown in the figure is created automatically by Delphi itself.

Now all that remains is to guess which path will actually be substituted for "."
As practice has shown, all paths do not look as they seem, based on simple common sense. A whole day of using GetHomeDir and other useful TPath methods had me completely stumped.
It turned out to be simpler (?)
st:TMemoryStream; OutputDir: JFile; ApkFile: JFile; ApkUri: Jnet_Uri; path, filename: string; ... OutputDir:= TAndroidHelper.Context.getExternalCacheDir(); path:= JStringToString(OutputDir.getAbsolutePath); filename:= path+"/ASDroid2.apk"; ApkFile:= TJfile.JavaClass.init(StringToJstring(filename)); FApkUri:= TAndroidHelper.JFileToJURI(ApkFile); st.Position:= 0; st.SaveToFile(filename); Please note that in provider_paths we set external-paths, and in the code we look for ExternalCacheDir.!!! (For.Unbelievably.Creative.Knowers!)
Then everything is simple. FApkUri is passed to the intent and launched
The final code is something like this. (downloading in a stream using a small custom API, but nothing important there, you can ignore it)
procedure TasdSettingsFrame.bDownloadClick(Sender: TObject); begin ($IFDEF ANDROID) bDownload.Enabled:= False; DownloadAndRun(); ($ENDIF) end; ($IFDEF ANDROID) procedure TasdSettingsFrame.DownloadAndRun(); begin ttask.Run(procedure var aapi:TasdAPI; st:TMemoryStream; OutputDir: JFile; ApkFile: JFile; ApkUri: Jnet_Uri; path, filename: string; begin st:= TMemoryStream.Create; aapi:= TasdAPI.Clone(_API) ; try aapi.OnReceiveData:= OnReceiveData; aapi.getApk(st); if aapi.Err.Code=0 then begin OutputDir:= TAndroidHelper.Context.getExternalCacheDir(); path:= JStringToString(OutputDir.getAbsolutePath); filename:= path+"/ASDroid2.apk"; ApkFile:= TJfile.JavaClass.init(StringToJstring(filename)); FApkUri:= TAndroidHelper.JFileToJURI(ApkFile); st.Position:= 0; st.SaveToFile(filename); TThread.Synchronize (nil,procedure begin bDownload.Enabled:= true; StartActivity(FApkUri); end); end; finally st.Free; aapi.Free; end; end); end; procedure StartActivity(ApkUri: Jnet_Uri); var Intent: JIntent; begin Intent:= TJIntent.Create(); Intent.setAction(TJIntent.JavaClass.ACTION_VIEW); Intent.addFlags(TJIntent.JavaClass.FLAG_ACTIVITY_NEW_TASK or TJIntent.JavaClass.FLAG_ACTIVITY_CLEAR_TOP or TJIntent.JavaClass.FLAG_GRANT_WRITE_URI_PERMISSION or TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION); Intent.setDataAndType(apkuri, StringToJString("application/vnd.android.package-archive")); TAndroidHelper.Activity.startActivity(Intent); end; procedure TasdSettingsFrame.OnReceiveData(const Sender: TObject; AContentLength: Int64; AReadCount: Int64; var Abort: Boolean); begin tthread.Synchronize(nil, procedure begin pb1.Max:= AContentLength; pb1.Value:= AReadCount; end); end; ($ENDIF) Questions remain, of course, about why it’s so strange with catalogs, but there’s no desire to find out yet. It works - don't touch it.
Good luck to all.
UPD.
In order for the system installer to start, you need to remember to check one more box

From

Greetings. On the Internet I found a BASS library for Android and, accordingly, a wrapper for it for Delphi.

Everything seems to be working fine, but when setting up the library using the methods
BASS_GetConfigPtr, BASS_SetConfigPtr for working with string parameters there is a problem.
On Windows I worked with this easily, there it is enough to use this construction

PAnsiChar(BASS_GetConfigPtr(configId)) and get the value. BASS_SetConfigPtr(configId, PAnsiChar(value)) and set the value. But this method does not work under Android, for at least one reason - it does not understand what PAnsiChar is. On docwiki.emarcadero.com, there is such an article. Which says that PAnsiChar needs to be replaced with one of three: System.String, System.MarshalledString or System.SysUtils.TStringBuiler
Only now, if you use MarshalledString, then when you try to get the value, the application just freezes and that’s it.
Then I thought, since the library is written in Java (probably), it might be worth trying to use JNI to work with it, as in the Java file that came with the library. There I found declarations of these functions and noticed that the return type was Object (well, not knowing Java, I just assumed that this was also just a reference to a value, for example, like PAnsiChar in Delphi on Windows).

But, when I try to use this in any way, I come across problems in the form of a compilation error, or another application freeze.
Since Object is returned, I decided to try the option with JObject and JString, but neither option wants to work, again errors at the compilation stage, or the application freezes. Maybe I'm doing something wrong.

In general, I would appreciate your help!

From

Good time!
There is an idea to make it possible to backup application data to Google drive under the current user account. I didn’t find anything like this on the forum, maybe someone has already tried to solve a similar problem? I'm interested in working with Gdrive first of all.

From

Well, everything is basically the same as always, either I’m a lamb or the skis don’t work)
And everything is simple - I want that while the data is being downloaded from the server by clicking a button, the user will simply receive a response in the form of some kind of spinning garbage and he will see that the process is going on and that the program does not freeze and does not poke anywhere again.
So far, for testing, I’ve simply made an Update button (speedbutton with image), the data is simply loaded and displayed in the GridPanel, and on top of it, so that the user cannot point anywhere, I’ve paved it with a panel with an Image, rotated by a timer (the whole thing is on top of Visible: =false). And when we click on the Update button, we make the panel at the top of the grid displayed and start the timer, then the same handler/procedure loads the data, and at the end we stop the timer and hide the translucent, incidentally, panel. Alya like this:
procedure TForm1.SB_DataUpdateClick(Sender: TObject); begin //display the loading logo P_showLoad.Visible:= true; Timer_load_rotate.Enabled:= true; //starting the timer GetDeD_List(DE_set.Date); //the procedure for loading and displaying what we need, which takes a very long time to complete //and hiding the loading logo Timer_load_rotate.Enabled:= false; //in reverse order P_showLoad.Visible:= false; end; aaand... not a damn thing is happening the way I want(
In the end, this logo is not displayed at all, and if we remove its hiding, then it will be displayed only when everything is loaded. Logic began to tell me that I should have displayed it somehow by executing it in a parallel asynchronous thread, like this:
procedure TForm1.SB_DataUpdateClick(Sender: TObject); begin TThread.Queue(TThread.Current, //TThread.Queue TThread.Synchronize ForceQueue procedure() begin P_showLoad.Visible:= true; Timer_load_rotate.Enabled:= true; end); GetDeD_List(DE_set.Date); //the procedure for loading and displaying what we need, which takes a very long time to complete end; And again, it is displayed only after everything has loaded and the whole procedure has worked. And I’ve already tried everything, Synchronize and ForceQueue; and through TTask.Run and |task:= TTask.Create(procedure () ... etc.| nothing works, for the life of me this whole thing will be displayed only after the click procedure has been fully worked out. Maybe I’m wrong direction in general, and is this somehow being done differently? Maybe I’m still debugging on Win32, and not everything on Android, but there are a couple of options and rules that work on it? But why can’t I understand what’s what... It should be something simple, but I just can’t figure out how(

From

Google Play will no longer support 32-bit Android applications as of August 1, 2019.
And you can’t post new ones on Google Play anymore.
The latest Delphi XE does not allow you to create 64-bit Android applications.
Who knows when a new version with 64-bit support will appear? They said it was the end of summer, but summer is over

  • Latest Visitors 0 users online

    No registered user is viewing this page

    • Anyone who has written more or less serious software for different mobile operating systems knows that Android is the most open OS for developers. The API available for third-party applications is much wider, the system itself is more flexible, and the rules for placing applications in the market are very liberal. However, Android also has a number of system APIs that are hidden from third-party applications and are available only to stock software. In this article we will try to figure out how to access these APIs and what opportunities they open.

    A little theory

    As we all know, in Android there is such a concept - application permissions(permissions, permissions). Permissions are written into each application's Manifest.xml file and determine which API functions the application can access. If you want to work with the camera, add the line to Manifest.xml . You need access to the memory card - android.permission.READ_EXTERNAL_STORAGE. Everything is simple and logical, and all the powers available to applications are well documented.

    There is, however, one very important detail in this harmonious scheme, which the creators of Android themselves call access level(protection level). To understand what this is, try adding the following line to the Manifest.xml of any of your applications:

    In theory, this power should open access to an API that allows you to put your smartphone into airplane mode, turn GPS on/off, and do other useful things. But the IDE doesn’t think so and therefore immediately highlights the line as an error with the wording “Permission is only granted to system apps”. This is a warning about a violation of that very access level. The IDE seems to be telling us: yes, you can try to give your application the WRITE_SECURE_SETTINGS permission, but Android still will not allow you to use the API assigned to it until you make your application a system one. What does “systemic” mean in this case? This means: you sign it with the same digital key that the firmware itself is signed with (go try to get such a key from some Samsung or LG!).

    Officially, Android has four access levels:

    • normal- “normal” permissions, which give the application access to harmless functions that cannot be used maliciously (examples: SET_ALARM, ACCESS_NETWORK_STATE, VIBRATE). The system won't even tell you that the application is using them at all;
    • dangerous- “dangerous” powers, the user will be informed about them when installing the application or will see a warning window in Android 6.0 (examples: READ_SMS, SEND_SMS, CALL_PHONE, READ_CALL_LOG);
    • signature- available only to applications signed with the firmware key (examples: GET_TASKS, MANAGE_USERS, WRITE_SETTINGS, MOUNT_UNMOUNT_FILESYSTEMS);
    • privileged- available to applications located in the /system/priv-app directory.

    In most cases, signature and privileged access levels are equivalent. For example, to obtain the MANAGE_USERS permission, an application must either be signed with a firmware key or located in the /system/priv-app directory. But there are exceptions: for example, the MANAGE_DEVICE_ADMIN authority has the signature access level, that is, the only way to get it is to sign the application with the firmware key.

    There are also a set of internal access levels introduced into Android to solve certain problems: installer, development, preinstalled, appop, pre23. Essentially, these are crutches, and at this stage you may not think about them, but we will return to the development access level, and it will be very useful to us. In the meantime, let's talk about how to get the access levels we need and what they give.

    privileged access level

    Privileged is not the highest level of access and does not allow you to use the entire Android API. However, in most cases it turns out to be quite sufficient, since it allows you to install and remove applications and users (INSTALL_PACKAGES, DELETE_PACKAGES, MANAGE_USERS), manage the status bar (STATUS_BAR), manage some power settings (WRITE_SECURE_SETTINGS), read and change Wi-Fi settings (READ_WIFI_CREDENTIAL , OVERRIDE_WIFI_CONFIG), disable applications and their components (CHANGE_COMPONENT_ENABLED_STATE) and much more.

    In order for an application to receive the privileged access level, it must be installed in the /system/priv-app directory, which means it must come pre-installed as part of the firmware. However, with root, we can place our application in this directory using two functions:

    // A utility function that simply executes a shell command static public boolean runCommandWait(String cmd, boolean needsu) ( try ( String su = "sh"; if (needsu) ( su = "su"; ) Process process = Runtime.getRuntime ().exec(new String(su, "-c", cmd)); int result = process.waitFor(); return (result == 0); ) catch (IOException e) ( throw new RuntimeException(e); ) catch (InterruptedException e) ( throw new RuntimeException(e); ) ) // The function makes the specified application a system application and sends the smartphone to a soft reboot static public void makeAppSystem(String appName) ( String systemPrivAppDir = "/system/priv-app/" ; String systemAppDir = "/system/app/"; String appPath = "/data/app/" + appName; // Connect /system in read-write mode if (!runCommandWait("mount -o remount,rw /system" , true)) ( Log.e(TAG, "makeAppSystem: Can"t mount /system"); return; ) int api = Build.VERSION.SDK_INT; String appDir = systemPrivAppDir; // Copy the application to /system/priv- app or /system/app depending on the Android version if (api >= 21) ( runCommandWait("cp -R " + appPath + "* " + appDir, true); runCommandWait("chown -R 0:0 " + appDir + appName + "*", true); runCommandWait("rm -Rf " + appPath + "*", true); ) else ( if (api< 20) { appDir = systemAppDir; } runCommandWait("cp " + appPath + "* " + appDir, true); runCommandWait("chown 0:0 " + appDir + appName + "*", true); runCommandWait("rm -f " + appPath + "*", true); } // Отправляем смартфон в мягкую перезагрузку Shell.runCommand("am restart", true); }

    I will not describe the runCommandWait function; it simply executes a shell command and waits for it to complete (read more in my article about writing applications with root rights). The makeAppSystem function, in turn, takes the full name of the application (this is the same com.example.app that you specify when creating a new project in Android Studio) and transfers it to /system/priv-app or /system/app, depending depending on the version of Android you are using. The code may seem a little strange to you, but in fact it is absolutely correct and takes into account two factors:

    • before Android 4.4 (API Level: 20), the /system/priv-app directory did not exist and all system applications were located in /system/app;
    • starting with Android 5.0 (API Level: 21), application packages are not simply stored in /data/app and /system/priv-app, but are placed inside their own separate subdirectories.

    How to use this code? It’s very simple: you define in the Manifest.xml of your application all the privileged powers that it needs, regardless of IDE errors. Then, at the very beginning of the application code, you insert a call to makeAppSystem with the name of the application itself as an argument, compile and run. After launching, the application moves itself to /system/priv-app, reboots the smartphone, and all privileged APIs are opened to it.

    The list of privileged powers can be found in the Android sources. Just search for the word privileged. More on how to use them a little later.

    Signature access level

    Signing with a firmware key allows you to obtain the highest level of access to the API - signature. An application with such access can do almost anything: manipulate any Android settings (WRITE_SETTINGS, WRITE_SECURE_SETTINGS), grant applications administrator rights (MANAGE_DEVICE_ADMINS), programmatically press buttons and enter data into any window (INJECT_EVENTS) and much more.

    It is almost impossible to get this level of access on stock firmware. No smartphone manufacturer will provide you with a key to sign their firmware. But if we are talking about custom firmware, then everything becomes a little simpler. For example, nightly builds of the same CyanogenMod (and let me remind you that it has more users than users of all versions of Windows Phone combined) are signed with a test key, and its peculiarity is that it is publicly available.

    But that’s not all, CyanogenMod has a security mechanism that, unlike pure Android, allows not absolutely all applications signed with the firmware key to receive the signature access level, but only those located in /system/priv-app. Therefore, to get the signature access level in CyanogenMod (not in Cyanogen OS, I emphasize), you need to:

    1. Add the necessary permissions to the application's Manifest.xml.
    2. Add to the application a call to the makeAppSystem() function described in the previous section.
    3. Sign the release version of the application with the platform key from the CyanogenMod repository.

    Access level development

    Android has a special development access level, the difference of which is that applications receive it not by placing it in /system/priv-app or using a digital signature of the firmware, but dynamically. That is, the system can give this level of access to any application, or it can revoke it back. But the most important thing is that, having root rights, the application can give itself this level of access independently.

    To do this, just use code like this:

    RunCommandWait("pm grant " + appName + " android.permission.WRITE_SECURE_SETTINGS", true);

    In this case, appName will receive the WRITE_SECURE_SETTINGS permission, regardless of where it is hosted or what key it is signed with. Cool? No doubt, but WRITE_SECURE_SETTINGS is actually the only useful permission with the development access level. The remaining fourteen are powers for debugging and testing (reading logs, memory dumps, and so on).

    How to use the system API?

    The main problem you will encounter when working with the system API is the complete (with a few exceptions) lack of documentation. You will find almost no mention of this either in official or unofficial manuals. Information will have to be collected bit by bit, scouring hundreds of pages of forums and reading thousands of pages of Android source code. However, we will give you a starting point, albeit a small one, in the form of a couple of useful examples.

    WRITE_SECURE_SETTINGS

    The WRITE_SECURE_SETTINGS permission was introduced in Android 4.2 to protect some critical Android settings. These settings include: turning on/off airplane mode, managing location and data transfer settings. It is protected by three levels of access: signature, privileged and development. That is, you can use any of the above methods for obtaining an access level to give your application the WRITE_SECURE_SETTINGS permission.

    How to use the new opportunities? For example, like this:

    // Read the current setting value boolean isEnabled = Settings.System.getInt(getContentResolver(), Settings.System.AIRPLANE_MODE_ON, 0) == 1; // Toggle the setting Settings.System.putInt(getContentResolver(), Settings.System.AIRPLANE_MODE_ON, isEnabled ? 0: 1); // Send an intent to switch Intent intent = new Intent(Intent.ACTION_AIRPLANE_MODE_CHANGED); intent.putExtra("state", !isEnabled); sendBroadcast(intent);

    This is a very simple code that stupidly switches the smartphone to airplane mode or vice versa depending on the current state. Everything is simple and concise.

    INSTALL_PACKAGES

    As the name implies, the INSTALL_PACKAGES permission allows you to “silently” install APK packages on the system. This feature can be used either by applications signed with a firmware key (signature) or installed in /system/priv-app . In this case, it is not even necessary to use the Java API, just call the pm (Package Manager) command from the console with the necessary parameters:

    RunCommandWait("pm install " + apkPath, false);

    After the command is processed, the apkPath package will be installed on the system. You could argue that the same can be done with root rights, and you would be right: in this case, it is enough to change the last argument of the runCommandWait() function to true. However, it is worth keeping in mind that applications with root rights, firstly, lead to the appearance of a window asking the user for the appropriate permissions, and secondly, they are logged by the same SuperSU. Otherwise, it’s enough to register your software once in /system/priv-app, and it will be able to install as much software as you want without any questions.

    Instead of conclusions

    That's all. Accessing the private API in Android is not that difficult to achieve. On the other hand, with legitimate software, in most cases it makes no sense to use it; it’s easier to get root rights and call the appropriate console commands: settings to change settings, pm to install/uninstall applications, setprop to change low-level settings and so on. However, if we are talking about not quite ordinary software...

    Android SDK includes a variety of libraries, documentation and tools that help develop mobile applications for Android platform.

    • API Android SDK - Android API libraries provided for application development.
    • SDK documentation - includes extensive reference information detailing what is included in each package and class and how to use it when developing applications.
    • AVD (Android Virtual Device) is an interactive emulator of an Android mobile device. Using an emulator, you can run and test applications without using a real Android device.
    • Development Tools - The SDK includes several development tools that allow you to compile and debug the applications you create.
    • Sample Code - The Android SDK provides sample applications that demonstrate some of the capabilities of Android, and simple programs that show how to use custom API features in your code.

    SDK and Android API Level versions

    Before the beginning Android application development It's helpful to understand the platform's overall approach to managing API change. It is also important to understand Android API Level (API Layer Identifier) ​​and its role in making your app compatible with the devices on which it will be installed.

    API level- an integer value that uniquely identifies the Android platform API version. The platform provides API structures that applications can use to interact with the Android system. Each subsequent version of the Android platform may include API updates.

    Updates to the API structure are designed to ensure that the new API remains compatible with earlier versions of the API. Thus, most changes to the API are cumulative and introduce new functionality or fix previous ones. Since some of the APIs are constantly updated, outdated APIs are not recommended for use, but are not removed for reasons of compatibility with existing applications.

    The API level that an Android application uses is determined by an integer identifier that is specified in the configuration file of each Android application.

    The table determines the correspondence between the API level and the Android platform version.

    Compliance with platform version and API level

    Tools for application development and debugging

    In addition to the emulator, the SDK also includes many other tools for debugging and installing the applications you create. If you develop Android apps using the Eclipse IDE, many of the command line tools included in the SDK are already used when building and compiling your project. However, in addition to them, the SDK contains a number of useful tools for developing and debugging applications:

    • android- an important development tool launched from the command line that allows you to create, delete and configure virtual devices, create and update Android projects (when working outside the Eclipse environment) and update the Android SDK with new platforms, add-ons and documentation;
    • Dalvik Debug Monitor Service (DDMS)- Integrated with Dalvik Virtual Machine, the standard virtual machine of the Android platform, this tool allows you to manage processes on both the emulator and device, and also helps in debugging applications. You can use this service to terminate processes, select a specific process for debugging, generate trace data, view heap or thread information, take emulator or device screenshots, and much more;
    • Hierarchy Viewer- a visual tool that allows you to debug and optimize the user interface of the application being developed. It shows a visual tree of the view hierarchy, analyzes the performance of redrawing graphics on the screen, and can perform many other functions to analyze the graphical interface of applications;
    • Layoutopt is a command line tool that helps optimize markup schemes and markup hierarchies in the application you are creating. Necessary for solving problems when creating complex graphical interfaces that may affect application performance;
    • Draw 9-patc h is a graphic editor that allows you to easily create NinePath graphics for the graphical interface of developed applications;
    • sqlite3- a tool for accessing SQLite data files created and used by Android applications;
    • Traceview- this tool provides a graphical analysis of trace logs that can be generated from applications;
    • mksdcard is a disk image tool that you can use in an emulator to simulate the presence of an external memory card (such as an SD card).
    • The most important of them is mobile device emulator , however, the SDK also includes other tools for debugging, packaging and installing your applications on the emulator.

    Android Virtual Device

    Android Virtual Device (Android Virtual Device) is an emulator that runs on a regular computer. The emulator is used to design, debug and test applications in a real runtime environment.

    Before you can run an Android device emulator, you need to create Android Virtual Device (AVD) . AVD Defines the system image and device settings used by the emulator.

    There are two ways to create a device emulator:

    1. On the command line using the android utility, available in the directory where you installed the Android SDK, in the tools folder.
    2. Visually using Android SDK and AVD Manager in IDE Eclipse by selecting the menu item Window | Android SDK and AVD Manager. The Android SDK and AVD Manager window will appear, with which you can create and configure mobile device emulators, as well as download Android SDK updates.

    The Android SDK and AVD Manager window will also appear if you call android.exe without parameters on the command line.

    iAndroid SDK and AVD Manager

    Android SDK and AVD Manager window

    On the right side of the List of existing Android Virtual Devices panel, click the New button, which will open the Create new AVD window.

    In this window, set the desired configuration for the device emulator being created:

    • Name- name of the device being created;
    • Target- Android SDK version supported by the device. The device is backward compatible with older SDK versions, i.e. if Android 2.0 is selected, the emulator will support SDK versions 1.6, 1.5, 1.1;
    • SD Card- installs a virtual SD card;
    • Skin-device screen type. The downloadable platform includes a number of emulator skins that can be used to simulate the app's performance on devices of different screen sizes and resolutions. The set of skins for the emulator, depending on the installed SDK version specified in the Target field, contains different types and screen sizes, for example:
    • HVGA(Halfsize VGA Video Graphics Array), size 320x480, medium density, normal screen;
    • WVGA800 (Wide Video Graphics Array), size 480x800, high density, normal screen;
    • WVGA854 (Wide Video Graphics Array), 480x854, high density, normal screen;
    • QVGA (Quarter Video Graphics Array), size 240x320, low density, small screen;
    • WQVGA (Wide Quarter Video Graphics Array), size 240x400, low density, normal screen;

    • Hardware- imitation of equipment installed on the device. If necessary, by clicking the New button, you can open a window for adding additional virtual equipment.

    Window for adding additional virtual hardware

    After setting the configuration and clicking the Create AVD button, the manager will create a new virtual device, the name and API version of which will appear in the list List of existing Android Virtual Devices.

    For more fine-tuning, it is better to use the andnoid.exe command line tool. It has more features than Map9er's visual AVD and is convenient for configuring the network, ports and virtual hardware of the emulator. Unfortunately, due to the limited space of the book, it is not possible to consider this tool in more detail.

    Depending on supported API versions The appearance of the virtual device will be different.

    The emulator window is designed in the form of a phone with an additional keyboard. After the system boots, it appears Home screen - Android desktop. To access it, use the button with the house icon. The emulator also imitates the touch screen of a real mobile device - in the emulator, you press the left mouse button on the screen.

    The emulator has two virtual desktops, which can be navigated using the arrow buttons on the device's navigation panel or by moving the cursor while holding down the left mouse button (in a real device, by moving your finger across the screen). In addition to program shortcuts, you can place widgets on the desktop.

    Appearance of AVD version 1.5

    Appearance of AVD version 2.0

    To test the appearance of the application being created at different screen positions using a key combination +You can change the screen layout from vertical to horizontal and vice versa.

    The bar at the top of the screen is Status Bar. It contains system notification icons: mobile station signal strength, battery charge and current time. Panel Status Bar is also designed to display (in the form of icons appearing on the left side of the panel) user notifications for missed calls, unread text and multimedia messages, received mail, and system notifications from services running in the background. If in Status Bar select the notification icon and pull down the marker that appears, an expanded notification panel opens with more detailed information and a button to close the notification.

    The marker at the bottom of the screen allows you to open a window for launching applications installed on the system - Application Launcher. The window extends when you click on the marker.

    The emulator, however, does not support some functionality available on real devices:

    • incoming and outgoing messages. However, you can simulate telephone calls through the emulator interface;

    Launcher of installed applications Application Launcher

    • USB connection;
    • video camera (however, there is a video camera simulator);
    • connecting headphones;
    • connection status determination;
    • determining the battery charge level; D detection of SD card insertion or removal;
    • Bluetooth connection.

    Of course, real phones are somewhat different from the emulator, but in general AVD designed very high quality and close in functionality to the real device.

    More information about how API levels work is available in What is API Level?

    App Components

    Isolated services

    App stack navigation

    Android 4.1 makes it much easier to implement the proper design patterns for Up navigation. All you need to do is add the android:parentActivityName to each element in your manifest file. The system uses this information to open the appropriate activity when the user presses the Up button in the action bar (while also finishing the current activity). So if you declare the android:parentActivityName for each activity, you don"t need the onOptionsItemSelected() method to handle click events on the action bar"s app icon—the system now handles that event and resumes or creates the appropriate activity.

    This is particularly powerful for scenarios in which the user enters one of your app"s activities through a "deep dive" intent such as from a notification or an intent from different app (as described in the design guide for Navigating Between Apps). When the user enters your activity this way, your app may not naturally have a back stack of activities that can be resumed as the user navigates up. However, when you supply the android:parentActivityName attribute for your activities, the system recognizes whether or not your app already contains a back stack of parent activities and, if not, constructs a synthetic back stack that contains all parent activities.

    Note: When the user enters a deep activity in your app and it creates a new task for your app, the system actually inserts the stack of parent activities into the task. As such, pressing the Back button also navigates back through the stack of parent activities.

    When the system creates a synthetic back stack for your app, it builds a basic Intent to create a new instance of each parent activity. So there"s no saved state for the parent activities the way you"d expect had the user naturally navigated through each activity. If any of the parent activities normally show a UI that"s dependent on the user"s context, that context information will be missing and you should deliver it when the user navigates back through the stack. For example, if the user is viewing an album in a music app, navigating up might bring them to an activity that lists all albums in a chosen music genre. In this case, if the stack must be created, it"s necessary that you inform the parent activity what genre the current album belongs to so that the parent can display the proper list as if the user actually came from that activity. To deliver such information to a synthetic parent activity, you must override the method. This provides you with a TaskStackBuilder object that the system created in order to synthesize the parent activities. The TaskStackBuilder contains Intent objects that the system uses to create each parent activity. In your implementation of onPrepareNavigateUpTaskStack() , you can modify the appropriate Intent to add extra data that the parent activity can use to determine the appropriate context and display the appropriate UI.

    If your app structure is more complex, there are several other APIs available that allow you to handle the behavior of Up navigation and fully customize the synthetic back stack. Some of the APIs that give you additional control include:

    onNavigateUp() Override this to perform a custom action when the user presses the Up button. navigateUpTo(Intent) Call this to finish the current activity and go to the activity indicated by the supplied Intent . If the activity exists in the back stack, but is not the closest parent, then all other activities between the current activity and the activity specified with the intent are finished as well. getParentActivityIntent() Call this to get the Intent that will start the logical parent for the current activity. shouldUpRecreateTask(Intent) Call this to query whether a synthetic back stack must be created in order to navigate up. Returns true if a synthetic stack must be created, false if the appropriate stack already exists. finishAffinity() Call this to finish the current activity and all parent activities with the same task affinity that are chained to the current activity. If you override the default behaviors such as onNavigateUp() , you should call this method when you create a synthetic back stack upon Up navigation. onCreateNavigateUpTaskStack Override this if you need to fully control how the synthetic task stack is created. If you want to simply add some extra data to the intents for your back stack, you should instead override onPrepareNavigateUpTaskStack()

    However, most apps don"t need to use these APIs or implement onPrepareNavigateUpTaskStack() , but can achieve the correct behavior simply by adding android:parentActivityName to each element.

    Multimedia

    Media codes

    You can handle encrypted media data in the codecs by calling queueSecureInputBuffer() in conjunction with the MediaCrypto APIs, instead of the normal queueInputBuffer() .

    For more information about how to use codecs, see the MediaCodec documentation.

    Record audio on cue

    Audio effects

    Note: It"s not guaranteed that all devices support these effects, so you should always first check availability by calling isAvailable() on the corresponding audio effect class.

    Gapless playback

    You can now perform gapless playback between two separate MediaPlayer objects. At any time before your first MediaPlayer finishes, call setNextMediaPlayer() and Android attempts to start the second player the moment that the first one stops.

    Media router. The new APIs MediaRouter, MediaRouteActionProvider, and MediaRouteButton provide standard mechanisms and UI for choosing where to play media.

    Camera

    Auto focus movement

    Connectivity

    Android Beam

    Android Beam™ now supports large payload transfers over Bluetooth. When you define the data to transfer with either the new setBeamPushUris() method or the new callback interface NfcAdapter.CreateBeamUrisCallback , Android hands off the data transfer to Bluetooth or another alternate transport to achieve faster transfer speeds. This is especially useful for large payloads such as image and audio files and requires no visible pairing between the devices. No additional work is required by your app to take advantage of transfers over Bluetooth.

    When using the callback interface, the system calls the interface"s createBeamUris() method when the user executes a share with Android Beam so that you can define the URIs to share at share-time. This is useful if the URIs to share might vary depending on the user context within the activity, whereas calling setBeamPushUris() is useful when the URIs to share are unchanging and you can safely define them ahead of time.

    Network service discovery

    Android 4.1 adds support for multicast DNS-based service discovery, which allows you to find and connect to services offered by peer devices over Wi-Fi, such as mobile devices, printers, cameras, media players, and others that are registered on the local network.

    Before you can start discovering services on local devices, you also need to call addServiceRequest() . When the WifiP2pManager.ActionListener you pass to this method receives a successful callback, you can then begin discovering services on local devices by calling discoverServices() .

    When local services are discovered, you"ll receive a callback to either the WifiP2pManager.DnsSdServiceResponseListener or WifiP2pManager.UpnpServiceResponseListener , depending on whether you registered to use Bonjour or Upnp. The callback received in either case contains a WifiP2pDevice object representing the peer device.

    Network usage

    Accessibility services can also perform actions on behalf of the user, including clicking, scrolling and stepping through text using performAction and setMovementGranularities . The performGlobalAction() method also allows services to perform actions such as Back, Home, and open Recent Apps and Notifications.

    Customizable app navigation

    When building an Android app, you can now customize navigation schemes by finding focusable elements and input widgets using findFocus() and focusSearch() , and set focus using setAccessibilityFocused() .

    More accessible widgets

    The new android.view.accessibility.AccessibilityNodeProvider class allows you to surface complex custom views to accessibility services so they can present the information in a more accessible way. The android.view.accessibility.AccessibilityNodeProvider allows a user widget with advanced content, such as a calendar grid, to present a logical semantic structure for accessibility services that is completely separate from the widget’s layout structure. This semantic structure allows accessibility services to present a more useful interaction model for users who are visually impaired.

    Copy and Paste

    Copy and paste with intents

    Renderscript

    Renderscript computation functionality has been enhanced with the following features:

    • Support for multiple kernels within one script.
    • Support for reading from allocation with filtered samplers from compute in a new script API rsSample .
    • Support for different levels of FP precision in #pragma .
    • Support for querying additional information from RS objects from a compute script.
    • Numerous performance improvements.

    New pragmas are also available to define the floating point precision required by your compute Renderscripts. This lets you enable NEON like operations such as fast vector math operations on the CPU path that wouldn’t otherwise be possible with full IEEE 754-2008 standard.

    Note: The experimental Renderscript graphics engine is now deprecated.

    Animation

    Activity launch animations

    Remote views

    • "sans-serif" for regular Roboto
    • "sans-serif-light" for Roboto Light
    • "sans-serif-condensed" for Roboto Condensed

    Vibrate for input controllers

    If connected input devices have their own vibrate capabilities, you can now control the vibration of those devices using the existing Vibrator APIs simply by calling getVibrator() on the InputDevice .

    Permissions

    ...

    This feature defines "television" to be a typical living room television experience: displayed on a big screen, where the user is sitting far away and the dominant form of input is be something like a d-pad, and generally not through touch or a mouse/pointer-device.
    

    2024 gtavrl.ru.