Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink 0 day support for new android versions #86

Closed
blagoev opened this issue Jun 1, 2015 · 2 comments
Closed

Rethink 0 day support for new android versions #86

blagoev opened this issue Jun 1, 2015 · 2 comments
Assignees
Milestone

Comments

@blagoev
Copy link
Contributor

blagoev commented Jun 1, 2015

Currently minSDKVersion is referred to when building. This is not correct. We need new way to handle how and from where we reference android.jar on build.

This will also require redesigning how we handle metadata versions across different devices and different android versions at run time.

@blagoev
Copy link
Contributor Author

blagoev commented Jul 3, 2015

The correct way of getting the android version is

  • For Eclipse: to parse the project.properties file and get the target property
  • For Android Studio: parse the build.gradle file and get compileSdkVersion property
Metadata handling

The current implementation uses only metadata for single android.jar version. This is problematic since the application can run on older versions that have the same public API, but with different non public class hierarchy. The prototype representation at runtime requires the correct class hierarchy even if it is not public.

Possible way of handling this

  • Ship many and full metadata packages for every version the application can run
    This will not be optimal on our size constraints
  • Ship single full metadata package for the minVersion the application can run and only diffs for the upper versions of the application.
    This will require metadata merging and a "metadata diff builder", which will result in increased startup times. The merge should be linear towards the desired version. Ideally the merging phase should be done once and persisted so next app starts are fast as the current implementation.
  • Use the highest possible version of the metadata and ship only this version
    This will require compensation logic on certain places and may result in performance degradation.
  • Investigate if we can search for the metadata for the a class but invoke the method on the actual instance class

@blagoev
Copy link
Contributor Author

blagoev commented Jul 6, 2015

After a short discussion we think we might be able to fix the metadata handling by compensating for class hierarchy changes. This will not require any metadata merging and diff-ing. Still in the future we might need this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants