Thank you for your interest in contributing to the Fake System Update project! This document provides guidelines and instructions for contributing to the codebase.
- Code of Conduct
- Getting Started
- Development Setup
- Development Workflow
- Coding Standards
- Commit Guidelines
- Pull Request Process
- Issue Reporting
- Feature Requests
- Testing
- Documentation
We are committed to providing a welcoming and inspiring community for all. By participating in this project, you agree to:
- Be respectful and inclusive
- Accept constructive criticism gracefully
- Focus on what is best for the community
- Show empathy toward other community members
- Harassment or discriminatory language
- Trolling or insulting comments
- Public or private harassment
- Publishing others' private information
- Unethical or unprofessional conduct
Before contributing, ensure you have:
- Android Studio Arctic Fox (2020.3.1) or newer
- JDK 11 or higher
- Git for version control
- Android SDK with API levels 24-36
- Basic knowledge of Kotlin and Android development
Looking for a good first issue? Check our issue tracker for:
- Issues labeled
good first issue - Issues labeled
help wanted - Documentation improvements
- UI/UX enhancements
Click the "Fork" button on GitHub to create your own copy of the repository.
git clone https://github.com/YOUR_USERNAME/FakeSystemUpdate.git
cd FakeSystemUpdategit remote add upstream https://github.com/ORIGINAL_OWNER/FakeSystemUpdate.git- Open Android Studio
- Select "Open an Existing Project"
- Navigate to your cloned repository
- Wait for Gradle sync to complete
- Verify the project builds successfully
git checkout -b feature/your-feature-nameBranch Naming Convention:
feature/add-ios-style- New featuresbugfix/fix-progress-calculation- Bug fixesdocs/update-readme- Documentation updatesrefactor/simplify-setup-activity- Code refactoringtest/add-unit-tests- Test additions
-
Sync with Upstream
git fetch upstream git rebase upstream/main
-
Make Your Changes
- Write clean, documented code
- Follow coding standards (see below)
- Add tests for new functionality
-
Test Your Changes
./gradlew test ./gradlew connectedAndroidTest -
Commit Your Changes
git add . git commit -m "feat: add iOS 18 update style"
-
Push to Your Fork
git push origin feature/your-feature-name
-
Create Pull Request
- Go to GitHub
- Click "New Pull Request"
- Fill out the PR template
- Wait for review
We follow the Kotlin Coding Conventions.
Naming Conventions:
// Classes: PascalCase
class FakeUpdateActivity : AppCompatActivity()
// Functions: camelCase
fun navigateToReveal()
// Constants: UPPER_SNAKE_CASE
const val EXTRA_STYLE = "extra_style"
// Variables: camelCase
val prankDuration = 10
var currentProgress = 0Indentation:
- Use 4 spaces (no tabs)
- Continuation indent: 8 spaces
Line Length:
- Maximum 120 characters
- Break long lines appropriately
Imports:
// Order: Android, AndroidX, Third-party, Java/Kotlin, Internal
import android.content.Context
import androidx.appcompat.app.AppCompatActivity
import com.google.android.material.button.MaterialButton
import kotlin.math.min
import io.softexforge.fakesysupdate.PrankSessionDataDocumentation:
/**
* Calculates non-linear progress for realistic update simulation.
*
* Progress stalls at specific points to maximize prank effect.
*
* @param fraction Time fraction (0.0 to 1.0)
* @return Progress percentage (0 to 99)
*/
fun computeNonLinearProgress(fraction: Double): Int {
// Implementation
}Layout Files:
<!-- Use kebab-case for IDs -->
<TextView
android:id="@+id/text_prank_title"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/title_setup"
android:textSize="24sp"
android:textColor="?attr/colorOnSurface" />String Resources:
<!-- Use snake_case for string names -->
<string name="onboarding_welcome_title">Welcome to Fake Update</string>
<string name="error_past_time">Selected time is in the past.</string>Dimensions:
<!-- Use dp for dimensions, sp for text sizes -->
<dimen name="spacing_normal">16dp</dimen>
<dimen name="text_size_large">20sp</dimen>Activity Structure:
class SetupActivity : AppCompatActivity() {
// 1. Companion object & constants
companion object {
const val EXTRA_STYLE = "extra_style"
}
// 2. Properties
private lateinit var styleDropdown: AutoCompleteTextView
private var selectedStyle: String = "stock"
// 3. Lifecycle methods
override fun onCreate(savedInstanceState: Bundle?) {
// Implementation
}
// 4. UI setup methods
private fun setupStyleDropdown() {
// Implementation
}
// 5. Event handlers
private fun onStartButtonClick() {
// Implementation
}
// 6. Helper methods
private fun validateConfiguration(): Boolean {
// Implementation
}
// 7. Inner classes
private class StyleAdapter : BaseAdapter() {
// Implementation
}
}We use Conventional Commits.
<type>(<scope>): <subject>
<body>
<footer>
Types:
feat: New featurefix: Bug fixdocs: Documentation onlystyle: Code style changes (formatting, etc.)refactor: Code refactoringtest: Adding or updating testschore: Build process or auxiliary tool changes
Examples:
feat(update-styles): add Windows 11 update screen
Implemented Windows 11 update style with:
- Blue accent colors
- Microsoft logo
- Progress ring animation
Closes #42
fix(exit-methods): correct shake detection threshold
The shake detection was too sensitive, causing false
positives. Increased threshold from 12f to 15f.
Fixes #38
docs(readme): update installation instructions
Added missing step for SDK installation and clarified
Gradle sync process.
- Write clear, concise commit messages
- Use present tense ("add feature" not "added feature")
- Reference issues and pull requests when applicable
- Keep commits atomic (one logical change per commit)
- Don't commit commented-out code
- Don't commit debug logs
- Code follows the style guidelines
- All tests pass locally
- New code has appropriate test coverage
- Documentation is updated
- Commit messages follow guidelines
- No merge conflicts with main branch
## Description
Brief description of changes
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Testing
Describe how you tested your changes
## Screenshots (if applicable)
Add screenshots for UI changes
## Checklist
- [ ] Code follows style guidelines
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No breaking changes (or documented)-
Automated Checks
- CI/CD pipeline runs automatically
- Lint checks must pass
- Unit tests must pass
-
Code Review
- At least one maintainer must approve
- Address all review comments
- Keep discussions professional
-
Merge
- Squash and merge (usually)
- Maintainer will merge after approval
Use the bug report template:
**Describe the bug**
A clear description of what the bug is.
**To Reproduce**
Steps to reproduce:
1. Go to '...'
2. Click on '...'
3. See error
**Expected behavior**
What you expected to happen.
**Screenshots**
If applicable, add screenshots.
**Device Info:**
- Device: [e.g. Pixel 7]
- Android Version: [e.g. Android 14]
- App Version: [e.g. 1.0]
**Additional context**
Any other relevant information.**Describe the bug**
Triple tap exit method doesn't work on Samsung devices.
**To Reproduce**
1. Configure prank with triple tap exit
2. Launch prank on Samsung Galaxy S23
3. Triple tap the screen
4. Nothing happens
**Expected behavior**
Prank should exit to reveal screen after 3 taps.
**Device Info:**
- Device: Samsung Galaxy S23
- Android Version: Android 14 (One UI 6)
- App Version: 1.0
**Additional context**
Works fine on Pixel devices. Might be related to Samsung's
touch sensitivity settings.-
Check Existing Issues
- Search for similar requests
- Avoid duplicates
-
Use Feature Request Template
**Is your feature request related to a problem?** Describe the problem. **Describe the solution** What you want to happen. **Describe alternatives** Alternative solutions you've considered. **Additional context** Screenshots, mockups, etc.
-
Discuss First
- For major features, open a discussion before coding
- Get feedback from maintainers
- Ensure alignment with project goals
We're particularly interested in:
- New update style variants (iOS, Windows, etc.)
- Accessibility improvements
- Performance optimizations
- Localization/translations
- Enhanced UI/UX
- Better analytics insights
Located in app/src/test/
Writing Tests:
class ProgressCalculationTest {
@Test
fun `progress starts below 10 percent`() {
val progress = FakeUpdateActivity.computeNonLinearProgress(0.05)
assertTrue(progress < 10)
}
@Test
fun `progress never reaches 100`() {
val progress = FakeUpdateActivity.computeNonLinearProgress(0.99)
assertTrue(progress < 100)
}
}Run Tests:
./gradlew testLocated in app/src/androidTest/
Writing Tests:
@RunWith(AndroidJUnit4::class)
class SetupActivityTest {
@get:Rule
val activityRule = ActivityScenarioRule(SetupActivity::class.java)
@Test
fun startButton_isDisplayed() {
onView(withId(R.id.btn_start_prank))
.check(matches(isDisplayed()))
}
}Run Tests:
./gradlew connectedAndroidTestBefore submitting a PR, manually test:
- Onboarding flow completes
- All update styles render correctly
- Each exit method works
- Scheduling modes function properly
- Share/receipt generation works
- No crashes or ANRs
- UI looks good on different screen sizes
- App works on Android 7.0 (API 24)
Document:
- All public APIs
- Complex algorithms
- Non-obvious logic
- TODOs and FIXMEs
Example:
/**
* Generates a shareable image receipt from prank session data.
*
* This renderer inflates the selected template layout, populates
* it with session data, and renders it to a bitmap.
*
* @param data The prank session data to visualize
* @return A bitmap containing the rendered receipt
*
* @throws IllegalStateException if template inflation fails
*/
fun generate(data: PrankSessionData): Bitmap {
// Implementation
}When making changes, update:
- Inline code comments
- README.md (if user-facing changes)
- DOCUMENTATION.md (if architecture changes)
- Changelog (for releases)
- Entertainment First - Create the most realistic prank experience
- Safety & Ethics - Ensure responsible use with clear disclaimers
- Quality - Maintain high code quality and performance
- Privacy - Never collect user data
- Real system modifications
- Malicious functionality
- Data collection or tracking
- Deceptive practices
- Documentation: Start with DOCUMENTATION.md
- Issues: Search existing issues first
- Discussions: Use GitHub Discussions for questions
- Website: Visit fakesysupdate.softexforge.io
- Watch the repository for notifications
- Check the changelog for new releases
- Follow project milestones
Contributors will be:
- Listed in the project contributors
- Mentioned in release notes for significant contributions
- Credited in the app's About section (for major features)
By contributing, you agree that your contributions will be licensed under the same license as the project.
If you have questions about contributing:
- Check this guide thoroughly
- Search existing issues and discussions
- Open a new discussion if needed
- Contact via feedback form
Thank you for contributing to Fake System Update! 🎭
Your efforts help make this the best entertainment app for harmless pranks.
Made with 💙 by Nasim STG at SoftexForge