(access to the Android OS as an administrator), understand that this procedure has not only , but also . Therefore, they sometimes encounter the error “Your device has been modified. Updates software are missing.” Indeed, having access to all system files, using a smartphone or tablet becomes easier. However, it will no longer be possible to officially update the operating system.
When you request to search for official software updates from the device, you will receive an error message: “Your device has been modified. There are no updates.” To return to the original factory state, ROOT rights will have to be disabled. This can be done using the instructions below.

How to disable ROOT rights:

1. Disable the antivirus on the PC;
2. Go to the official Samsung website and download the program;
3. Go to Samsung KIES to the “Tools” tab. In it, select the option “Firmware update and initialization”;
4. Enter the device model and its serial number in the windows provided for this purpose. Serial number you can find out by going to “Settings” - “About device” - “Status” - “Serial number”. The Galaxy S4 model has the “GT-I9500” format;
5. Next, follow the prompts of the electronic assistant.

This scheme works on most Samsung models Galaxy line and allows you to get latest version official regional firmware of the operating system. may take 20 - 60 minutes. After removing ROOT rights, receiving official OS updates through Over-The-Air (OTA) technology will again become available, and the error “ Your device has been modified. No software updates available” will disappear.

Note! After removing superuser rights, the device will return to its original state. factory condition. All your data will be lost.
This instruction should work not only for latest smartphones Samsung Galaxy S4, S5, Note, but also on many other Galaxy.

In software development, the work is complete when the completed software product reaches those for whom it was intended. In the case of mobile software, this means deploying the application you create to user devices. The ultimate measure of the quality of a product is the usefulness of the application and the pleasure that working with it gives to users. For these goals to be achieved, the mobile app must land on the actual target devices, which means it must be pre-packaged and then deployed to each user's mobile device.

This book focuses on enriching the reader's technical knowledge and instilling in him the creative way of thinking necessary to create great mobile applications. And although the operations of packaging and deploying applications are not directly related to "writing mobile code", they play a very important role, and this chapter provides an overview of the decisions you will have to make to successfully deploy your mobile application.

Because the details of application packaging and deployment are determined by the specific device types and software technologies, this chapter provides only short review questions related to this topic. The individual steps of the packaging process are different for different technologies: J2ME/J2SE, the .NET Compact Framework, and some native code-based technologies require different sequences of steps to package and deploy applications. For different types devices, such as PDAs, smartphones or any specialized devices, have different software installation procedures, differing in their details. By issuing phones to their users, network operators mobile communications often offer software designed for dynamic loading to these devices; these operators have their own strategies for installing and initializing software. Documentation packages specific to various device technologies and mobile network operators can often be downloaded from the Web.

This short chapter focuses only on the most general issues to give you a mental framework for how to approach the problems of packaging and deploying applications. Additional links articles on the specifics of packaging and deploying applications when working with the .NET Compact Framework are given in Appendix A; Quite good articles and examples that will help you understand the details of the processes under consideration can be found among online resources. In addition, there are professional installation tools that can significantly reduce the number of manual operations required to package and prepare mobile applications; Of course, it makes sense to familiarize yourself with these tools. However, it is very important to know what challenges and opportunities you have to deal with when deploying mobile applications.

To ensure your mobile app deployment is successful, you must answer the following questions:

1. If your target devices are not "open devices", does the device vendor have any requirements that must be met?

2. Are there additional components that must also be deployed in order for the application to function properly on all types of devices selected as targets?

3. How will the end user install your application?

All these issues are discussed in detail in the following sections.

Does your mobile app need a digital signature?

Mobile devices can be divided into three categories:

1. Devices for a strictly defined purpose. This category includes devices that come with pre-installed software that provides the user with a fixed set of services. There are no tools to allow you to add additional software after the device has been deployed. Just such systems were the first mobile phones until quite recently. The main reason that devices with fixed dial functional capabilities are still found today, the desire is to provide guaranteed reliability and safety characteristics. The closed system can be thoroughly tested. The only way to include software in such a system is to write it into the device's ROM at the manufacturing stage or by updating the ROM. Among modern mobile device platforms that are of the greatest interest, systems with a strictly defined purpose are not found.

