Android OS's design flaws & how some of them can be fixed


Abstract (FAQ)


Android is a mobile operating system (OS) based on a branch of the Linux kernel and currently developed by Google.

Android has a user interface based on direct manipulation (and not X11 as is traditional with Linux and Unix systems).

Android is designed primarily for touchscreen mobile devices such as smartphones and tablet computers, with specialized user interfaces for televisions (Android TV), cars (Android Auto), and wrist watches (Android Wear).

The OS uses touch inputs that loosely correspond to real-world actions, like swiping, tapping, pinching, and reverse pinching to manipulate on-screen objects, and a virtual keyboard.

Despite being primarily designed for touchscreen input, it also has been used in game consoles, digital cameras, regular PCs (e.g. the HP Slate 21) and other electronics.

Android is the most widely used mobile OS and, as of 2013, the highest selling OS overall.

  • Android devices sell more than Microsoft Windows, iOS, and Mac OS X devices combined, with sales in 2012 to 2014 close to the installed base of all PCs.
  • As of July 2013 the Google Play store has had over 1 million Android apps published, and over 50 billion apps downloaded.
  • A developer survey conducted in April–May 2013 found that 71% of mobile developers develop for Android.
  • At Google I/O 2014, the company revealed that there were over 1 billion active monthly Android users, up from 538 million in June 2013. 

Android's source code is released by Google under open source licenses, although most Android devices ultimately ship with a combination of open source and proprietary software.

The Android OS was initially developed by Android, Inc. (which Google backed financially and later bought in 2005).

Android was unveiled in 2007 along with the founding of the Open Handset Alliance — ?a consortium of hardware, software, and telecommunication companies devoted to advancing open standards for mobile devices.






OUTSTANDING "Operating System" ISSUES STILL NOT FIXED





System Clock Synchronization Architecture


The Kernel (and the graphical user interface subsystem) is currently unable to use GPS + GLONASS + GNSS (WAAS, ENGOS) Time Correction Service "timestamps" via the standard hardware or software NMEA interfaces relating to location services.

Time slewing via RADclock should be added into the NTP (and TAI) time transfer architecture arrangement currently used by Android and Linux. 

Android's time synchronization problems need to be fixed permanently.

HOWEVER, some small and large changes in the timekeeping architecture will be needed to do it.


Primary change needed : ADD RADCLOCK

RADclock is needed as a backup timekeeping [but mainly clock discipline] mechanism to NTP (that is currently used, but badly configured in almost all Android builds). NTP and RADclock can work with each other cooperatively, so most incompatibility issues are minimal. Some RADclock features should be changeable via the Control Panel "Time & Date" subsystem, but the User Interface changes needed to do this are unclear.

URLs

RADclock FAQ

Robust
The RADclock performance has been tested over a period of years under a wide variety of conditions, including network congestion, network disconnection and server faults, and has been proven to be extremely robust (see the Documentation section for published papers on this topic).

Two Clocks in One
The RADclock actually provides two clocks, an absolute and a difference clock. The absolute clock provides "wall clock" time (i.e. today, right now) while the difference clock is designed to measure accurately the time elapsed between two events. Each clock can be accessed using the API provided.

The RADclock also gives access to kernel level packet timestamping.

Easy Deployment
The RADclock is compatible with the NTP protocol and can be deployed quickly on hosts to provide a robust timekeeping solution, using existing NTP servers. It can run in parallel to the ntpd daemon without harm, so that both clocks can coexist and be used independently.

RADclock can be reserved for specific applications requiring high accuracy.

NOTICE

RADclock may fix most of Android's decade ongoing time synchronization problems -- if it is implemented correctly.

However RADclock will have zero impact on Android devices that are not connected to the Internet.

These "non-Internet" (by luck or design) Android devices need to be able to use GNSS timestamps to slew the clock to ~TAI time, as TAI is the standard for GNSS location and navigation systems. The Control Panel and Applications need to be able to perform the time slewing function separately as well as  in concert with each other. Applications cannot perform System Clock slewing unless the device has been rooted, a bad design flaw.


Secondary change needed : ADD "Time Slew" capability to the Graphical User Interface Subsystem

USER INTERFACE CHANGE :

"TIME SYNCHRONIZATION" or "TIME SLEW" or "TIME CORRECTION" need to be separated out and away from the general Time & Date settings in the Control Panel.

These new Control Panel settings should never be lumped into the "Time & Date" settings.

Merging Time & Date -- AND Time Synchronization -- makes the Control Panel menus relating to Time & Date much more complex than necessary. This extra complexity will cause significant user confusion, so it must be avoided. 

The Graphical User Interface subsystem [that already has Superuser privileges, and thus is capable of system clock slewing] needs to add to its API a call like
  • TimeSlew(Inputs : "Calling Application[42 bytes (32 bytes min), UTF8]", "Time Source Metadata [12 bytes, ASCII6-printable]", "Time_delta[signed int delta, byte units {aka "M" for minutes, "s" for seconds, "m" for ms} ]"; Returns : Exit Code[int]).
  • There probably is a better way of making this API call, this is a 1st attempt.
  • There needs to be extensive sanity checking involved in this API.

