Mobile Computing
COMP5216
Week 04 Semester 2, 2020
Dr. Kanchana Thilakarathna School of Computer Science
The University of Sydney
Page 1
Announcements
– It’s great that you are talking…! – What should be in the proposal?
– App: background, related work, significance, requirements, and etc;
– Solution: explain how you are going to implement your solution describing the proposed workflow of the app and technical approaches that are required to implement the solution.
– Plan: the implementation schedule, workload distribution among the group, how to develop collaboratively; and
– Potential setbacks: identified risks, threats and proposed solutions;
– References
The University of Sydney
Page 2
E.g. Workflow of the app
The University of Sydney Page 3
E.g. Technical approach
– How you going to technically realize your app?
– Do you need server support?
– Are you going to rely on external
libraries?
– What are the API that you going to use?
– Any specific ML models?
– Etc…
The University of Sydney
Page 4
Outline
– User Quality of Experience – What to avoid ?
– Challenges in Mobile computing – Structure of the course
– E.g. Challenges in determining user location – Option 1
– Option 2
– Google Play Services
– Internet Protocol Basics
The University of Sydney
Page 5
User Quality of Experience (QoE)
– The main challenge
– Extremely difficult to measure – why ?
– It is highly personal
– Perception – Culture
– Age
– Mood
– Gender
– Profession
The University of Sydney
Page 6
User Quality of Experience (QoE)
– How users react to apps also depends on… – Time of the day
• Check weather in the morning vs checking whether at night – Season
• Rainy vs Summer – Current activity
• Sitting in a couch vs standing on board crowded train
The University of Sydney
Page 7
Understand your customer
– Target a specific customer segment at the beginning – SnapchatàTeenagers
– What are the common things that annoy us ?
The University of Sydney Page 8
What to avoid ?
User perception threshold – 50-100ms
Trewin, S., Swart, C., Koved, L., Martino, J., Singh, K.,&Ben-David, S. (2012, December). Biometric authentication on a mobile device: a study of user effort, error and task disruption. In Proceedings of the 28th Annual Computer Security Applications Conference (pp. 159-168). ACM.
The University of Sydney
Page 9
What to avoid ?
– Potential causes
– Faulty battery or device
– Network issues
– High speed mobility
– Trying to download too much data
– Not the right data flow
– Too complex data processing
– Not the right network for communication
– Too frequent communication The University of Sydney
– Network
– Computing – Energy
Page 10
What to avoid ?
– STRIDE threat list
– Spoofing, Tampering, Repudiation, Information Disclosure, Denial of
Service , Elevation of Privileges – Potential causes
– Usermistakes
– Unsecure communication
– Unsecure storage of user data – Malicious ad library
– Security – Privacy
The University of Sydney
Page 11
E.g. Power vs Communication
– Power consumption for HTTPS data transfer 1000
800
600
400
200
0
Idle App start-up TCP handshake TLS handshake Data exchange Connection termination High power idle Idle Average
Power (mW)
0 0.1 0.2 0.3
0.4
0.5 0.6 0.7
– You design your app to transfer 1KB of data to your app server at every one 10 seconds.
– What are the consequences ? The University of Sydney
Page 12
Time (s)
E.g. Power vs Security
– Power consumption for HTTPS data transfer 1000
800
600
400
200
0
Setting up a secure channel
Idle App start-up TCP handshake TLS handshake Data exchange Connection termination High power idle Idle Average
Power (mW)
0 0.1 0.2 0.3 0.4
0.5 0.6 0.7
– Every action has consequences The University of Sydney
Page 13
Time (s)
Course Schedule
– We are going to have one lecture for each challenge
Week
Lectures
Labs/Tutorials
5
Mobile Networking
Media access
6
Mobile Security & Privacy
AR/VR
7
Mobile Cloud & Energy
User management
– There are other challenges:
– User Interaction (did talk about them a bit on Week 2) – Policies and regulations
– Advertising
– App analytics
– Monetization The University of Sydney
Page 14
Challenges in determining device location
Week 4, COMP5216
The University of Sydney Page 15
Challenges in determining device location
– Location adds “Context” to every action.
– The biggest challenge – User is moving.
– Various sources to determine the location. – GPS
– Assisted-GPS – Cell towers –…
–…
– Each source comes with different accuracy, availability, resource requirement and efficiency
– Dependent on the environmental factors. The University of Sydney
Page 16
The Global Positioning System (GPS) Location
– Provided by the United States government https://www.gps.gov
– Use the signals received from satellites for localisation.
– Each location in the world is covered by at least four satellites.
– User device receives the signal and measure the time lag to estimate the distance to each satellite.
– No data connection is required.
– Longer time-to-fix.
– Identifying the satellites – Synchronising the clocks.
The University of Sydney
Page 17
GPS Accuracy
– Standard Positioning Service (SPS) – Available to all users
– No restrictions or direct charge
– high-quality receivers have accuracies of 3m and better horizontally – In the level of 5-10m in worst case.
– Precise Positioning Service (PPS)
– Used by US and Allied military users
– Use more satellites than public service
– US Government can selectively deny access
– GLONASS (Russian), BeiDuo (China), Galileo (EU), NAVIC (India) The University of Sydney
Page 18
GPS Location
– Smartphones can connect to multiple constellations to improve the accuracy: GPS or GLONASS & use the combined result.
– Many apps in Google Play Store to check the status of GPS signals
– However, GPS is not available everywhere, especially indoors.
The University of Sydney Page 19
Assisted GPS
– Tries to address some of the problems in GPS.
– Faster set-up time by getting satellite information through data
connection.
– Lower energy consumption
The University of Sydney Page 20
Network Location
– Use near by cell tower & WiFi access point information to query a geo tagged database.
– Energy Efficient.
– Needs a user data connection.
– Who provide data to the geo DBs? – Everyone
– It has been happening for sometime now https://www.zdnet.com/article/how-google-and-everyone-else-gets-wi- fi-location-data/
The University of Sydney Page 21
Network Location
– WIGLE public database – www.wigle.net
The University of Sydney Page 22
How to get location in Android – Option 1
– Location API in android.location [1] – There are two main location providers:
– GPS_PROVIDER
– NETWORK_PROVIDER – PASSIVE_PROVIDER
– Ask for the necessary permissions for the location providers. – GPS_PROVIDER:
– NETWORK_PROVIDER:
[1] https://developer.android.com/reference/android/location/LocationManager
The University of Sydney
Page 23
How to get location in Android – Option 1
– Flow for obtaining user location – Start application
– Start listening to location
– Get the cached location
– Maintain “best-estimate” filtering out less accurate updates – Stop listing to location
– Use last “best-estimate”
Location update window
The University of Sydney
Page 24
How to get location in Android – Option 1
– Start of the window
– As soon as app starts or after a certain user action
– Period of the window – Long – More battery – Short – Less accurate
– Maintain the “best-estimate”
– Most recent fix is not always the best
– PASSIVE_PROVIDER
– Getting the location fix often takes too long
– Provides locations without actually initiating a location fix. – Only returns locations generated by other providers
The University of Sydney
Page 25
Android – Option 1: Best practices
– Reduce the size of the window
– As soon as you receive the information you need, stop listening to
location
– Reduce the frequency of Location Provider access
– Restrict a set of providers
– More provider – More battery
– App developers must not be troubled with all of these problems !!
The University of Sydney
Page 26
How to get location in Android – Option 2
– Fused Location Provider API
– Current method [Recommended by Google].
– Google Play Services
– https://developers.google.com/location-context/fused-location- provider
– http://developer.android.com/training/location/index.html
– Provides a much higher level view for the developer.
– Automatically changing the appropriate Location Provider, e.g. GPS or WiFi
– Your app must do is specify the desired level of service.
– Better accuracy and power management.
The University of Sydney Page 27
Google Play Services
– Google Play services is installed as a separate application – Run as a background Service
– https://developers.google.com/android/guides/setup
The University of Sydney Page 28
Advantages of Google Play Services
– According to Google:
1. Google Play services provide a simple interface and a
cleaner API surface.
2. You specify a desired quality of service and the APIs manage
the underlying technologies for you.
3. The Google Play services APIs are optimized for
performance and battery usage.
4. The Google Play services APIs are actively maintained. Google is constantly improving the algorithms and adding more features.
The University of Sydney
Page 29
Back to – How to get location in Android – Option 2
– How ?àTutorial – Week 10
Optimize location for battery & efficiency
Recall:
– Accuracy: higher the accuracy, the higher the battery drain.
– Frequency: More frequent location is computed, the more
battery is used.
– Latency: Less latency usually requires more battery.
– Step 1:
– UtilizecachedlocationviagetLastKnownLocation(String):
– Getting the location fix often takes too long and more resources
The University of Sydney
Page 30
Accuracy – Google Play Services Location
– Specify location accuracy using the setPriority() method
– PRIORITY_HIGH_ACCURACY
– Most accurate
– Use as many providers as necessary (GPS, WiFi, Cell-towers, etc. )
– PRIORITY_BALANCED_POWER_ACCURACY
– Accurate location
– Rarely uses GPS.
– PRIORITY_LOW_POWER
– Coarse (city-level) accuracy – Mostly using on cell towers
– PRIORITY_NO_POWER
– Passive location
– Rely on location computed by other apps
The University of Sydney
Page 31
Frequency & Latency – Google Play Services Location
– setinterval()method
– The interval at which location is computed for your app. – Larger the better for battery
– setMaxWaitTime()method – Larger the better for battery
– Delays the delivery of location
– Combination of the two methods can be used to batch requests
– SetsetMaxWaitTime()severaltimeslargerthansetinterval() – Settimeouttoavoidkeeptrying
– setExpirationDuration()
The University of Sydney Page 32
Google Play Services Location APIs
– Seems a lot easier than Location APIs
– Why is it necessary to learn all location access methods ?
– Low flexibility
– E.g. Can not restrict your app to receive only WiFi location.
– Not so easy after all…
The University of Sydney
Page 33
How to get location in Android – Option 3
– Geofencing API
– Google Play Services
– https://developers.google.com/location-context/geofencing
– Geofencing API allows you to define perimeters
– Your app gets a notification when the device crosses a geofence
The University of Sydney
Page 34
Exercise
– Can you suggest 2 alternatives to geofencing without using Geofencing API or GPS?
The University of Sydney Page 35
Navigation is not only about GPS
– Oneoftheconsistentchallenges when navigating with Google Maps is figuring out the right direction to go
– Newapproachfornavigationwith Global localization, which combines Visual Positioning Service (VPS), Street View, and Maps
The University of Sydney
Page 36
Google Play Services APIs
– Develop
– Awareness, Fit, Places
– Grow
– Analytics
– Earn
– Ads
The University of Sydney
Page 37
Google Fit APIs
– Sensor API
– Raw sensor data access from both smartphone and
wearables
– Recording API
– Automated storage with subscriptions – History API
– Access to historical fitness data – Sessions API
– Store data/meta data of fitness activities – Goals API
– Tracking users fitness goals
– Bluetooth Low Energy API
– Connect companion devices to Google Fit
https://developers.google.com/fit/android/
The University of Sydney
Page 38
Awareness APIs
– FenceAPI
– Reacttochangesintheuser’senvironment
– Theuser’scurrentlocation(latitude/longitude)
– Theuser’scurrentactivity,likewalkingordriving.
– Device-specificconditions,suchaswhethertheheadphonesarepluggedin. – Proximitytonearbybeacons
– SnapshotAPI
– Getanideaaboutuser’scurrentenvironmentusing7sensorinputs 1. Time
2. Location
3. Place
4. Activity
5. Beacons
6. Headphones
7. Weather
–
Have fun developing “Context-Aware” apps…!
– https://developers.google.com/awareness/ The University of Sydney
Page 39
What’ Next ?
– Start working on Project Proposal – Dueinweek6.
– Tutorial 4
– Learn how to develop mobile app using Google’s Firebase platform – Understand how to use Cloud Firestore to store and read data
– Next week
– How to respect and effectively manage Mobile Networking resources
when you develop apps?
The University of Sydney Page 40
Optional Internet Protocols- Basics
These slides are adopted from
– Computer Networking: A Top Down Approach 7th Ed. Jim Kurose, Keith Ross
Pearson – Addison-Wesley
The University of Sydney
Page 41
What is Internet ?
– Billions of connected computing devices
– Communication links
• Fiber, copper, radio, satellite
– Hosts – end devices
• User devices, Servers
– Packet Switches
• Routers, Switches
– To inter-operate, we need; – Protocols
• TCP, IP, HTTP, 802.11 – Standards
• RFC • IETF
mobile network
home network
institutional network
regional ISP
The University of Sydney
Page 42
global ISP
What is a Protocol ?
human protocols:
– “what’s the time?” – “I have a question” – introductions
… specific messages sent
… specific actions taken when messages received, or other events
network protocols:
§ machines rather than humans
§ all communication activity in Internet governed by protocols
protocols define format, order of messages sent and received
among network entities, and actions taken on message transmission, receipt
The University of Sydney
Page 43
What is a protocol ?
a human protocol and a computer network protocol:
Hi Hi
Got the time?
2:00
TCP connection request
TCP connection response
Get http://www.awl.com/kurose-ross
The University of Sydney
Page 44
time
Transport Service Requirement
application
file transfer e-mail Web documents real-time audio/video
stored audio/video interactive games text messaging
data loss
no loss
no loss
no loss loss-tolerant
loss-tolerant loss-tolerant no loss
throughput
elastic
elastic
elastic
audio: 5kbps-1Mbps video:10kbps-5Mbps same as above
few kbps up elastic
time sensitive
no
no
no
yes, 100’s msec
yes, few secs yes, 100’s msec yes and no
The University of Sydney
Page 45
Common Internet Protocols
application
e-mail remote terminal access
Web file transfer streaming multimedia
Internet telephony
application layer protocol
SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959]
HTTP (e.g., YouTube), RTP [RFC 1889]
SIP, RTP, proprietary (e.g., Skype)
underlying transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
TCP or UDP
The University of Sydney
Page 46
TCP and UDP
TCP service:
– reliable transport between sending and receiving process
– flow control: sender won’t overwhelm receiver
– congestion control: throttle sender when network overloaded
– does not provide: timing, minimum throughput guarantee, security
– connection-oriented: setup required between client and server processes
UDP service:
§ unreliable data transfer between sending and receiving process
§ does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup,
Q: why bother? Why is there a UDP?
The University of Sydney
Page 47
Securing TCP
TCP & UDP
§ no encryption
§ cleartext passwds sent into socket traverse Internet in cleartext
SSL
§ provides encrypted TCP connection
§ data integrity
§ end-point authentication
SSL is at app layer
– apps use SSL libraries, that “talk” to TCP
SSL socket API
§ cleartext passwords sent into socket traverse Internet encrypted
§ see Chapter 8
The University of Sydney
Page 48
HTTP Overview
HTTP: hypertext transfer protocol
– Web’s application layer protocol
– client/server model
– client: browser that requests, receives, (using HTTP protocol) and “displays” Web objects
– server: Web server sends (using HTTP protocol) objects in response to requests
PC running Firefox browser
The University of Sydney
Page 49
iPhone running Safari browser
server running
Apache Web server
HTTP request
HTTP response
HTTP request
HTTP response
HTTP overview
uses TCP:
§ client initiates TCP connection (creates socket) to server, port 80
§ server accepts TCP connection from client
§ HTTP messages (application- layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)
§ TCP connection closed The University of Sydney
HTTP is “stateless”
– server maintains no information about past client requests
aside
“state” are complex!
§ past history (state) must be
maintained
§ if server/client crashes, their
views of “state” may be inconsistent, must be reconciled
Page 50
protocols that maintain
Web and HTTP
– web page consists of objects
– object can be HTML file, JPEG image, Java applet, audio
file,…
– web page consists of base HTML-file which includes several
referenced objects
– each object is addressable by a URL, e.g.,
www.someschool.edu/someDept/pic.gif
host name path name
The University of Sydney
Page 51
HTTP Method Types
HTTP/1.0:
– GET
– POST
– HEAD
– asks server to leave requested object out of response
HTTP/1.1:
– GET, POST, HEAD – PUT
– uploads file in entity body to path specified in URL field
– DELETE
– deletes file specified in the URL field
The University of Sydney
Page 52
HTTP Request Message
– two types of HTTP messages: request, response – HTTP request message:
– ASCII (human-readable format)
carriage return character line-feed character
request line (GET, POST, HEAD commands)
header lines
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n Keep-Alive: 115\r\n
carriage return, line feed at start of line indicates end of header lines
The University of Sydney
Connection: keep-alive\r\n
\r\n
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Page 53
HTTP Response Message
status line (protocol status code status phrase)
header lines
data, e.g., requested HTML file
The University of Sydney
HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
ETag: “17dc6-a5c-bf716880″\r\n Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n \r\n
data data data data data …
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Page 54
HTTP response status codes
– –
status code appears in 1st line in server-to-client response message.
some sample codes:
200 OK
– request succeeded, requested object later in this msg 301 Moved Permanently
– requested object moved, new location specified later in this msg (Location:)
400 Bad Request
– request msg not understood by server 404 Not Found
– requested document not found on this server 505 HTTP Version Not Supported
The University of Sydney
Page 55