2. Open devices. These include devices for which there are no restrictions regarding what software can be installed on them. The user can freely place any desired software on the device without obtaining any permission. Most PDA/Pocket PC devices are open systems, and so are some smartphone models.

3. Devices with limited expansion capabilities. These are devices on which only applications for which this is allowed can be installed. So that on such a device with limited access any application may be running, you must obtain the consent of the third party who controls access to this device. When mobile phones This party is usually the mobile network operator that issued the device. Applications deployed to restricted devices must first obtain a cryptographic signature.

A cryptographic signature is a small piece of information attached to an application. The signature is based on the use of two elements: 1) a unique binary hash code generated by applying a special algorithm to the bytes of the application, and 2) a cryptographic key, owned by the individual or organization signing the application; Usually this key consists of two parts - a closed secret part and a derivative open part, the restoration of which by unauthorized persons is difficult. The signature attached to the signed application is verified using a set of approved keys. The signature is used to reliably identify the party signing the application. If the application binary image changes for any reason, the signature becomes invalid. Likewise, if you use a different key to sign an application, the resulting signature will change. A device that provides limited application installation capabilities maintains a list of approved signing keys. When you try to install an application or run it on a device, it is verified that it is signed by an authorized party; If the check gives a negative result, then execution of the application is prohibited. It is also possible that if the signature is missing or does not match, the device asks the user whether he wants to continue with the operation, the security of which is not guaranteed; The choice of this behavior is determined by the device manufacturer or distributor.

ON A NOTE

A manufacturer may supply multiple versions of a device, some of which are "open" and others that are "restricted" devices. An example of this type of device is Microsoft Smartphone devices.

Some manufacturers and their mobile network operator partners ship smartphones as "open" devices that allow any application to be installed. Other vendors market them as "limited extensibility" devices, allowing only approved applications to be installed. Typically, devices purchased directly from the manufacturer are “open source.” Typically, if you are developing and testing applications, then you need open devices, on which your application can be seamlessly deployed from a development tool without any signature. When purchasing a device for application development purposes, make sure this option is available.

If your mobile app is intended to run on devices that limit the apps that can be used on this device, then the application must be signed. Typically, this procedure involves sending the application to a third party who is the owner of the signing keys, the presence of which is verified by the device. It is important to understand that the model in which signatures are used does not depend on exactly how the application got to the device. The application can be downloaded from the Web, installed using a flash memory card, or downloaded from a PC; this usually makes no difference to the device module that verifies signatures. In order for applications to run, they must go through the same signature verification process.

Contact the mobile network company that issues the phones you want to use as the target device for your application for detailed instructions on how to obtain execution permission and a cryptographic signature for the application. Many operators that distribute smartphones support one or another partnership programs developing applications that you can join. Often, technology providers also have certification and partnership programs that facilitate the placement of applications on devices by agreement with operators mobile networks. So, for this purpose, Microsoft runs the Mobile2Market program (see Appendix A).

Why do some device vendors require apps to be signed?

Mobile network operators are the main distributors of mobile devices, requiring digital signatures for applications when installing and running new software. This is mainly done for the following three reasons:

1. To manage the commercial usage model for applications running on their issued devices. Mobile network operators often subsidize part of the cost of the phones they issue to users. Therefore, they need a mechanism to return the funds invested in handsets. Some operators prefer to receive this compensation as a share of the revenue from running applications on their devices. Others only want apps deployed on devices that they believe are useful for their business. Still others may be most interested in ensuring that only apps that meet certain quality and content requirements are deployed to their devices.