TimeSlew() should only permit clock changes of a range of 168 hours minutes maximum (7 calendar days), providing that extra sanity checks are strictly met. This security rational should allow Android mobiles that have been turned off for 3 or 4 months [but are not near a WiFi or cell tower] to eventually correct the system clock time within 2 minutes.

However for most devices clock slewing of less than 30 seconds should be the default security policy.

Importantly, a system clock some 10 years out of date should converge to within 100ms of  TAI (or NTP Time) after less than 5 minutes of the Android device booting.

It is assumed the that User Interface subsystem would ultimately call the JAVA API SetToNow() [unless there is also a direct route to  to slew the the system time clock towards ~NTP time or ~TAI time.

The NMEA GNSS subsystem needs to be permitted to use GNSS timestamps to correct local clock time via a setting in the Control Panel. The hardware (and software) GNSS packet decoder need to be able to correct the clock time, but with some security provision (via Control Panel, say less than 120 slews per day maximum).

Applications need to be able announce that they are capable of submitting TimeSlew requests, and this requires changing some syntax around App Manifest. The user must specifically permit an application to submit time synchronization requests to the UI to hand off to the OS Kernel.
  

Tertiary change needed : ADD "Time Synchronization" Control Panel

This capability must allow NTP (+ GPS + GLONASS +WAAS +ENGNOS ...) to be called or used for timesync.

Currently, Android 5.x does not support this basic clocktime correction feature. Synchronizing to GNSS time signals requires listening to the NMEA subsystem, the primary source of timestamps not derived via NTP.

Overview of Changes (User Interface)

[Time Synchronization] {Control Panel Subsystem}

[Synchronize System Time]
--> This is supposed to be a UI Button that should call NTP (with Superuser privileges) to do a System Time Sync correction.
--> If not connected to the Internet via USB or WiFi or Bluetooth, it should use GNSS timestamps instead.
--> This button is subject to the security policies on clock slewing, any other configuration should be considered botched.  

[ ] Only use NTP & RADclock for System Time Updates (disables policies below it)
-- Notice : mobile networks will be able to override this temporarily in order to connect. 

Use [ ] GPS [ ] GLONASS Timestamps to correct System Clock (subject to Security Policy)

Use GNSS Correction Service Timestamps [ ] WAAS (North America)  [ ] ENGNOS (European Region)
to correct System Clock (subject to Security Policy)

[ ] Security Policy : Do not update System Clock via GNSS any more than
[ ] 7 days (emergency only) [ ] 30 Minutes [ ] 30 Seconds
[ ] 5 Seconds [ ] 2 Seconds [ ] 500 ms
[ ] Pattern 30s, 5s, 2s, 500ms, 100ms, 50ms

Anti-Spoofing
[ ] Security Policy : Don't trust GPS or GLONASS timestamps unless both agree within
[ ] 20ms [ ] 50ms
[ ] Pattern : 100ms, 50ms, 20ms, Trust
of the System Clock 

[ ] Security Policy : Don't trust GNSS Correction Services timestamps unless within
[ ] 20ms [ ] 50ms [ ] 100ms
[ ] Pattern : 1500ms, 300ms, 100ms, 50ms, 20ms
of the System Clock 

ANNEX : Tickets Already Submitted for System Enhancement
ANNEX : Time Synchronization Paths
  1. Time & Date Control Panel --> NTP --> Internet --> NTP Timestamps --> System Time Sync [path very approximate, current design]
  2. Time & Date Control Panel --> 2g / 3g / 4g / LTE Physical Layer --> Mobile Network Timestamp --> System Time Sync [also current] 
  3. NEW : {Control Panel} --> GNSS Link Layer --> NMEA Timestamp --> [security & sanity check] --> System Time Sync [path very approximate]
  4. NEW : {Control Panel} --> Application <--->> GNSS Link Layer --> NMEA Timestamp -->> [security & sanity check] --> System Time Sync [path very approximate], ">>" Application bypasses GNSS and NMEA via TimeSlew();
  5. Future : [Radio Controlled Clock] --> [Sanity Check] --> System Time Sync






USB Interface Issues


When Android mobiles (and tablets) are plugged into USB ports, there is no Internet access via the standardized USB internet access mechanism.

This current state of affairs does force the Bluetooth and WiFi transmission systems to be used for internet access, and reduces the functional life of the transmitters in these subsystems by the usual predictable nominal amounts.

The security risks for using the USB subsystem for web access are not that great, as the OS is already fairly locked down.





Modern X11 Compatibility





Created by

Initial ideas

Created

Last Revised

Revision

Last change


Max Power

September 2013

14 January 2015

28 January 2015

0.03a

Add USB Internet access