There are a lot of code changes coming in Android N. Some of them we can see — like the new notifications — and others we can't (but are still a big deal). We see the same thing with every update. There are refinements and changes in the interface, but under the hood adjustments and changes are made to make Android run better, and safer. Google has improved security in Android Nougat in a handful of different areas. Some are designed to harden Android itself, while others are tools for developers to use so it stays that way when we install apps. Let's take a look at the changes themselves.

Seamless updates

Google already does "seamless updates" on Chrome OS, and it works really well. Things will be very similar in Android. Verizon is offering the Pixel 4a for just $10/mo on new Unlimited lines Seamless updates will use two separate system partitions. One of them is the system you're running as you use your phone every day. When it's time for an update, the other system partition gets altered and updated, and the next time you reboot you're automatically switched over. The next time there is an update, the other system partition gets changed and you switch back. Read more: Android 7.0: What are seamless updates and how do they work? That means things can be done while you're working or playing, and when it is finished all you need to do is reboot normally. You'd be surprised (I was when I heard it) but a pretty large chunk of people don't update their phone because it takes a while. They might have done it once, then sat there waiting, and decided to not do it again. It's easy to dismiss the notification. But by changing the procedure, making updates easier, and eliminating the horrible wait time while seeing the "updating apps" dialog, more people will do it. Network Security Configuration Network Security Configuration lets app developers create and use a custom configuration file for network security settings instead of requesting system-level changes.The configuration file can be changed without modifying the app itself and can be set to use a custom Certification Authority instead of the device default, and can also be set to ignore any or all of the CAs trusted by the system. This is important for connecting to a host that has a self-signed CA (for things like enterprise apps) or for an app that should only trust a specific CA. In addition, the configuration can be set to opt-out of any plain text network traffic and force encrypted communication using the HTTPS protocol. If you're a network admin or develop network apps, you know how important these changes are. The rest of us can be happy that we can have more secure network traffic in apps that are easier to develop. Media Server hardening

Remember Stagefright? While it was blown out of proportion by much of the media, there was a real issue hidden behind the hyperbole. Playing a media file and it having the ability to force you to reboot or to lose all audio is a nasty issue, and the fact that (in theory) this could be used to secretly gain root permissions is even scarier. Google takes it very seriously and we see patches to the media server library every month to try and stay ahead of the bugs and security concerns that come with it. In Android N, the media server gets a big overhaul. Google has broken up the media server into smaller components that can be updated outside of a full system update — just like they did with the WebView component. This means when they have a new patch you can grab the update from Google Play instead of waiting six months or more for the people who made your phone decide to send the patch out to you. They have also changed the permission model for the media server, no longer giving it full system permissions. Running with low privileges makes it even harder for anyone to crack into the system if they do get into the media server. This is a major change, and will make hacking an Android phone (the bad kind of hacking) even harder than it used to be. Key Attestation Key Attestation will allow developers to make sure the keys they may be using in their apps are valid and stored in the phone's hardware-backed keystore and not in software. When the attestation tool is given a generated alias for a key (the actual key should never be shared) it then generates a certificate chain that can be used to verify the key. Developers can verify both the key as well as the verified boot state to make sure everything is valid. Phones that ship with Android N and use Google services will have a certificate that's issued by Google as the root (or primary) authority while other phones that have been upgraded will need a certificate issued by the company who made them. Not all phones that can run Android N have a trusted hardware environment to store encryption keys, and in those cases, software-level key attestation is used instead. The verified boot state can still be checked to make sure the system software hasn't been tampered with. Yes, this means a developer can check for root. That's a good thing provided no undue penalty is applied to users who have rooted their phone. File-level encryption