2. To control the costs of supporting the devices they issue. Mobile network operators that issue phones to their users in large quantities, worries about the cost of their subsequent support. Every time a user has a problem with their handset and contacts their network operator, all costs associated with providing the user with the technical assistance they require are borne by the provider. The usefulness of such support becomes problematic if running an application deployed on the device, either accidentally or intentionally, results in unauthorized use of the network or prevents the phone from being used for normal operations. A mobile network operator may want to have full confidence that the phones it distributes in large quantities only run approved, high-quality applications that are covered by the terms of support.

3. To protect your networks. Mobile network operators ensure that applications running on their devices cannot, accidentally or intentionally, harm their expensive communications networks. For network operators, there is nothing worse than viruses spreading among many phones and initiating a DoS (denial of service) attack, which leads to the impossibility of commercially servicing the network.

The desire of mobile network operators to control the use of the phones they provide comes into conflict with the prospects for faster innovation that are enabled by the use of open platforms. The centralized management model may be attractive due to its stability, but open platforms offer the opportunity to dynamically introduce unplanned innovations. This situation is analogous to the opposition that exists between the predictable stability of a planned economy and the creative chaos of the capitalist system. Different mobile network operators are experimenting with different models, each trying to find the best balance between control and freedom. Add to this the desire of various parties to provide customizable security settings for each individual application (controlling, for example, the ability to access the network, display the user interface, access to file system devices and the like), and it will become clear to you that the controversy around this will continue for many years. Ultimately, something closer to open model, but with security measures in place to ensure that access to the most valuable functionality of mobile devices will only be possible with the consent of the network operators distributing these devices. It is reasonable to assume that other categories of mobile device providers will be involved in this scheme. An organization that provides feature-rich smartphones to its employees may only allow applications that it deems trustworthy to be used on them. In the end, the final say will always remain with the party from which the user receives the mobile device. Those who buy phones directly from vendors are likely to purchase open devices, while those who get them from a third party will be given some options to extend the functionality of the devices, with some bias tailored to that party's interests.

Installing runtimes and other required components

If you intend to use devices of a certain configuration for your mobile application, you can optimize the installation for such a device. On the other hand, if the range of devices on which a mobile application is intended to run is expected to be as wide as possible, you must define a common denominator for them and account for those components that may be missing on some devices. There are two different cases: 1) target devices that are missing the runtime environment required by your application, and 2) target devices that are missing components that your device uses.

Dynamically Deploy Runtimes to Mobile Devices

The ability to dynamically install the core runtime libraries required by your application is important if multiple generations of devices are targeted. For example, while the .NET Compact Framework v1.1 is supported on Pocket PC 2000, 2002, 2003 and later models, the framework was not pre-installed in ROM on any Pocket PC 2000 devices, which is also true for most Pocket devices PC 2002

The NET Compact Framework has only become a standard part of the platform since the Pocket PC 2003 generation. If your application was built to run on top of the .NET Compact Framework v1.1 and you want it to run on as wide a range of hardware as possible, then for some devices this may be possible. require dynamic installation of the runtime environment. You have three different options

1. Limit the ability to run the application only on those devices on which the required environment is installed. Of course, this solution is the simplest, but at the same time the least flexible.

2.Package the required runtime environment along with the application installation files. This method provides the most complete functionality, but at the same time it is also the most cumbersome, since along with the application installation program, those components of the runtime environment that are not needed will be transferred to the device, and the installation logic becomes more complicated, since different types of equipment may require different options for assembling the environment. If on most types of your target devices required version runtime is already installed, much of the work will be wasted.

3.Require users of devices that do not have the required runtime to install it manually. Ideally, the installation logic should be able to independently detect the presence or absence of required runtime components. If only a small portion of your target devices require dynamic installation of components, then it is probably sufficient to inform the users of those devices exactly what they need to do and ask them to follow further instructions in the installation procedure.

ON A NOTE

Only some device classes support dynamic installation of runtime environments and components.

As noted earlier, some devices are open source and allow software installation, while others only allow the installation of certain software and therefore may not allow for dynamic installation of runtime environments. In addition, the range of devices that allow dynamic installation of runtime environments is also limited by technical reasons. For example, on Microsoft Smartphone and Pocket PC devices, the memory allocated for file systems is handled differently, as a result of which it is possible to support the installation of the .NET Compact Framework in the Pocket PC RAM file system, if necessary, but it is not feasible for Microsoft Smartphone devices, which require the runtime to be installed in ROM (although applications may be stored in the smartphone's file system). Therefore, knowledge of the specifications and options for expanding the functionality of target devices is very important.

An equally important aspect is the correct use of runtime versions. Regardless of the runtime technology you use (e.g. .NET Compact Framework, J2ME, J2SE, native codes), updated versions are released from time to time, so you need to be careful about which version you are working with.

Many runtimes provide compatibility with previous versions(backwards compatible); for example, version 1.3 of the runtime can execute code written for versions 1.1 and 1.2. If backward compatibility is not supported, you have two options:

1. Probably the most simple solution is to create separate versions of your application for each supported runtime version; This will require you to put extra effort into developing and testing your application, but will ensure the best experience for your end users.

2. The second option is to install the required runtime version as described above.

Dynamic installation of components required by the application

Components are any technologies installed on the device that your application uses that are not part of the underlying runtime or operating system. In the case of enterprise mobile applications, these include, for example, processors local databases device data. Another example would be graphic elements third party controls that your application may use. The components themselves may be accompanied by additional files. For example, an application that uses a mobile device's database processor may have prepopulated database files containing data that the application will use at runtime.

Unlike the case of runtime environments discussed above, you generally should not expect the bulk of target devices to ship with installed components, which your application may need. As in the previous case, if the components required by the application are missing, you have two options: 1) the necessary components can be provided by the application installation program and installed by it as needed, and 2) the installation package of your application can come without the components, but report users about where components can be installed individually. Your choice will be determined by how likely it is that the required components are already installed on users' devices, and by how much inclusion of components increases the size of the application's installation package.

Possible packaging and installation options

There are several possible options delivery and installation of the application. Which mechanism is best depends on the complexity of your application, its dependency on components, and how your mobile application will be used by end users.

If your application doesn't have components that come with it that it depends on, it's best to use the simplest copy-and-run installation option. As the name of this method itself says, in this case the installation comes down to local copying of the application to the device, after which it can be launched for execution.

With this approach, there is no local registration of the application on the device. If you need to register an app on a mobile device so that it appears in the navigation options offered to the device user, you will need an additional installation code.

Device-Managed Installation

Device-driven installation is very similar to installing desktop applications on a PC. In this case for local installation applications on mobile device starts special application. If applications on a given mobile device require digital signatures to run, then the installation program must also be signed. Typically, users download and run the installer using an Internet browser. You can also use installation tools provided by third-party developers.

Typically, local installation programs are flexible enough to allow you to install the necessary components, copy necessary files and perform other operations that must precede or follow the installation procedure.

Desktop installation

Desktop-based installations are typically accomplished by initiating the installation program for the device from the desktop computer. This model is most common when there is interaction between a desktop PC and the mobile device it is synced with. The desktop application can launch an installation program that communicates with the mobile device and installs the necessary software on it.

A desktop-based installation has two significant advantages: 1) users are familiar with the process of running installation programs on a PC, and 2) desktop computers that sync with mobile devices can use this synchronization process to force updated applications and data to move to the devices.

As in previous cases, you can also use third-party installation programs.

Installation using memory cards

Memory card-based installation is performed directly on the device itself and is initiated by inserting a memory card into the device. This type of installation procedure is very similar to installing software on desktop computers from CDs, where the installation program automatically starts after inserting the CD or DVD into the corresponding drive. Using this type of installation assumes the presence of a file with a specific name and a specific location on the media, where it tries to find it operating system after you insert the memory card into the device.

This installation option is especially convenient when the memory card must in any case be used to store application data. If, for example, a mobile application uses a database and uses a removable memory card to store 200 MB of information, then choosing this installation option will be quite natural. 4 MB of application installation package, its runtime environment and others necessary components easily nestled next to 200 MB of data, which in any case must be transferred to the device via a memory card.

With this installation option, you may also find third-party installation programs useful.

Installation using the development tool

If your application only needs to be deployed to a small number of devices (eg 20), then it is entirely possible for a development tool to do this for you. Development tools often provide excellent tools for downloading applications and prerequisites that you can take advantage of, thereby saving you the trouble of creating and debugging your own installation scripts.

The downside to this approach is that it doesn't actually scale. It is not applicable for deploying applications on restricted devices and is only suitable for a small number of devices. If it is possible that your application will subsequently need to be deployed on a large number of devices, then you will have to think about an installation mechanism that does not require the participation of a development tool. If you are creating a specialized application intended to be used by a few devices, then this solution will suit you perfectly.

Installing applications in ROM

Another installation option that can sometimes be used when creating mobile applications for specialized equipment or when working directly with a mobile device supplier is to host the application in the device's ROM image. Custom mobile devices often come with a specific set of built-in applications.

Moreover, for many modern devices The device ROM image can be rewritten, allowing the device vendor to periodically update device capabilities. Typically, to perform such a rewrite, you must have a cryptographic key that allows you to “unlock” the device's ROM image.

While there are no technical obstacles, installing applications in ROM requires close cooperation with the device vendor (which can be a barrier in itself).

Summary

The best advice for developers of applications intended to be deployed on a large number of mobile devices is to test the deployment of the application very early in the development cycle and then include the corresponding requirements as part of the criteria for passing each development milestone. Developing application provisioning and installation technologies always requires more work than originally anticipated; In addition, this work is less attractive compared to creating the application itself, and therefore it is often put off until later, preferring to do more interesting things. The same can be said about applications for desktop computers and servers, but in the case of mobile devices this turns out to be doubly true. The heterogeneous nature of mobile devices, the potential need to engage third parties to supply devices, and the need to test installation procedures on various types devices are forced to pay close attention to this problem. Start preparing the installation package at the earliest stages of development, do it as often as possible, and test the installation procedure on the target hardware on which you plan to deploy the application.

Recently, attempts by third-party sites to install third-party software on your smartphone under the guise of firmware updates or mandatory downloads to improve the operation of the device have become more frequent. Of course, you can understand the site owners - they make money on every download.

But if the downloaded applications turn out to be harmless games and just take up memory and system capacity, that’s not so bad. Much worse if under the guise useful programs and utilities download Trojan programs whose purpose is to harm the device or steal personal data. How to distinguish malware? Let's look at this using the example of one of these programs. And at the same time we will consider the method by which its loading is imposed. Most often, it is intrusively suggested to update the system.

So, we entered one of the sites while free surfing or by search query. And we see an inscription on it that says that your smartphone is very outdated (its type is often displayed, for example Lenovo P780/S660/S860, since it is determined when the device communicates with the server).

In this regard, it is reported that the Internet connection will be very slow and limited. And you just need to update the system immediately. To do this, you just need to click “OK” and follow the instructions received.

Article about differences. Which firmware is better to choose?

The main task of such “acceleration and improvement” is to force the user to download an application developed by third-party programmers to his smartphone. It should be noted that an application that clears memory and slightly speeds up performance does exist. But you don’t need to update the system to load it, it’s a regular utility. When the user is prompted to download new system, then this may be hiding a Trojan program, the purpose of which is to gain access to personal data or disrupt the operation of the system.
In addition, OS updates cannot be performed from the browser. Messages about new OS variants may appear only in the notifications section, or they can be received manually.

How to check firmware updates on your smartphone?

To update system applications, you need to go into the settings of your smartphone, scroll down the menu to the “About phone” tab. Open this tab and select “System Update” - “Check”.

Wait while the system checks for updates and updates the software if necessary. But under no circumstances should you do this from the page of an unknown site!

If similar messages appear on the screen of your smartphone, do not click on such links. And to help other users, report on the forums when such “updates” appear.